Some questions about ThreadLocal

Discussion in 'Java' started by lightning, Aug 1, 2008.

  1. lightning

    lightning Guest

    In javadoc:
    Each thread holds an implicit reference to its copy of a thread-local
    variable as long as the thread is alive and the ThreadLocal instance
    is accessible; after a thread goes away, all of its copies of thread-
    local instances are subject to garbage collection (unless other
    references to these copies exist).


    It seems only when thread "goes away",the threadlocals of that thread
    will be cleaned.
    But what about when using threadpools?
    For example:
    Executors.newFixedThreadPool()


    In TOMCAT,the threadlocals works fine because framework such dwr ,
    struts2 or spring transactionmanager using threadlocals to store many
    things.How did it work?
    Will it work fine no matter no matter Tomcat is using threadpool or
    using singlethread mode?
    lightning, Aug 1, 2008
    #1
    1. Advertising

  2. lightning

    Mark Space Guest

    lightning wrote:

    > In TOMCAT,the threadlocals works fine because framework such dwr ,
    > struts2 or spring transactionmanager using threadlocals to store many
    > things.How did it work?


    I'm not sure what you are trying to say. Can you give some code as an
    example?

    Regardless, I'm pretty sure that if a thread completes, it cannot be
    used again. Therefore I assume that Executors such as FixedThreadPool
    have some way of keeping a thread "open" and alive, and not allowing it
    to terminate. So ThreadLocal objects should persist.


    > Will it work fine no matter no matter Tomcat is using threadpool or
    > using singlethread mode?


    Single threaded mode is best avoided under all circumstances. Just
    don't use it. I have no idea what it might do to thread local objects
    under the various Java EE containers.
    Mark Space, Aug 1, 2008
    #2
    1. Advertising

  3. In article <Ecykk.15965$>,
    Mark Space <> wrote:

    > lightning wrote:
    >
    > > In TOMCAT,the threadlocals works fine because framework such dwr ,
    > > struts2 or spring transactionmanager using threadlocals to store many
    > > things.How did it work?

    >
    > I'm not sure what you are trying to say. Can you give some code as an
    > example?
    >
    > Regardless, I'm pretty sure that if a thread completes, it cannot be
    > used again. Therefore I assume that Executors such as FixedThreadPool
    > have some way of keeping a thread "open" and alive, and not allowing it
    > to terminate. So ThreadLocal objects should persist.


    ThreadLocal's storage has a WeakReference to the Thread as a key. That
    means that the key lasts exactly as long as the Thread object, never
    longer or shorter. The thread pointer could be re-used at the OS-level
    but that's OK because it's guaranteed that no old Java references exist.

    ThreadLocal should only be used as a last resort. It's prone to causing
    mysterious side-effects and memory bloating. If you must use one, put
    just one at a very high level and use it to store a session manager.

    >
    > > Will it work fine no matter no matter Tomcat is using threadpool or
    > > using singlethread mode?

    >
    > Single threaded mode is best avoided under all circumstances. Just
    > don't use it. I have no idea what it might do to thread local objects
    > under the various Java EE containers.


    --
    Goolge is a pro-spamming service. I will not see your reply if you use Google.
    Kevin McMurtrie, Aug 1, 2008
    #3
  4. lightning

    Guest

    On 1 Aug., 10:02, Kevin McMurtrie <> wrote:
    > In article <Ecykk.15965$>,
    >  Mark Space <> wrote:
    >
    > > lightning wrote:

    >
    > > > In TOMCAT,the threadlocals works fine because framework such  dwr ,
    > > > struts2  or spring transactionmanager using threadlocals to store many
    > > > things.How did it work?

    >
    > > I'm not sure what you are trying to say.  Can you give some code as an
    > > example?


    Same here, the question - if any - is not clear to me. ThreadLocals
    can of course be used in the presence of thread pools. You just have
    to be aware of the fact that their life time may exceed that of the
    current "request" (whatever that is in a particular application).

    > > Regardless, I'm pretty sure that if a thread completes, it cannot be
    > > used again.  Therefore I assume that Executors such as FixedThreadPool
    > > have some way of keeping a thread "open" and alive, and not allowing it
    > > to terminate.  So ThreadLocal objects should persist.

    >
    > ThreadLocal's storage has a WeakReference to the Thread as a key.


    This is not true. The weak reference points to the ThreadLocal
    instance in order to make an entry garbage collectible when the
    ThreadLocal instance can be collectible. The map itself is a member
    of Thread so this is collected if the Thread is collected.

    >  That
    > means that the key lasts exactly as long as the Thread object, never
    > longer or shorter.


    The key can (and most likely will in the case of a static ThreadLocal)
    last longer than a thread.

    > ThreadLocal should only be used as a last resort.  It's prone to causing
    > mysterious side-effects and memory bloating.


    I would agree saying that you should be knowing what you are doing.
    But I would not necessarily say this is a "last resort" only. It all
    depends. It's a tool like many others with advantages and
    disadvantages.

    >  If you must use one, put
    > just one at a very high level and use it to store a session manager.


    The benefit of this session manager being?

    Cheers

    robert
    , Aug 1, 2008
    #4
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Steve Jasper
    Replies:
    5
    Views:
    1,298
    Steve Jasper
    Nov 20, 2003
  2. Ian Pilcher
    Replies:
    3
    Views:
    732
    NOBODY
    Oct 29, 2005
  3. no
    Replies:
    3
    Views:
    6,798
    robert
    Mar 6, 2006
  4. Timo Nentwig
    Replies:
    1
    Views:
    758
  5. sods
    Replies:
    0
    Views:
    397
Loading...

Share This Page