StringBuilder либо StringBuffer.


Переиспользовать и очищать особого смысла нет.

В общем случае, переиспользование объектов ведёт к худшей производительности чем пересоздание.
Пересозданый ненужный объект быстро умирает в Eden, а когда допилят Escape Analysis, то будет умирать ещё раньше.
Переиспользуемый объект оседает в Tenured. Количество живых объектов в Tenured - основная проблема Java GC. Т.е. при каждой сборке этот объект будет проверятся.

ivanraразве что StringBuffer явно лишнее
В Java 7 - пофиг.

avp.mkЗалез в исходник AbstractStringBuilder, ivanra абсолютно прав - лучше чистить и повторно использовать.
Извольте объяснится.

ivanraне первый раз встречаю что в 7 synchronized должно работать быстрее.
Наверное потому что я в каждой второй теме про StringBuffer про это пишу.

ivanraНо каким образом? Операционка остается та же и процессор тот же. Отказались от системного вызова и реализовали свой? Есть ссылка на официальное сообщение?
JVM ассоциирует монитор с первым потоком, который его захватил. Все последующие обращения этого потока к монитору не приводят ни к какой синхронизации вообще. Просто идёт проверка "а это ты - проходи". Это вообще ничего не стоит.
А вот если вдруг другой поток подкрадется к монитору, то JVM "насторожится" и начнет использовано полноценный synchronized уже для всех потоков.
Поэтому StringBuffer вида сделал и выкинул, от StringBuilder уже почти ни чем не отличается. Конечно, какая-то минимальная, разница есть. Но она на столько мала, что на фоне вызовов методов, и других операций со StringBuilder, она не заметна.

avp.mkпорезаный java.lang.AbstractStringBuilder
Смотреть в исходники я и сам умею. Ткните пальцем почему очищение быстрее пересоздания? Имеется ввиду что что уже будет готов массив заданого размера? Так это изначальным capacity решается.

avp.mkПотому что создание и инициализация массива тоже чего-то стоит. (и времени и памяти).
При вызове sb.setLength(0); этого не происходит, только лишь значение поля count становится равным 0.
Эта экономия нивелирутся затратами GC на долгоживущий объект.

HoBTIDИ еще, не подскажете, почему на Android, где как раз очень важна производительность,
рекомендуют как раз переиспользовать объекты, а не пересоздавать?
allocating memory is always more expensive than not allocating memory
Потому что там иначе работает GC. Потому что там программы остро нуждаются в экономии памяти. Т.е. расход памяти там, в итоге, бъет по перфомансу сильнее.

HoBTIDПравильно ли я понял, что GC проще удалить 100 (1000, 1 000 000, сколько???) короткоживущих объектов,
чем 1 долгоживущий?
Дело не в том что "проще". А в том как это всё вообще работает.
Пересоздание - ОК. Потратили немного больше на allocation.
Вышли за пределы блока. Если escape analysis отработал успешно (а его, вроде, с каждой версией Java всё лучше допиливают).
Объект умер быстро своей смертью.
Даже без escape analysis он быстро уберется из Eden.
К вашему вопросу о количестве... - количество убираемых объектов влияет на производительность напорядки меньше чем количество найденых живых. GC сканирует именно живые объекты. Все которы мы создали и забыл, он просто не найдёт и удалит. Причем пачкой - что очень быстро.

Теперь если объекты переиспользовать. Мы же не говорим про Hello World, который ничего не делает, кроме как использует один единственный StringBuilder. Мы же говорим о некой, потенциально большой, системе? Если вы решили переиспользовать объекты, значит вы это будете делать не в одном месте. А во многих. Ведь вы считаете что это быстрее, чем создавать новые. Поэтому придерживаетесь этого подхода.
Таким образом ваш объект оседает в Eden, перемещается в survived и в конце-концов оседает в tenured. Ваш объект всегда нужен и всегда живой. Поэтому он сканируется при каждой сборке в Tenured. И влияет на производительность всей системы.

Мой ответ не претендует на полноценность, так как стоит рассмотреть альтернативные алгоритмы сборки, такие как G1.
Кроме этого, не исключено что в готовой системе можно и с массой объектов tenured свести работу к GC к минимум тонкими настройками. Но это всё индивидуально для каждого проекта.

HoBTIDМы же не сравниваем 1 короткоживущий и 1 долгоживущий.
Сравниваем, не понятно что, не понятно с чем. Я же говорю про общий случай. А вы всё пытаетесь свести к одному единственому, в котором переиспользование вдруг окажется быстрее. Конечно бывают варианты, когда переиспользование окажется выгоднее. Но это не значит что переиспользование выгодне во всех случаях.