StringBuffer está obsoleto?

Question

En el libro "Effective Java", Josh Bloch dice que

StringBuffer es en gran medida obsoleta y debe ser reemplazado por el no sincronizada aplicación 'StringBuilder'

.

Pero en mi experiencia, todavía he visto el uso generalizado de la clase StringBuffer. ¿Por qué la clase StringBuffer ahora está obsoleta y por qué se debería preferir StringBuilder a StringBuffer, excepto por el aumento del rendimiento debido a la falta de sincronización?

Answer 1

Es obsoleta en ese nuevo código de Java 1.5 general debe utilizar StringBuilder - es muy raro que usted realmente necesita para construir cadenas de una manera segura para los subprocesos, así que ¿por qué pagar el costo de sincronización?

Sospecho código que ves usando StringBuffer recae principalmente en los cubos de:

• escrito antes de Java 1.5
• escritas para mantener la compatibilidad con el JDK de más edad
• escrito por personas que no conocen StringBuilder
• generados automáticamente por las herramientas que no sabe de StringBuilder

Answer 2

No todo el mundo lee lo más ampliamente que :-)

sólo estoy medio en broma. Las personas copian código y patrones todo el tiempo. Muchas personas no se mantienen en contacto con los cambios de API.

¿Por qué StringBuffer está obsoleto? Porque en la gran mayoría de los casos, su comportamiento sincronizado no es necesario. No puedo pensar en un momento en el que lo haya necesitado alguna vez. A pesar de que la sincronización no es ahora el problema de rendimiento que alguna vez fue, tiene poco sentido pagar ese impuesto en escenarios donde no es necesario.

Answer 3

¿Por qué la clase StringBuffer ahora está obsoleta?

Porque sus operaciones están sincronizadas, lo que agrega sobrecarga y rara vez es útil.

La razón por la que todavía ve StringBuffer utilizado ampliamente es simplemente la inercia: Todavía hay incontables ejemplos de código tutoriales por ahí que nunca se actualiza para utilizar StringBuilder, y la gente todavía aprenden prácticas obsoletas (no sólo éste), a partir de dichas fuentes. E incluso las personas que saben mejor a menudo recurren a viejos hábitos.

Answer 4

No solo no se requiere sincronización en la mayoría de los casos, en realidad le da a los lectores de su código información incorrecta si la usa: es posible que el lector crea que la sincronización es necesaria donde en realidad no lo es.

En su lugar, el uso de un StringBuilder anuncia el hecho de que no espera el acceso entre subprocesos.

De hecho, el envío de datos a través de subprocesos casi siempre debe hacerse a través de canales de comunicación bien definidos de todos modos, no simplemente accediendo a un búfer de cadena sincronizado. Así que de alguna manera recomendaría siempre usando una solución diferente, incluso cuando un StringBuffer parece apropiado a primera vista.

Answer 5

Creo que obsoleto es una exageración.

StringBuffer está sincronizado. StringBuilder no lo es.

En muchos casos (tal vez la mayoría), no le importará la seguridad del hilo de algo utilizado para construir cadenas. Deberías usar StringBuilder en estos casos. En algunos casos, sin embargo, es posible que desee asegurarse de que las acciones en el objeto sean seguras para subprocesos. StringBuffer sigue siendo útil en esos casos.