Why use StringBuilder? StringBuffer can work with multiple thread as well as one thread?

Question

Suppose our application have only one thread. and we are using StringBuffer then what is the problem?

I mean if StringBuffer can handle multiple threads through synchronization, what is the problem to work with single thread?

Why use StringBuilder instead?

Solution 1

StringBuffers are thread-safe, meaning that they have synchronized methods to control access so that only one thread can access a StringBuffer object's synchronized code at a time. Thus, StringBuffer objects are generally safe to use in a multi-threaded environment where multiple threads may be trying to access the same StringBuffer object at the same time.

StringBuilder's access is not synchronized so that it is not thread-safe. By not being synchronized, the performance of StringBuilder can be better than StringBuffer. Thus, if you are working in a single-threaded environment, using StringBuilder instead of StringBuffer may result in increased performance. This is also true of other situations such as a StringBuilder local variable (ie, a variable within a method) where only one thread will be accessing a StringBuilder object.

So, prefer StringBuilder because,

• Small performance gain.
• StringBuilder is a 1:1 drop-in replacement for the StringBuffer class.
• StringBuilder is not thread synchronized and therefore performs better on most implementations of Java

Check this out :

• Don't Use StringBuffer!
• StringBuffer vs. StringBuilder performance comparison

Solution 2

StringBuilder is supposed to be a (tiny) bit faster because it isn't synchronised (thread safe).

You can notice the difference in really heavy applications.

The StringBuilder class should generally be used in preference to this one, as it supports all of the same operations but it is faster, as it performs no synchronization.

http://download.oracle.com/javase/6/docs/api/java/lang/StringBuffer.html

Solution 3

Using StringBuffer in multiple threads is next to useless and in reality almost never happens.

Consider the following

Thread1: sb.append(key1).append("=").append(value1);
Thread2: sb.append(key2).append("=").append(value2);

each append is synchronized, but a thread can stoop at any point so you can have any of the following combinations and more

key1=value1key2=value2
key1key2==value2value1
key2key1=value1=value2
key2=key1=value2value1

This can be avoided by synchronizing the whole line at a time, but this defeats the point of using StringBuffer instead of StringBuilder.

Even if you have a correctly synchronized view, it more complicated than just creating a thread local copy of the whole line e.g. StringBuilder and log lines at a time to a class like a Writer.

Solution 4

StringBuffer is not wrong in a single-threaded application. It will work just as well as StringBuilder.

The only difference is the tiny overhead added by having all synchronized methods, which brings no advantage in a single-threaded application.

My opinion is that the main reason StringBuilder was introduced is that the compiler uses StringBuffer (and now StringBuilder) when it compiles code that contains String concatenation: in those cases synchronization is never necessary and replacing all of those places with an un-synchronized StringBuilder can provide a small performance improvement.

Solution 5

StringBuilder has a better performance because it's methods are not synchronized.

So if you do not need to build a String concurrently (which is a rather untypical scenarion anyway), then there's no need to "pay" for the unnecessary synchronization overhead.

View more solutions