StringBuffer est obsolète?

Question

Dans le livre "Effective Java", Josh Bloch dit que

StringBuffer est en grande partie obsolète et devrait être remplacé par l'implémentation non synchronisée 'StringBuilder'

.

Mais selon mon expérience, j'ai encore constaté une utilisation généralisée de la classe StringBuffer. Pourquoi la classe StringBuffer est-elle maintenant obsolète et pourquoi StringBuilder devrait-il être préféré à StringBuffer, à l'exception des performances accrues dues à la non-synchronisation?

Answer 1

C'est obsolète dans ce nouveau code Java 1.5 utiliser StringBuilder - il est très rare que vous avez vraiment besoin de construire des chaînes de caractères dans un thread-safe manière, alors pourquoi payer le coût de la synchronisation?

Je soupçonne que le code que vous voyez à l'aide de StringBuffer tombe surtout dans des compartiments de:

• Écrit avant de Java 1.5
• Écrit pour maintenir la compatibilité avec les anciens Jdk
• Écrit par des gens qui ne savent pas à propos de StringBuilder
• Généré automatiquement par des outils qui ne savent pas à propos de StringBuilder

Answer 2

Tout le monde ne lit pas autant que vous :-)

Je plaisante à moitié. Les gens copient le code et les modèles tout le temps. De nombreuses personnes ne restent pas en contact avec les modifications apportées aux API.

Pourquoi StringBuffer est-il obsolète? Parce que dans la grande majorité des cas, son comportement synchronisé n'est pas requis. Je n'arrive pas à penser à une fois où j'en ai eu besoin. Bien que la synchronisation ne soit plus le problème de performances actuel, il n’a guère de sens de payer cette taxe dans des scénarios où elle est inutile.

Answer 3

Pourquoi la classe StringBuffer maintenant obsolète?

Parce que ses activités sont synchronisés, ce qui ajoute de la surcharge et il est rarement utile.

La raison pour laquelle vous voyez toujours des StringBuffer largement utilisé est tout simplement l'inertie: Il y a encore d'innombrables exemples de code tutoriels là-bas qui n'ont jamais été mis à jour pour utiliser StringBuilder, et les gens encore apprendre des pratiques dépassées (et pas seulement celui-ci) à partir de ces sources. Et même les gens qui savent mieux souvent revenir à leurs vieilles habitudes.

Answer 4

Je pense que obsolète est une exagération.

StringBuffer est synchronisé. StringBuilder n'est pas.

Dans de nombreux cas (peut-être dans la plupart des cas), vous ne vous souciez pas de la sécurité d'un thread utilisé pour construire des chaînes. Vous devez utiliser StringBuilder dans ces cas. Dans certains cas, cependant, vous pouvez très bien vouloir vous assurer que les actions sur l'objet sont thread-safe. StringBuffer est toujours utile dans ces cas.

Answer 5

Non seulement la synchronisation n'est pas nécessaire dans la plupart des cas, il donne en fait les lecteurs de votre code de fausses informations, si toutefois vous l'utiliser: à savoir, le lecteur pourrait être amené à croire que la synchronisation est nécessaire, là où il ne l'est pas.

À l'aide d'un StringBuilder au lieu de cela fait de la publicité le fait que vous ne vous attendez pas cross-thread d'accès.

En fait, l'envoi de données à travers les threads doivent presque toujours être fait par le biais des canaux bien définis de la communication de toute façon, pas simplement en accédant à un synchronisée tampon de chaîne. Donc dans un sens je le recommande toujours à l'aide d'une solution différente, même si une StringBuffer semble approprié au premier coup d'œil.