Java StringBuilder and Thread Safety

Question

I am building up a String out of multiple pieces and want to use either StringBuffer or StringBuilder to do so. From the Java 5 docs, I see that StringBuilder is preferred when possible, with the caveat that

Instances of StringBuilder are not safe for use by multiple threads.

From this statement, I understand that I should not have a single StringBuilder instance shared by multiple threads. But what about this case:

//Is this safe?
//foo() is called simultaneously by multiple threads
String foo(String a, String b) {
    return new StringBuilder(a).append(b).toString();
}

Here there could be multiple threads in the function at the same time, using the StringBuilder class at the same time (eg, concurrent access of static variables, if there are any), but each thread would have its own separate instance of StringBuilder. From the documentation, I can not quite decide whether this counts as use by multiple threads or not.

there might be some benefit in making foo() a static method as well, since it doesn't touch any instance variables. — Kip
– Kip, Commented Mar 10, 2009 at 18:30
@Kip: Depends on the class. But some times you may want to perform polymorphic operations and making the method static will imped this. — OscarRyz
– OscarRyz, Commented Mar 10, 2009 at 18:33
Using String.concat would faster, but I think this is just an example. — Tom Hawtin - tackline
– Tom Hawtin - tackline, Commented Mar 10, 2009 at 18:35
might be useful: How do I prove programmatically that StringBuilder is not threadsafe? — Andrew
– Andrew, Commented Feb 19, 2018 at 10:24

Michael Myers · Accepted Answer · 2009-03-10 18:28:23Z

19

That's perfectly fine. Local variables have no problems with thread safety as long as they don't access or mutate instance or class variables.

answered Mar 10, 2009 at 18:28

Michael Myers♦

193k47 gold badges301 silver badges297 bronze badges

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

Comments

Kip · Accepted Answer · 2009-03-10 18:48:42Z

11

Yes, that is safe, because the StringBuilder object is used only locally (each thread calling foo() will generate its own StringBuilder).

You should also note that the code you posted is practically identical to the bytecode generated by this:

String foo(String a, String b) {
    return a + b;
}

edited Mar 10, 2009 at 18:48

answered Mar 10, 2009 at 18:29

Kip

110k87 gold badges243 silver badges268 bronze badges

3 Comments

Kip Over a year ago

see also: stackoverflow.com/questions/272535/…

Kip Over a year ago

well ok not identical, it has one extra instruction.. the compiler converts + operator to: new StringBuilder().append(a).append(b);

djangofan Over a year ago

Woah! I wouldn't have believed that unless I tried it. The only difference is there is additonal .append call in this answer, one for each argument. Hmm.

Mr.Q · Accepted Answer · 2014-06-02 05:29:21Z

The code you have is safe.

This code is not.

public class Foo
{
    // safe
    private final static StringBuilder builder;

    public static void foo()
    {
        // safe
        builder = new StringBuilder();
    }

    public static void foo(final String a)
    {
        // unsafe
        builder.append(a);
    }

    public synchronized void bar(final String a)
    {
        // safe
        builder.append(a);
    }
}

Local variables that only make use of local data do not have threadsafe issues. You can only have threadsafe issues once you start dealing with data that is visible at the class or instance method/variable level.

Bill K · Accepted Answer · 2009-03-10 18:32:49Z

4

Agree with the other answers--just a note.

If there was a case where StringBuffer was being used by multiple threads, it's probably a completely broken use case because it would mean a single string was being built up in a quasi-random order, so it wouldn't make sense to make StringBuffer thread safe.

answered Mar 10, 2009 at 18:32

Bill K

62.9k19 gold badges113 silver badges158 bronze badges

8 Comments

OscarRyz Over a year ago

That's the rationale of StringBuilder. Most of the times the synchronization was not needed.

Steve B. Over a year ago

Yes, which makes you wonder why they didn't just rewrite StringBuffer instead of creating the parallel StringBuilder. To keep backwards compatibility for that app that builds nondeterministic strings?

Kip Over a year ago

Maybe if you were using a StringBuilder for some kind of in-memory logging of a multithreaded app? Not sure why you'd do that though...

Bill K Over a year ago

@Kip That's the only thing I could come up with either, and when I tried to justify it, it seemed like a broken use case which fit my original statement so I left it out :)

kjb Over a year ago

There is memory overhead for every object in those lists. A StringBuffer allows you to cut down on memory usage in lieu of more synchronized calls.

|

ReneS · Accepted Answer · 2009-03-10 18:38:01Z

3

I am not sure if this code is needed, because Java picks the StringBuilder automatically I guess. If you do not have a performance problem, go with a + b.

In case of a performance need, try that:

return new StringBuilder(
a.length() + b.length()).append(a).append(b).toString();

It correctly sizes the buffer and prevents the VM from resizing it and creating garbage to collect on the way.

answered Mar 10, 2009 at 18:38

ReneS

3,5652 gold badges29 silver badges36 bronze badges

Collectives™ on Stack Overflow

Java StringBuilder and Thread Safety

5 Answers 5

Comments

3 Comments

Comments

8 Comments

Comments

Linked

Hot Network Questions

Collectives™ on Stack Overflow

5 Answers 5

Comments

3 Comments

Comments

8 Comments

Comments

Linked

Related