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?
StringBuffer
is not wrong in a single-threaded application. It will work just as well asStringBuilder
.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 usesStringBuffer
(and nowStringBuilder
) when it compiles code that containsString
concatenation: in those cases synchronization is never necessary and replacing all of those places with an un-synchronizedStringBuilder
can provide a small performance improvement.There is a huge cost to synchronize objects. Don't see a program as a standalone entity; its not a problem when you are reading the concepts and applying them on small programs like you have mentioned in your question details, the problems arise when we want to scale the system. In that case your single threaded program might be dependent on several other methods/programs/entities, so synchronized objects can cause a serious programming complexity in terms of performance. So if you are sure that there is no need to synchronize an object then you should use StringBuilder as it is a good programming practice. At the end we want to learn programming to make scalable high performance systems, so that is what we should do!
Using StringBuffer in multiple threads is next to useless and in reality almost never happens.
Consider the following
each append is synchronized, but a thread can stoop at any point so you can have any of the following combinations and more
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.
This will help u guys, Be Straight Builder is faster than Buffer,
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.
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,Check this out :