This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
No, they are not the same. You use synchronization to protect code blocks, and often to safely share the same data across multiple threads. You use ThreadLocal to have a single reference to access different data for each thread.
When a Thread is already acting on one object,preventing any other thread from acting on the same object is called "Thread Synchronization" or "Thread Safe". The Object on which the threads are synchronized is called "Synchronized Object".Thread Synchronization is recommended when multiple threads are used on the same object(in multiThreading).
Thread locale is a scope of access like,global Scope,local scope to a specific Thread,which is accessing an object.
I can point out one use case where I used thread local. Consider you have a Servlet which calls some business methods. You have a requirement to generate a unique transaction id for each and every request this servlet process and you need to pass this transaction id to the business methods, for logging purpose. One solution would be passing this transaction id as a parameter to all the business methods. But this is not a good solution as the code is redundant and unnecessary.
To solve that, you can use Thread Local. You can generate a transaction id (either in servlet or better in a filter) and set it in the Thread Local. After this, what ever the business method, that this servlet calls, can access the transaction id from the thread local.
This servlet might be servicing more that one request at a time. Since each request is processed in separate thread, the transaction id will be unique to each thread (local) and will be accessible from all over the thread’s execution (global).
On Related note ThreadLocal is not as simple as it look like, In correct usage of ThreadLocal can create memory leak in Java. Especially in J2EE environment where your code runs on a managed environment and application server's thread are used to serve request, which lives longer than http request.
Javin Paul wrote:On Related note ThreadLocal is not as simple as it look like, In correct usage of ThreadLocal can create memory leak in Java. Especially in J2EE environment where your code runs on a managed environment and application server's thread are used to serve request, which lives longer than http request.
This is not completely correct -- as the Thread instance does use a WeakReference to the ThreadLocal intance. This means that if the ThreadLocal instance becomes unreachable because the http request is out-of-scope, the memory will be eventually released. Having said that, there does seem to be some delay in doing so -- it does look like it takes time for it to happen (and I didn't look into why ... but my speculation is the weak reference only clears the key, and it will take another access (by a different threadlocal obviously) to clear the values).