Java: Thread safety with StringBuilder

Question

I have a scenario where I want to use StringBuilder as a local variable in a method. I understand if StringBuilder is a local method variable it should not have any problems about thread-safety.

However, if I append to the StringBuilder an instance variable like:

class MyClass {
    private List<String> property;

    public void myMethod() {
        StringBuilder sb = new StringBuilder();
        for(String s : property) {
            sb.append(s);
        }
    }

    // some other methods that mutate property
}

I think to make this thread-safe, simply change the StringBuilder to StringBuffer is not sufficient. Shall I synchronize on the property itself?

what is my method doing? seems it's creating a StringBuilder object and throwing it away... — stivlo
– stivlo, Commented Jun 4, 2013 at 13:20
You need to synchronize the access to the List, not the StringBuilder — user330315
– user330315, Commented Jun 4, 2013 at 13:20
might be interesting: How do I prove programmatically that StringBuilder is not threadsafe? — Andrew
– Andrew, Commented Feb 19, 2018 at 10:30

Andrew · Accepted Answer · 2018-02-19 10:29:26Z

8

It's not StringBuilder but List<String> property who is in danger. You have two options:

Make myMethod and other methods that mutate property synchronized
Use java.util.concurrent.CopyOnWriteArrayList which is thread safe and makes a snapshot for iterator

edited Feb 19, 2018 at 10:29

Andrew

49.8k15 gold badges99 silver badges145 bronze badges

answered Jun 4, 2013 at 13:22

Evgeniy Dorofeev

137k31 gold badges208 silver badges288 bronze badges

Sign up to request clarification or add additional context in comments.

1 Comment

Sanjay T. Sharma Over a year ago

Just an FYI for the OP: if you plan on making a lot of updates, be wary of the CopyOnWriteArrayList approach; in that case you would be better off going with option 1.

Caesar Ralf · Accepted Answer · 2013-06-04 13:30:58Z

The problem is that while you are calling yours myMethod(), another thread can be adding new String to yours property list, thus, modifying the result.

One way to avoid this is using synchronized in the methods that access property in any way, or you can use the good old ReadWriteLock. The implementation most used is the ReentrantReadWriteLock. There are good examples in the internet, but what you would do is something like:

class MyClass {
    private final ReadWriteLock propertiesLock = new ReentrantReadWriteLock();
    private final Lock read = propertiesLock.readLock();
    private final Lock write = propertiesLock.writeLock();
    ... 

    public StringBuilder myMethod() {
        StringBuilder builder = new StringBuilder();
        read.lock();
        try {
           // your writing here.
        } finally {
            read.unlock();
        }
        return builder;
    }

    public void addProperty(String property) {
        write.lock();
        try {
            properties.add(property);
        } finally {
            write.unlock();
        }
    }
}

Joonas Pulakka · Accepted Answer · 2013-06-04 13:24:14Z

3

You can synchronize on property, or on any object, as long as you synchronize on the same object in wherever you access property.

An alternative to synchronization would be using a thread-safe implementation of List, such as CopyOnWriteArrayList, which is great (fast, less contention than with synchronization) if the list is read often but not modified too often.

answered Jun 4, 2013 at 13:24

Joonas Pulakka

36.6k29 gold badges109 silver badges171 bronze badges

Comments

joaonlima · Accepted Answer · 2013-06-04 13:22:35Z

2

It seems that the synchronize issue lies on property.

So just add a synchronization on it:

synchronized (property) {
   ...
}

answered Jun 4, 2013 at 13:22

joaonlima

6285 silver badges15 bronze badges

Collectives™ on Stack Overflow

Java: Thread safety with StringBuilder

4 Answers 4

1 Comment

Comments

Comments

Comments

Linked

Hot Network Questions

Collectives™ on Stack Overflow

4 Answers 4

1 Comment

Comments

Comments

Comments

Linked

Related