Why a synchronized StringBuffer was never a good idea
Introduction
StringBuffer is a synchronized class for mutable strings. The main problem with making it synchronized is that- It was usually used as a local variable so making it synchronized just made it slower.
- It was never a good idea to use it in a multi-threaded way. This problem is that developers assumed that methods which used StringBuffer were themselves thread safe when they were not.
The problem with StringBuffer
This is an example from a real class which is used in production in many trading systems. It's not a commonly used but you might assume that StringBuffer gives you thread safety, when it doesn't.
private StringBuffer sb = new StringBuffer();
public void addProperty(String name, String value) {
if (value != null && value.length() > 0) {
if (sb.length() > 0) {
sb.append(',');
}
sb.append(name).append('=').append(value);
}
}
While individual calls are thread safe, multiple calls are not. It is almost impossible to find a good use for StringBuffer that doesn't involve multiple calls (including toString)
A puzzle
Imagine three threads call (in no particular order)
T1: addProperty("a", "b");
T2: addProperty("c", "d");
T3: sb.toString(); write a program which will generate every possible output of T3's sb.toString()
I found 89. With thread safety, you might reduce this to 4.
Note: if you used StringBuilder it would be worse, but at least you might not assume your method is thread safe when it is not. e.g. SimpleDateFormat uses StringBuffer ;)
dev
Strings
Production (computer science)
IT
Published at DZone with permission of Peter Lawrey. See the original article here.
Opinions expressed by DZone contributors are their own.