Question

While reading on Thread Safety I came across this issue.
If I’m correct method local Primitives and object references lives inside a stack and actual objects pointed by the references inside the stack lives in the heap.

But when it comes to method local non primitive object initialization, wouldn’t that cause a concurrency issue ? I mean if the method locals non primitives lives in the heap and only the pointers lives in the stacks, isn’t it the same as of instance variables ?

Can someone please help me to understand this….

PS

Think of two threads with each having two stacks of their own and one heap. What I understood is that the two threads keep their method local primitive variables inside their stacks. I have no issue with that.

But what if we have a method with non primitive method local variables ? Then if the object for that variable is stored inside the heap, both the threads will have the access to the same object, won’t they ? So if that’s the case there would be Sync problems.

That is what I’m asking.

Thanks

Answer 1

Both threads could have access to the same object if they both have a reference to the object. If you have a method like the following:

public String concat(String a, String b) {
    StringBuilder builder = new StringBuilder();
    builder.append(a);
    builder.append(b);
    return builder.toString();
}

The StringBuilder object is indeed in the heap, but only one thread has a reference to this object. No other thread can have a reference to this StringBuilder. So it’s inherently thread-safe.

If, on the contrary, you have the following:

public String concat(String a, String b) {
    final StringBuilder builder = new StringBuilder();
    new Thread(new Runnable() {
        @Override
        public void run() {
            builder.append("haha!");
        }
    }).start();
    builder.append(a);
    builder.append(b);
    return builder.toString();
}

Then you have a thread-safety issue, because you shere the locally created object reference with another thread, and StringBuilder is not thread-safe.