15

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.

Improve this question
3
  • 9
    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. Commented Aug 26, 2012 at 9:33
  • I'we always wondered who wants to synchronize two threads along something like the interface of a StringBuffer. I've never seen code like that but I'm almost sure it's a bad design from a multithreading perspective. Since I think synchronizing thread along the StringBuffer interface is a bad idea I think this class shouldn't exist and one should always use StringBuilder. As others already mentioned, StringBuffer exists for historical reasons. Commented Jul 15, 2016 at 16:01
  • might be useful: How do I prove programmatically that StringBuilder is not threadsafe? Commented Feb 19, 2018 at 10:15

2 Answers 2

Reset to default
24

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.

Improve this answer
3
  • I'll add to this that you need to keep in mind the inherit thread safety of the two. StringBuilder is not thread safe. Commented Aug 26, 2012 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. Commented Aug 26, 2012 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. Commented Aug 27, 2012 at 8:15
9

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.
Improve this answer
2
  • I agree with you .. still not able to understand your point Outside tight loops the advantage is negligible... Commented Aug 26, 2012 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. Commented Aug 26, 2012 at 9:06

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.