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?

Answer 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

Answer 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