• Post Reply Bookmark Topic Watch Topic
  • New Topic

How to use ThreadLocal class

 
nibla jose
Greenhorn
Posts: 28
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Please explain how to use ThreadLocal class with a valid example.. All examples i get on net doesnt explain in detail? How good is it to use the ThreadLocal class for implementing Thread specific storage for user attributes and related ones in a web application?
 
Henry Wong
author
Sheriff
Posts: 22528
109
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
All examples i get on net doesnt explain in detail?


How much detail can there be? To set a value, have the thread call the set() method. To get the value back have the thread call the get() method. The same thread local object can be shared by many threads, and they won't step on each other when they call set() and get().

Henry
 
Henry Wong
author
Sheriff
Posts: 22528
109
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

And I almost forgot -- to provide an initial value, which is returned by get() when set() hasn't been called yet, then override the initialValue() method.

Henry
 
nibla jose
Greenhorn
Posts: 28
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Henry,

I have some doubts in it.

1. If i have 5 threads, how many ThreadLocal objects will be there? One or Five?
2. Does the ThreadLocal object constructor has to be run each time any thread stores a value?
3. Or is it just that only the three methods, get, set and initialValue are thread specific? Is not the constructor thread specific?
4. Is it always better that we create the ThreadLocal object as a static reference?
5. What happens, if it is not a static reference and if the object which holds it gets grabage collected, but the thread doesn't die?

If my idea is correct (which i am sure is not ) ThreadLocal object is not something which was to be implemented as an object creation. Because it is not a regular object and it has to bypass a lot of ideas like these. I would say the functionality of set and get methods were better of as static methods like below.

Thread.setThreadLocalValue(String key, Object value);
Object Thread.getThreadLocalValue(String key);

Is there anything that we gain from making it like an object creation?

Thanks in advance for all kind answers..
 
Henry Wong
author
Sheriff
Posts: 22528
109
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

I think you may be reading too much into the ThreadLocal class. This class is a very simple class -- and quite frankly, has little to do with threading. In fact, it may be easier to think of it as a simple map, where the key is the thread calling the accessors.

Anyway....

1. If i have 5 threads, how many ThreadLocal objects will be there? One or Five?


If you create one, you have one. If you create five, you have five.

2. Does the ThreadLocal object constructor has to be run each time any thread stores a value?


No. In fact, it will be kinda silly to do that. Since, it will destroy the previous ThreadLocal object. This is no different that creating a new collection everytime you want to add something to the collection -- it doesn't make sense to do that.

3. Or is it just that only the three methods, get, set and initialValue are thread specific? Is not the constructor thread specific?


See 2.

4. Is it always better that we create the ThreadLocal object as a static reference?


Doesn't really matter. As long as the threads can access it, it can use it.

5. What happens, if it is not a static reference and if the object which holds it gets grabage collected, but the thread doesn't die?


Not sure what you are asking? What thread doesn't die?

Henry
 
nibla jose
Greenhorn
Posts: 28
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
This is no different that creating a new collection everytime you want to add something to the collection -- it doesn't make sense to do that.


That is very good way to look at it. An object collection for different threads... Thank you henry. Makes sense now. the 5th question. Dont bother. I was too hasty and dumb.

Also help me on how good it is in performance. Because in some sites i read that the performance can be a pain. I was actually thinking of implementing 'a single point access' to the servlet API from a project using struts 1.3. Struts 1.3 automatically doesnt provide one like JSF or others (FacesContext.getInstance().getExternalContext().getRequest() ) . So in the end i have to pass the request objects across the all the unwanted classes. How advisable it is do so?
 
Henry Wong
author
Sheriff
Posts: 22528
109
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Also help me on how good it is in performance. Because in some sites i read that the performance can be a pain.


I will freely admit that I am *not* a fan of this class -- and don't use it much. It is an old class (which uses simple synchronization).

[EDIT: Next few paragraphs deleted. As I was totally incorrect. See next post for correction.]

Henry
 
Henry Wong
author
Sheriff
Posts: 22528
109
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I will freely admit that I am *not* a fan of this class -- and don't use it much. It is an old class (which uses simple synchronization).


Interesting. I just took a look at the Java 6 source code for this. The ThreadLocal class doesn't hold the data. Instead, it stores it directly in the Thread class. And since each thread will only access the data of its Thread class, there is no need for any synchronization.

And of course, it uses weak references, so that the Thread may get rid of the value, if the ThreadLocal that place it there is no longer reachable.


I stand corrected. Maybe I should look into using this class more often.

Henry
 
Mike Simmons
Ranch Hand
Posts: 3090
14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
As far as I know, this is how ThreadLocal was implemented as far back as 1.2 as well, which is when the class was publicly released. At least, that's how Paul Hyde's Java Thread Programming (1999) describes the 1.2 implementation.
 
Henry Wong
author
Sheriff
Posts: 22528
109
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Mike Simmons wrote:As far as I know, this is how ThreadLocal was implemented as far back as 1.2 as well, which is when the class was publicly released. At least, that's how Paul Hyde's Java Thread Programming (1999) describes the 1.2 implementation.


Yea. I'm not surprised. ThreadLocal seems to be one of the classes that I dismissed the first time I saw it.

Regardless, it does look like it has been updated recently, as some of the code uses the atomic libraries -- albeit, a small part, the part that generates a hashcode.

Henry
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!