Testing the difference between StringBuilder and StringBuffer

Question

I just want to see the difference between them visually, so below is the code. But it always fails. Can someone please help me on this? I have seen questions on SO too, but none of them have shown the difference programatically.

public class BBDifferencetest {
     protected static int testnum = 0;

     public static void testStringBuilder() {
             final StringBuilder sb = new StringBuilder();

             Thread t1 = new Thread() {

                     @Override
                     public void run() {
                             for (int x = 0; x < 100; x++) {
                                     testnum++;
                                     sb.append(testnum);
                                     sb.append(" ");                                
                             }
                     }
             };
             Thread t2 = new Thread() {

                     public void run() {

                             for (int x = 0; x < 100; x++) {
                                     testnum++;
                                     sb.append(testnum);
                                     sb.append(" ");
                             }
                     }
             };
             t1.start();
             t2.start();

             try {
                     t1.join();
                     t2.join();
             } catch (InterruptedException e) {
                     e.printStackTrace();
             }

             System.out.println("Result is: " + sb.toString());

        }

     public static void main(String args[]) {
             testStringBuilder();
     }
}

When I execute this, I get the output sometimes in a random manner, so this proves my test. But when I even replace StringBuilder with StringBuffer and test, even it gives me unexpected output(rather than sequential which from 1 to 200). So can someone help me getting to know the difference visually?

P.S : If anyone has your code which shows the difference, I would be very glad to accept it as an answer. Because I am not sure whether I can achieve the difference with my code even though it is modified.

Jon Skeet · Accepted Answer · 2013-03-08 05:00:29Z

(rather than sequential which from 1 to 200)

Each thread is performing a read, modify, write operation on testnum. That in itself is not thread-safe.

Then each thread is fetching the value of testnum again in order to append it. The other thread may well have interrupted by then and incremented the value again.

If you change your code to:

AtomicInteger counter = new AtomicInteger();
...
sb.append(counter.getAndIncrement());

then you're more likely to see what you expect.

To make it clearer, change your loops to only call append once, like this:

for (int x = 0; x < 100; x++) {
    sb.append(counter.incrementAndGet() + " ");
}

When I do that, for StringBuffer I always get "perfect" output. For StringBuilder I sometimes get output like this:

97 98 100    102     104

Here the two threads have both been appending at the same time, and the contents have been screwed up.

EDIT: Here's a somewhat shorter complete example:

import java.util.concurrent.atomic.AtomicInteger;

public class Test {

    public static void main(String[] args) throws InterruptedException {
        final AtomicInteger counter = new AtomicInteger();
        // Change to StringBuffer to see "working" output
        final StringBuilder sb = new StringBuilder();
        Runnable runnable = new Runnable() {
            @Override
            public void run() {
                for (int x = 0; x < 100; x++) {
                    sb.append(counter.incrementAndGet() + " ");
                }
            }
        };

        Thread t1 = new Thread(runnable);
        Thread t2 = new Thread(runnable);
        t1.start();
        t2.start();
        t1.join();
        t2.join();
        System.out.println(sb);
    }
}

Sorry, this test didn't work. Can you please suggest another way?
@Sam: "didn't work" is far too vague for me to help you. Please be more precise.
I tested this way, it didn't show me any difference. In both cases I am getting non-synchronized output sometimes when I test with StringBuilder and StringBuffer.
@Sam: "non-synchronized" in what sense? You'll sometimes get spaces missing or together with your current code, because you're calling append twice (and the threads can switch between calls). See my edited answer for a short but complete example which does demonstrate the difference, at least on my machine.
Thank you so much. Your answer is working now and I have run it >10 times. Can you please explain in the answer why StringBuffer object also switches from one thread to another though it is supposed to provide access to only one thread at a time as per my understanding and why I need to use AtomicInteger? so that it would be helpful for even future readers. BTW you are a hero in java ;)

Cyrille Ka · Accepted Answer · 2013-03-08 05:03:59Z

StringBuffer is synchronized at the method level. It means that noone can enter one of his methods if a thread is already in one of his method. But it does not guarantee that one thread will be blocked to use StringBuilder at all as long as the other thread uses it, and so the two threads will still compete for access to methods, and you may have randomly a non-ordered result.

The only way to really lock an access to the StringBuffer is to put the code that access it in a synchronized block:

public void run() {
    synchronized(sb) {
        for (int x = 0; x < 100; x++) {
           testnum++;
           sb.append(testnum);
           sb.append(" ");                                
        }
    }
}

If you don't do that, then Thread 1 can go into sb.append(testnum) and Thread 2 will wait at the entry of it, and when Thread 1 goes out, Thread 2 can potentially go inside and starts to write before Thread 1 enters sb.append(" "). So you would see:

12 13 1415  16 ....

The thing is, locking like this will make things work for StringBuilder also. That's why one could say that the synchronization mechanism on StringBuffer is quite useless, and therefore why it's not used anymore (the same thing for Vector).

So, doing this way can not show you the difference between StringBuilder and StringBuffer. The suggestion in Jon Skeet answer is better.

Can you please elaborate with necessary code? So that I can check by replacing the StringBuffer with StringBuilder to check for the non-synchronized output.

Eric Haynes · Accepted Answer · 2013-03-08 05:17:38Z

+1 for what Cyrille said. I imagine that it is only the nature of arrays of inherently atomic types (primitives <= 32 bit) that saves you from get a ConcurrentModificationException with the StringBuilder as you would with, say, appending to a List<Integer>

Basically, you have two threads, each 100 individual operations. The two compete for lock of the object before each append, and release it afterwards, 100 times each. The thread that wins on each iteration will be randomized by the (extremely) small amount of time taken to increment the loop counter and testnum.

More exemplary of the difference from your example is not necessarily the ordering, but ensuring that all insertions are actually accounted for when using a StringBuilder. It has no internal synchronization, so it's entirely possible that some will get munged or overwritten in the process. The StringBuffer will handle this with internal synchronization guaranteeing that all inserts make it in properly, but you'll need external synchronization such as Cyrille's example above to hold a lock for the entire iteration sequence of each thread to safely use a StringBuilder.

Collectives™ on Stack Overflow

Testing the difference between StringBuilder and StringBuffer

3 Answers 3

6 Comments

1 Comment

Comments

Hot Network Questions

Collectives™ on Stack Overflow

3 Answers 3

6 Comments

1 Comment

Comments

Related