Какой реальный пример использования StringBuffer?

Question

Я использую Java 6.

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

Может ли кто-нибудь привести пример из реальной жизни, когда StringBuffer может быть полезен?

Спасибо.

РЕДАКТИРОВАТЬ: Извините, я думаю, что я не достаточно ясно. Я всегда использую StringBuilder, потому что в моих приложениях только один поток обращается к строке за раз. Поэтому мне было интересно, какой сценарий требует одновременного доступа к StringBuffer для нескольких потоков.

Answer 1

Единственный пример из реальной жизни, о котором я могу подумать, - это если вы ориентируетесь на версии Java, предшествующие 1.5.Класс StringBuilder был введен в версии 1.5, поэтому для более старых версий вместо него следует использовать StringBuffer.

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

На самом деле кажется, что даже авторы библиотеки Java признают, что StringBuffer была ошибкой :

Оценка командой библиотек:

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

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

Также стоит отметить, что библиотека базовых классов .NET, в значительной степени вдохновленная библиотеками Java, имеет StringBuilder класс, но нет StringBuffer, и я никогда не видел, чтобы кто-то жаловался на это.

Answer 2

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

Answer 3

StringBuffer - очень популярный выбор среди программистов.

Он имеет преимущество перед стандартными объектами String в том, что он не является неизменным объектом. Поэтому, если значение добавляется к StringBuffer, новый объект не создается (как это было бы с String), а просто добавляется в конец.

Это дает StringBuffers (в определенных ситуациях, которые не могут быть компенсированы компилятором) преимущество в производительности.

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

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

StringBuilder рекомендуется использовать вместо StringBuffer в однопоточных приложениях, однако, из-за увеличения производительности (или, если посмотреть на это наоборот, из-за снижения производительности StringBuffer).

Answer 4

Как правило, эти типы буферизованных строковых объектов полезны при динамическом построении строк.Они пытаются свести к минимуму объем выделения и освобождения памяти, который создается, когда вы постоянно добавляете строки фиксированного размера вместе.

Итак, на примере реального мира представьте, что вы вручную создаете HTML для страницы, где вы делаетепримерно 100 строкЕсли бы вы делали это с неизменяемыми строками, виртуальная машина JAVA занималась бы довольно небольшим распределением и освобождением памяти, тогда как с StringBuffer это делало бы намного меньше.