[concurrency-interest] "Best practice" for ThreadPool creation/run-down
Online at stolsvik.com
Tue Jan 8 18:17:11 EST 2008
Peter Kovacs wrote:
> Thank you, Aaron.
> I guess I'll have to read-up on the java.lang.ref package. (I kind of
> suspect that this will not work for me, because the thread pool used
> is ultimately referenced as a static variable in my library. I'll see
> if this is a problem for the PhantomReference scheme.)
Get rid of the static - library-thingies with statics in them are
annoying, in my opinion. I'd rather like to keep a reference to your
service-/something/, than to rely on you magically handling things using
those dreaded memory retaining annoyances which statics are.
And I also like to be able to shut down this /something/ explicitly. I
positively hate when java databases and message queues and what have
you, don't let you explicitly shut then fully down. What if I want to
implement a "reboot" algorithm - cycling the entire application as if
the JVM terminated, and then fire it up again? (If your memory
consumption doesn't increase after a bunch of such cycles, and you then
are able to terminate the application without calling System.exit(x),
chances are you have every resource under control). This goes doubly for
the "new-style" stuff using OSGi - here modules are taken up and brought
down all the time - and I don't like that I cannot explicitly clean up.
Furthermore, I think you should _clearly_, in bold and underline, state
in the javadocs and docs in general that there IS such a default
handling using a default thread pool - so that the users know that when
using your something, a bunch of threads will in any way be created.
Very good, though, that you provide a way for the user to provide an
executor themselves - don't then go ahead a stick that into some static!
Finally, you could possibly have a magic clean up procedure that made it
shut cleanly down if no one was using anymore - as a nod to those people
that aren't quite that worried about explicit resource handling. But I
think those reference-ideas won't guarantee that the JVM will be able to
shut down in a timely fashion without a System.exit(): I don't think the
JVM instantly enqueues abandoned objects - I believe this is done in the
same fashion as with garbage collection, and we all know how what
happens if you rely on finalization for resource shutdown, don't we? :)
However, you can make a ThreadFactory for your default pool, which
explicitly sets all those threads to deamon threads. (And please also
name your threads - that makes it SO much nicer when running the
application within a JVMTI-hooked IDE (e.g. Eclipse, when using debug
instead of run, which I though everybody did always), and when actually
debugging.) Then at least the JVM shutdown aspect would be fixed.
More information about the Concurrency-interest