[concurrency-interest] reusing threads and thread local state
mike.skells at ebizz-consulting.com
Thu May 5 05:00:30 EDT 2005
The point is that the approach that you propose is not suitable for the
1. It doesn't work in J2EE
2. It doesn't work when you are writing reusable code (ie not the app)
3. It stops the application being swapped
Given the above it does not seen to be a good idea to post is as the
solution to the problem that was described.
BTW WeakHashMap is _not_ a same management mechanism for the problem below.
You are assuming that there in no reference to the Thread in any of the
values that you maintain, or anywhere else in any system you ever write.
This is precisely the problem that causes memory leaks
From: concurrency-interest-bounces at cs.oswego.edu
[mailto:concurrency-interest-bounces at cs.oswego.edu] On Behalf Of Gregg
Sent: 05 May 2005 03:46
To: Mike Skells
Cc: 'Gregg Wonderly'; larryr at saturn.sdsu.edu;
concurrency-interest at altair.cs.oswego.edu; 'Osvaldo Pinali Doederlein';
Subject: Re: [concurrency-interest] reusing threads and thread local state
Mike Skells wrote:
>>I don't use threadlocals myself because it is just as easy to use a
>>Hashtable<Thread,Hashtable<String,?>> via a static factory which I can
>>control access to and manage clearing etc on my own.
This is my statement, not Larry's.
> Interesting to know how you manage the cleanup, as you now have a strong
> reference to a Thread in you HashMap, so the Thread cannot be GC until
> one of your explicit cleanups completes
I use explicit thread management to handle this issue. And also, I use
an periodic thread that asks if the thread is still running and remove
entries for any such threads.
> Also all of the ThreadLocals that are created in that thread are not GCed
> either (fixed in JDK1.5).
> If this is run in an environment that manages Threads (outside you
> such as an appserver then the cleanup is complicated further.
I don't use J2EE. I just use J2SE and Jini for my enterprise
applications. Keeps me in control of the things that matter to me.
> Looks to me as if you have created your own personal memory leak!
Only if you don't understand all the issues and ways out. There are a
lot more "appliance programmers" who don't understand computer science,
so these things will largely work for them. But, these memory leak bugs
are getting to be way to common (java.util.Timer cancelled tasks), so
I've learned to just role my own rather than depending on bug free JDK
code, which historically has not been available.
Concurrency-interest mailing list
Concurrency-interest at altair.cs.oswego.edu
More information about the Concurrency-interest