¿Cuándo debo usar StringBuilder o StringBuffer?

13

En una aplicación web de producción, mis compañeros programadores usaban StringBuffer en todas partes. Ahora me ocupo del desarrollo de aplicaciones y correcciones. Después de leer StringBuilder y StringBuffer Decidí reemplazar todo el código de StringBuffer con StringBuilder porque no necesitamos seguridad de subprocesos en nuestros beans de datos .

Por ejemplo: (en cada bean de datos puedo ver el uso de StringBuffer)

@Override
public String toString() {
    StringBuffer sb = new StringBuffer();// replace it from StringBuilder
    sb.append(" ABCD : ").append(abcd);
    sb.append(", EFGH : ").append(efgh);
    sb.append(", IJKL : ").append(ijkl);
}

Creamos un bean de datos separado para cada sesión / solicitud. Una sesión es utilizada por un solo usuario, ningún otro usuario puede acceder a ella.

¿Debo considerar otros puntos antes de migrar?

Si hay un solo subproceso (no hay subprocesos en espera / ningún nuevo subproceso buscará el bloqueo de objetos), funciona igual con StringBuffer o StringBuilder. Sé que en el caso de StringBuffer, toma tiempo tomar el bloqueo del objeto, pero quiero saber si existe alguna diferencia de rendimiento entre ellos, excepto la retención / liberación del bloqueo del objeto.

    
pregunta Satish Pandey 26.08.2012 - 09:09

2 respuestas

22

La única diferencia entre los dos es la sincronización utilizada en StringBuffer. La sobrecarga de la sincronización no es enorme en el gran esquema de las cosas, pero es significativa en relación con los métodos de StringBuilder que no las tienen. La JVM está haciendo un trabajo que de otra manera no tendría que hacer, especialmente con un solo hilo, etc.

Si su código funciona y la gente no se queja del rendimiento, no me preocuparía por eso. No vas a conseguir mucho por tu dinero. Sin embargo, si está escribiendo un nuevo código, o está actualizando un código que usa StringBuffer, sugeriría convertirlos al mismo tiempo.

    
respondido por el Matthew Flynn 26.08.2012 - 09:29
8

StringBuilder se agregó en un punto (Java 1.5) para ser un StringBuffer mejor y más rápido y el compilador lo usa bajo el capó para implementar el operador + en Strings.

Esto significa que al usar StringBuilder no puede hacer que su código se ejecute en JVM más antiguo que cuando se introdujo la clase. Esto sería un problema para nosotros, por un tiempo todavía. Si siempre ejecuta lo último, no necesita preocuparse.

No pasaría por el proceso de optimización por el que pasas, aunque por las siguientes razones.

  • Fuera de los bucles apretados, la ventaja es insignificante. A menos que aparezca explícitamente como un punto de acceso en un generador de perfiles, no me molestaría.
  • El cambio de código puede introducir errores, y debe volver a probar su aplicación a fondo. Eso puede ser mucho más caro que vivir con una clase sincronizada en una configuración no sincronizada.
respondido por el user1249 26.08.2012 - 09:48

Lea otras preguntas en las etiquetas