So you think you know Java Multi threading!

Having worked as a Java programmer for more than half of my career, I am often surprised (and sometimes not) as to how many developers don’t really understand how multi threading in the JVM works. This could be in part because we have become used to writing stateless services or the multithreaded aspects of the code are hidden behind the framework ( @async annotations in Spring and the Executor Framework in Java). This post is quick refresher (not to be substituted for an authoritative source) on certain aspects of multi threading , specifically synchronisation and thread safety and how the JVM handles it. It talks about the familiar Producer — Consumer problem and how to identify “shared state” with examples.

Think about the following scenario — I have a producer which needs to produce a series of numbers (e.g 1..100) and a consumer which needs to read the number as and when it is produced. If there are multiple producers and multiple consumers and the rate of consumption and production can differ, then it makes sense to put the produced output in a queue. But if our requirement is just reading the shared state of a ‘Counter’ variable, we do not need to put this in a queue. Identifying what is shared is the first problem in figuring out what needs to be protected for shared access.

In Producer Consumer case defined above, the producer increments the value of a shared counter , and the consumer reads the last incremented value of the shared counter. So we need to ensure that the shared counter at any point is only accessed by one thread to read its current value or write its next value.

An analogy would be to imagine a warehouse in which the only way to get to the contents is through a door which is locked. To put an item into the warehouse, one has to obtain a key and open the door and put the item into the warehouse and once the item is in the warehouse, the key is then returned. To get an item from the warehouse, the key has to be obtained , the door unlocked and the item retrieved. In this above case the warehouse or the CounterObj is shared between a producing thread (Thread A) and a consuming thread (Thread B). The lock is mutually exclusive (a mutex) that is, at any point in time either the producer or the consumer can obtain the key to the lock. They cannot both acquire the same key at the same time. Once the job is done, the key (or the access to the lock ) has to be released by the owning thread.

Now what does the thread do when it puts the item in the warehouse and now has to release the key/lock? Does it sleep or wait? If the thread sleeps in the synchronized block or as per our analogy the warehouse — it has not actually released the key to the warehouse. Its still holding on to the key and and is not doing any work except release the use of the CPU. This means no other thread can now acquire the key. So effectively no other thread can now get into the warehouse and and add or get an item if the lock is an exclusive lock (mutex) unless the first thread gets interrupted from its sleep. Coming back to thread constructs — the right option would be to call the lock object’s wait method which releases the lock so that another thread can enter any synchronised block protected by the same lock. In the warehouse analogy — this is like exiting the warehouse and giving the keys back and queueing at the entry of the ware house to acquire the key once it becomes available again.

Here is a Code snippet with the Producer Consumer entities mentioned above.

If the CounterObj is declared as volatile, then the write update is ensured to be visible to threads reading it. If we changed the program a little, to remove the wait notify block and instead use Thread.sleep(1000) without the synchronised block, we would still see a correct output but intermediate updates would be lost to the Consumer thread.

If your application needs state but is OK with multiple threads seeing different versions of the state, then ThreadLocal confines the value to a single thread. What is the difference between using ThreadLocal and volatile you might ask. Using volatile provides a weak level of synchronisation and reads and writes are atomic. volatile ensures that all thread read the most current value from main memory (not from the cpu cache or registers) and flushes back to main memory — however compound operations such as read and then increment i++, i==, i+=x etc are not guaranteed to be atomic. Using ThreadLocal however, each thread has its own value of that variable which does not need to be synchronised.

If an object (a Servlet or a Spring Bean) can be accessed by multiple threads and has class level variables that are mutable, then that object has shared state. Spring Containers, Web server implementations are inherently multi threaded. The beans or servlet instances handle multiple requests at the same time , each request originating from a separate thread. If an object is created by an entity and then accessed in two separate instances of different types through a reference parameter, it is still shared state. If objects are created within the method being executed, those are not shared as each Thread has its own stack frame and local variables are placed on the stack frame. Consider the code snippet below to illustrate the above.

Related posts:

On the off chance that it were the score of the drums and the bass, you would most likely allude to it as a free future type beat. On the off chance that it has no drums, you most unquestionably…