Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

In a production web application, my fellow programmers used StringBuffer everywhere. Now I am taking care of application development and corrections. After reading StringBuilder and StringBuffer I have decided to replace all the StringBuffer code with StringBuilder because we don't need thread safety in our data beans.

For example: (In each data bean I can see the use of StringBuffer)

@Override
public String toString() {
    StringBuffer sb = new StringBuffer();// replace it from StringBuilder
    sb.append(" ABCD : ").append(abcd);
    sb.append(", EFGH : ").append(efgh);
    sb.append(", IJKL : ").append(ijkl);
}

We create a separate data beans for each session/request. A session is used by a single user no other user can access it.

Should I consider other points before migrating?

If there is a single thread (no waiting threads/no new thread will be looking for object lock), it performs equally with either StringBuffer or StringBuilder. I know in the case of StringBuffer, it takes time to take the object lock but I want to know if there is any performance difference between them except the hold/release of the object lock.

share|improve this question
4  
If you use sb as a local variable like in your example, then thread-safety doesn't matter at all. Even if a thousand threads simultaneously entered the method, each would have its own call stack with its own local variables. The StringBuilders would never interfere with each other. –  FredOverflow Aug 26 '12 at 9:33
add comment

2 Answers

up vote 14 down vote accepted

The only difference between the two is the synchronization used in StringBuffer. The overhead of synchronization is not huge in the grand scheme of things, but it is significant relative to the StringBuilder methods that don't have them. The JVM is doing work that it wouldn't otherwise have to do--especially with only one thread, etc.

If your code works and people aren't complaining about performance, I wouldn't worry about it. You aren't going to get a lot of bang for your buck. However, if you are writing new code, or are updating code that uses StringBuffer, I'd suggest converting them StringBuilder at the same time.

share|improve this answer
    
I'll add to this that you need to keep in mind the inherit thread safety of the two. StringBuilder is not thread safe. –  Martijn Verburg Aug 26 '12 at 8:22
2  
@MartijnVerburg True, altough it was pointed out in stackoverflow.com/questions/6775016/stringbuffer-is-obsolete/… that there are very few use cases requiring multiple threads to use the same instance of a String builder. –  Matthew Flynn Aug 26 '12 at 22:25
4  
@MartijnVerburg: it should also be noted: if you really need thread safety then chances are that StringBuffer is not sufficient either! It guarantees that it doesn't brake, but the position at which you append can't easily be controlled if multiple threads access it at once, so another external synchronization would be needed. –  Joachim Sauer Aug 27 '12 at 8:15
add comment

StringBuilder was added at a point (Java 1.5) to be a better and faster StringBuffer and the compiler uses it under the hood to implement the + operator on Strings.

This means that by using StringBuilder you cannot make your code run on JVM's older than when the class was introduced. This would be a problem to us, for a while yet. If you always run the latest, you don't need to care.

I would not go through the optimization process you go through, though for the following reasons.

  • Outside tight loops the advantage is negligible. Unless it explicitly shows up as a hotspot in a profiler, I wouldn't bother.
  • Changing code may introduce errors, and you must retest your application thoroughly. That may be a lot more expensive than living with a synchronized class in a non-synchronized setting.
share|improve this answer
    
I agree with you .. still not able to understand your point Outside tight loops the advantage is negligible... –  Satish Pandey Aug 26 '12 at 8:12
    
The mechanism which is missing in StringBuilder as opposed to StringBuffer is trading speed for thread security. That speed improvement is very small, so it only matters if it is done a lot of times - this is usually the case in a small loop being done many times. –  user1249 Aug 26 '12 at 9:06
add comment

protected by World Engineer Dec 25 '13 at 4:01

Thank you for your interest in this question. Because it has attracted low-quality answers, posting an answer now requires 10 reputation on this site.

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.