How do I prove programmatically that StringBuilder is not threadsafe?
How do I prove programmatically that StringBuilder
is not threadsafe?
I tried this, but it is not working:
public class Threadsafe {
public static void main(String[] args) throws InterruptedException {
long startdate = System.currentTimeMillis();
MyThread1 mt1 = new MyThread1();
Thread t = new Thread(mt1);
MyThread2 mt2 = new MyThread2();
Thread t0 = new Thread(mt2);
t.start();
t0.start();
t.join();
t0.join();
long enddate = System.currentTimeMillis();
long time = enddate - startdate;
System.out.println(time);
}
String str = "aamir";
StringBuilder sb = new StringBuilder(str);
public void updateme() {
sb.deleteCharAt(2);
System.out.println(sb.toString());
}
public void displayme() {
sb.append("b");
System.out.println(sb.toString());
}
}
class MyThread1 implements Runnable {
Threadsafe sf = new Threadsafe();
public void run() {
sf.updateme();
}
}
class MyThread2 implements Runnable {
Threadsafe sf = new Threadsafe();
public void run() {
sf.displayme();
}
}
Solution 1:
Problem
I am afraid the test you have written is incorrect.
The main requirement is to share the same StringBuilder
instance between different threads. Whereas you are creating a StringBuilder
object for each thread.
The problem is that a new Threadsafe()
initialises a new StringBuilder()
:
class Threadsafe {
...
StringBuilder sb = new StringBuilder(str);
...
}
class MyThread1 implements Runnable {
Threadsafe sf = new Threadsafe();
...
}
class MyThread2 implements Runnable {
Threadsafe sf = new Threadsafe();
...
}
Explanation
To prove the StringBuilder
class is not thread-safe, you need to write a test where n
threads (n > 1
) append some stuff to the same instance simultaneously.
Being aware of the size of all the stuff you are going to append, you will be able to compare this value with the result of builder.toString().length()
:
final long SIZE = 1000; // max stream size
final StringBuilder builder = Stream
.generate(() -> "a") // generate an infinite stream of "a"
.limit(SIZE) // make it finite
.parallel() // make it parallel
.reduce(new StringBuilder(), StringBuilder::append, (b1, b2) -> b1);
// put each element in the builder
Assert.assertEquals(SIZE, builder.toString().length());
Since it is actually not thread-safe, you may have trouble getting the result.
An ArrayIndexOutOfBoundsException
may be thrown because of the char[] AbstractStringBuilder#value
array and the allocation mechanism which was not designed for multithreading use.
Test
Here is my JUnit 5 test which covers both StringBuilder
and StringBuffer
:
public class AbstractStringBuilderTest {
@RepeatedTest(10000)
public void testStringBuilder() {
testAbstractStringBuilder(new StringBuilder(), StringBuilder::append);
}
@RepeatedTest(10000)
public void testStringBuffer() {
testAbstractStringBuilder(new StringBuffer(), StringBuffer::append);
}
private <T extends CharSequence> void testAbstractStringBuilder(T builder, BiFunction<T, ? super String, T> accumulator) {
final long SIZE = 1000;
final Supplier<String> GENERATOR = () -> "a";
final CharSequence sequence = Stream
.generate(GENERATOR)
.parallel()
.limit(SIZE)
.reduce(builder, accumulator, (b1, b2) -> b1);
Assertions.assertEquals(
SIZE * GENERATOR.get().length(), // expected
sequence.toString().length() // actual
);
}
}
Results
AbstractStringBuilderTest.testStringBuilder:
10000 total, 165 error, 5988 failed, 3847 passed.
AbstractStringBuilderTest.testStringBuffer:
10000 total, 10000 passed.
Solution 2:
Much simpler:
StringBuilder sb = new StringBuilder();
IntStream.range(0, 10)
.parallel()
.peek(sb::append) // don't do this! just to prove a point...
.boxed()
.collect(Collectors.toList());
if (sb.toString().length() != 10) {
System.out.println(sb.toString());
}
There will be no order of the digits (they will not be 012...
and so on), but this is something you don't care about. All you care is that not all the digits from range [0..10]
where added to StringBuilder
.
On the other hand if you replace StringBuilder
with StringBuffer
, you will always get 10 elements in that buffer (but out of order).