Представьте себе реальный параллельный сценарий, в котором следует использовать StringBuffer, а не StringBuilder?

Причина, по которой StringBuffer является потокобезопасным, заключается в том, что в те дни, когда была разработана первая версия java API, люди подходили к параллелизму иначе, чем сейчас. Преобладало мнение, что объекты должны быть потокобезопасными, потому что Java поддерживает потоки, и люди могут использовать любой класс JDK в нескольких потоках. Позже, когда Java начали оптимизировать по времени выполнения, стоимость этих ненужных блоков синхронизации стала проблемой, поэтому новые API разрабатывались без синхронизации. Еще позже JVM начала оптимизировать блокировки до такой степени, что неоспоримые блокировки стали практически бесплатными, что сделало все решение спорным.

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

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

class RemoteLogger implements Runnable, Appender {
    final StringBuffer buffer = new StringBuffer();

    void append(String s) {
        buffer.append(s);
    }

    public void run() {
        for (;;) {
            Thread.sleep(100);

            String message = buffer.toString();
            sendToServer(message);
            buffer.delete(0, message.length());
        }
    }
}

Простой ответ - НЕТ. ИМХО, нет здравой ситуации, когда вы бы использовали StringBuffer вместо StringBuilder или другого класса. Обеспечение потокобезопасности StringBuffer может сделать ваш код менее потокобезопасным, потому что люди ошибочно предполагают, что если вы использовали StringBuffer, ваш код является потокобезопасным, когда это не так.

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

Почему синхронизированный StringBuffer никогда не был хорошей идеей.< /а>

Действительно в любом месте, когда текстовый буфер может быть доступен одновременно.

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

Следующая программа иногда будет генерировать исключения при использовании StringBuilder, но никогда не будет генерировать исключение при использовании StringBuffer.

Программа:

public class StringBuilderConcurrent {
    static final StringBuilder sb = new StringBuilder(); // shared memory

    public static void main(String[] args) throws Exception {
        int NUM_WRITERS = 300;
        ArrayList<WriterThread> threads = new ArrayList<WriterThread>(NUM_WRITERS);
        for (int i = 0; i < NUM_WRITERS; i++) {
            WriterThread wt = new WriterThread("writerThread" + i);
            threads.add(wt);
            wt.start();
        }
        for (int i = 0; i < threads.size(); i++) {
            threads.get(i).join();
        }    
        System.out.println(sb);
    }

    public static class WriterThread extends Thread {
        public WriterThread(String name) {
            super(name);
        }
        public void run() {
            String nameNl = this.getName() + "\n";
            for (int i = 1; i < 20; i++) {
                sb.append(nameNl);
            }
        }
    };
}

Поскольку StringBuilder (sb) не является потокобезопасным, запись данных в sb несколькими потоками может привести к повреждению sb (например, появление неожиданных нулевых символов, чередование букв слова с буквами других слов). Также возможно, что внутреннее состояние sb станет настолько несогласованным, что может быть выдано исключение:

Exception in thread "writerThread0" java.lang.ArrayIndexOutOfBoundsException
    at java.lang.System.arraycopy(Native Method)
    at java.lang.String.getChars(String.java:854)
    at java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:391)
    at java.lang.StringBuilder.append(StringBuilder.java:119)
    at test.StringBuilderConcurrent$WriterThread.run(StringBuilderConcurrent.java:35)

Следующая программа идентична первой, за исключением того, что она использует StringBuffer вместо StringBuilder. Он никогда не столкнется с исключением ArrayIndexOutOfBoundsException.

public class StringBufferConcurrent {
    static final StringBuffer sb = new StringBuffer(); // shared memory

    public static void main(String[] args) throws Exception {
        int NUM_WRITERS = 300;
        ArrayList<WriterThread> threads = new ArrayList<WriterThread>(NUM_WRITERS);
        for (int i = 0; i < NUM_WRITERS; i++) {
            WriterThread wt = new WriterThread("writerThread" + i);
            threads.add(wt);
            wt.start();
        }
        for (int i = 0; i < threads.size(); i++) {
            threads.get(i).join();
        }

        System.out.println(sb);
    }

    public static class WriterThread extends Thread {
        public WriterThread(String name) {
            super(name);
        }
        public void run() {
            String nameNl = this.getName() + "\n";
            for (int i = 1; i < 20; i++) {
                sb.append(nameNl);
            }
        }
    };
}

Являются ли эти программы репрезентативными для проблемы «реального мира» — довольно субъективный вопрос. Я оставлю это суждение на усмотрение публики.