Over a million developers have joined DZone.
Platinum Partner

Why a synchronized StringBuffer was never a good idea

· Performance Zone

The Performance Zone is brought to you in partnership with AppDynamics. Discover five of the top performance metrics to capture to assess the health of your enterprise Java application.

Introduction

StringBuffer is a synchronized class for mutable strings.  The main problem with making it synchronized is that

  1. It was usually used as a local variable so making it synchronized just made it slower.
  2. 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 ;)




The Performance Zone is brought to you in partnership with AppDynamics.  Learn the essentials of APM and how to implement best practices of application performance, better understand what it means to capture, analyze, and react to performance problems as they arise, and more specifically with .NET applications. 

Topics:

Published at DZone with permission of Peter Lawrey , DZone MVB .

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}