Java Language ThreadLocal Multiple threads with one shared object
In this example we have only one object but it is shared between/executed on different threads. Ordinary usage of fields to save state would not be possible because the other thread would see that too (or probably not see).
In Foo we count starting from zero. Instead of saving the state to a field we store our current number in the ThreadLocal object which is statically accessible. Note that the synchronization in this example is not related to the usage of ThreadLocal but rather ensures a better console output.
public class Foo implements Runnable < private static final int ITERATIONS = 10; private static final ThreadLocalthreadLocal = new ThreadLocal() < @Override protected Integer initialValue() < return 0; >>; @Override public void run() < for (int i = 0; i < ITERATIONS; i++) < synchronized (threadLocal) < //Although accessing a static field, we get our own (previously saved) value. int value = threadLocal.get(); System.out.println(Thread.currentThread().getName() + ": " + value); //Update our own variable threadLocal.set(value + 1); try < threadLocal.notifyAll(); if (i < ITERATIONS - 1) < threadLocal.wait(); >> catch (InterruptedException ex) < >> > > > From the output we can see that each thread counts for itself and does not use the value of the other one:
Thread 1: 0 Thread 2: 0 Thread 1: 1 Thread 2: 1 Thread 1: 2 Thread 2: 2 Thread 1: 3 Thread 2: 3 Thread 1: 4 Thread 2: 4 Thread 1: 5 Thread 2: 5 Thread 1: 6 Thread 2: 6 Thread 1: 7 Thread 2: 7 Thread 1: 8 Thread 2: 8 Thread 1: 9 Thread 2: 9 
PDF — Download Java Language for free
Thread Safety and Shared Resources
Code that is safe to call by multiple threads simultaneously is called thread safe. If a piece of code is thread safe, then it contains no race conditions. Race condition only occur when multiple threads update shared resources. Therefore it is important to know what resources Java threads share when executing.
Local Variables
Local variables are stored in each thread’s own stack. That means that local variables are never shared between threads. That also means that all local primitive variables are thread safe. Here is an example of a thread safe local primitive variable:
Local Object References
Local references to objects are a bit different. The reference itself is not shared. The object referenced however, is not stored in each threads’s local stack. All objects are stored in the shared heap.
If an object created locally never escapes the method it was created in, it is thread safe. In fact you can also pass it on to other methods and objects as long as none of these methods or objects make the passed object available to other threads.
Here is an example of a thread safe local object:
public void someMethod() < LocalObject localObject = new LocalObject(); localObject.callMethod(); method2(localObject); >public void method2(LocalObject localObject)
The LocalObject instance in this example is not returned from the method, nor is it passed to any other objects that are accessible from outside the someMethod() method. Each thread executing the someMethod() method will create its own LocalObject instance and assign it to the localObject reference. Therefore the use of the LocalObject here is thread safe.
In fact, the whole method someMethod() is thread safe. Even if the LocalObject instance is passed as parameter to other methods in the same class, or in other classes, the use of it is thread safe.
The only exception is of course, if one of the methods called with the LocalObject as parameter, stores the LocalObject instance in a way that allows access to it from other threads.
Object Member Variables
Object member variables (fields) are stored on the heap along with the object. Therefore, if two threads call a method on the same object instance and this method updates object member variables, the method is not thread safe. Here is an example of a method that is not thread safe:
public class NotThreadSafe < StringBuilder builder = new StringBuilder(); public add(String text)< this.builder.append(text); >>
If two threads call the add() method simultaneously on the same NotThreadSafe instance then it leads to race conditions. For instance:
NotThreadSafe sharedInstance = new NotThreadSafe(); new Thread(new MyRunnable(sharedInstance)).start(); new Thread(new MyRunnable(sharedInstance)).start(); public class MyRunnable implements Runnable < NotThreadSafe instance = null; public MyRunnable(NotThreadSafe instance)< this.instance = instance; >public void run() < this.instance.add("some text"); >> Notice how the two MyRunnable instances share the same NotThreadSafe instance. Therefore, when they call the add() method on the NotThreadSafe instance it leads to race condition.
However, if two threads call the add() method simultaneously on different instances then it does not lead to race condition. Here is the example from before, but slightly modified:
new Thread(new MyRunnable(new NotThreadSafe())).start(); new Thread(new MyRunnable(new NotThreadSafe())).start();
Now the two threads have each their own instance of NotThreadSafe so their calls to the add method doesn’t interfere with each other. The code does not have race condition anymore. So, even if an object is not thread safe it can still be used in a way that doesn’t lead to race condition.
The Thread Control Escape Rule
When trying to determine if your code’s access of a certain resource is thread safe you can use the thread control escape rule:
If a resource is created, used and disposed within the control of the same thread, and never escapes the control of this thread, the use of that resource is thread safe.
Resources can be any shared resource like an object, array, file, database connection, socket etc. In Java you do not always explicitly dispose objects, so «disposed» means losing or null’ing the reference to the object.
Even if the use of an object is thread safe, if that object points to a shared resource like a file or database, your application as a whole may not be thread safe. For instance, if thread 1 and thread 2 each create their own database connections, connection 1 and connection 2, the use of each connection itself is thread safe. But the use of the database the connections point to may not be thread safe. For example, if both threads execute code like this:
check if record X exists if not, insert record X
If two threads execute this simultaneously, and the record X they are checking for happens to be the same record, there is a risk that both of the threads end up inserting it. This is how:
Thread 1 checks if record X exists. Result = no Thread 2 checks if record X exists. Result = no Thread 1 inserts record X Thread 2 inserts record X
This could also happen with threads operating on files or other shared resources. Therefore it is important to distinguish between whether an object controlled by a thread is the resource, or if it merely references the resource (like a database connection does).