Imagine a real concurrent scenario where StringBuffer should be used than StringBuilder?

Question

I know the difference between StringBuffer and StringBuilder. read here!

And generally, as the javadoc says,

Where possible, it is recommended that this class be used in preference to StringBuffer as it will be faster under most implementations.

But, the javadoc of StringBuilder also says:

Instances of StringBuilder are not safe for use by multiple threads. If such synchronization is required then it is recommended that {@link java.lang.StringBuffer} be used

So, I am wondering, is the case that StringBuffer is preferred really existed? And as the mutable string is used mostly in a single thread, can anyone give me an concurrent real-world scenario that StringBuffer is preferred?

Answer 1

The reason StringBuffer is thread-safe is that back in the day when the first version of the java api was designed, people approached concurrency differently than nowadays. The prevailing opinion was that objects should be thread safe - because Java supports threads, and people might use any JDK class in multiple threads. Later, when Java was starting to be optimized for execution time, the cost of those needless synchronization blocks started to become a problem, so newer APIs were designed to not be synchronized. Still later, the JVM started to optimize locks to the point that uncontested locks became essentially free, making the entire decision a moot point.

StringBuffer is still thread-safe, because old code might rely on it being thread-safe. That is far from typical use, but conceivable.

For instance, suppose you were writing a logfile appender that forwards log entries to a central server. Since we don't want to block the caller while waiting for network I/O we do that in a dedicated thread. The other threads would accumulate their log entries in a 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());
        }
    }
}

Answer 2

The simple answer is NO. IMHO there is no sane situation where you would use StringBuffer instead of StringBuilder or another class. Making StringBuffer thread safe can make your code less thread safe because people mistakenly assume that if you have used StringBuffer you code is thread safe when this is not the case.

If you have used StringBuffer, at some point you have to use synchronized, although where is not always clear to most developers, and I have seen many bugs where this (even in mature libraries) wasn't done or wasn't done correctly. It is much better you use StringBuilder and do the locking enternally, consistently.

Why a synchronized StringBuffer was never a good idea.

is the case that StringBuffer is preferred really existed

There is one use case; you have a library which only accepts StringBuffer in the API. This is poor design for the reason mentioned above, but not library is perfect. ;)