StringBuffer устарел? - PullRequest
       32

StringBuffer устарел?

50 голосов
/ 21 июля 2011

В книге «Эффективная Ява» Джош Блох говорит, что

StringBuffer в значительной степени устарел и должен быть заменен несинхронизированная реализация 'StringBuilder'

.

Но по моему опыту я все еще видел широкое использование класса StringBuffer. Почему класс StringBuffer теперь устарел и почему StringBuilder следует отдавать предпочтение StringBuffer, за исключением повышения производительности из-за отсутствия синхронизации?

Ответы [ 5 ]

68 голосов
/ 21 июля 2011

В этом новом коде на Java 1.5 устарел, как правило, следует использовать StringBuilder - очень редко, когда вам действительно нужно создавать строки в поточно-ориентированном режиме, так почемузаплатить стоимость синхронизации?

Я подозреваю, что код, который вы видите с помощью StringBuffer, в основном попадает в следующие сегменты:

  • Написано до Java 1.5
  • Написано для поддержки совместимостис более старыми JDK
  • Написано людьми, которые не знают о StringBuilder
  • Автоматически сгенерированы инструментами, которые не знают о StringBuilder
19 голосов
/ 21 июля 2011

Не все читают так широко, как вы: -)

Я только наполовину шучу.Люди постоянно копируют код и шаблоны.Многие люди не остаются на связи с изменениями API.

Почему StringBuffer устарел?Потому что в подавляющем большинстве случаев его синхронизированное поведение не требуется.Я не могу вспомнить время, когда мне это было нужно.Несмотря на то, что синхронизация не является проблемой производительности, которой она когда-то была, нет смысла платить этот налог в тех случаях, когда это не нужно.

9 голосов
/ 21 июля 2011

Почему класс StringBuffer теперь устарел?

Поскольку его операции синхронизированы, что увеличивает накладные расходы и редко используется.

Причина, по которой вы все еще видите *Широко используемый 1007 * - это просто инерция: по-прежнему существует бесчисленное множество примеров учебников, которые никогда не обновлялись для использования StringBuilder, и люди все еще изучают устаревшие практики (не только эту) из таких источников.И даже люди, которые знают лучше, часто возвращаются к старым привычкам.

5 голосов
/ 21 июля 2011

Я думаю, что устаревшее - это преувеличение.

StringBuffer синхронизируется. StringBuilder нет.

Во многих (может быть, в большинстве) случаях вас не волнует безопасность потоков для чего-то, что используется для построения строк. Вы должны использовать StringBuilder в этих случаях. Однако в некоторых случаях вы вполне можете захотеть убедиться, что действия над объектом являются поточно-ориентированными. StringBuffer все еще полезен в этих случаях.

4 голосов
/ 21 июля 2011

Мало того, что синхронизация не требуется в большинстве случаев, она фактически дает читателям вашего кода неверную информацию, если вы все же используете ее: а именно, читатель может быть уверен, что синхронизация необходима там, где ее на самом деле нет.

Вместо этого StringBuilder объявляет тот факт, что вы не ожидаете многопоточного доступа.

Фактически, отправка данных между потоками почти всегда должна осуществляться через четко определенные каналы связи., а не просто путем доступа к синхронизированному строковому буферу.Таким образом, я бы рекомендовал всегда , используя другое решение, даже когда StringBuffer кажется уместным на первый взгляд.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...