This benchmark was vetted by several people over a period of a couple of months http://www.infoq.com/articles/java-threading-optimizations-p1.

Kirk

It’s only an issue if you reuse StringBuffers/-Builders stored in member variables.

Usually you don’t reuse StringBuffers/-Builders. You create them in local scope and forget about them when leaving a method, like this:

public String toString() {
// Creating objects is very, very cheap.
return new StringBuilder()
.append(name)
.append(“=”)
.append(value)
.toString();
}

the several threads scenario: you have several threads building a string with a single StringBuffer … this can’t be good. The resulting string is not determined. You need external synchronisation to avoid race conditions. But if you synchronize the access to StringBuffer you should use StringBuilder instead.

@Wanja:
Your first statement is slightly misleading. If you’re actually concatenating hard-coded strings, the compiler doesn’t convert it to a StringBuilder, it actually converts it directly to a string, as the compiler can do the entire computation at compile time.

Concerning the several comments about thread safety:
I think it’s very unlikely the “lack of thread safety” of StringBuilder would ever be an issue for anyone. This would be an issue if you had the same StringBuilder instance being accessed by multiple threads at the same time. This would be a very odd situation.

// The compiler takes care of this with StringBuilder for you.
String s = “asdfa” + “Asdfwe2234″ + someOtherStringObject;

// The compiler can’t figure this out, so use StringBuilder.
String output = “base”
for ( String s : SomeList )
{
output = output + s;
}