# Thread Safe Code Code that is safe to call by multiple threads simultaneously. This type of code contains no race conditions because a race condition only occurs when multiple threads update shared resources. # What Resources Java Threads Share When Executing ? ## Local Variables Local variables are stored in each thread's own stack and are never shared between threads. That means that local primitive variables are thread safe. ``` public void someMethod(){ long threadSafeInt = 0; threadSafeInt++; } ``` ## Local Object References Local references to objects are not shared between threads. However, the objects referenced are not stored in each thread'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. It can even be passed to other methods and objects as long as none of these methods or objects make the passed object available to other threads. ``` public void someMethod(){ LocalObject localObject = new LocalObject(); localObject.callMethod(); method2(localObject); } public void method2(LocalObject localObject){ localObject.setValue("value"); } ``` ## 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. ``` public class NotThreadSafe{ StringBuilder builder = new StringBuilder(); public add(String text){ this.builder.append(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 tow threads call the add() method simultaneously on different instances then it does not lead to race conditions. ``` new Thread(new MyRunnable(new NotThreadSafe())).start(); new Thread(new MyRunnable(new NotThreadSafe())).start(); ``` Each thread received its own instance of NotThreadSafe so their calls to the add method doesn't interfere with each other. Therefore, no race conditions. Even if an object is not thread safe, it can still be used in a way that doesn't lead to a 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 alway explicitly dispose objects, so "disposed" means losing or nulling 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 fire 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 itself, or if it merely references the resource (like a database connection does).