2008/10/1 Brian Pontarelli <[EMAIL PROTECTED]> > Is this still true in an environment that can be configured with fixed > thread pools such as servlet containers and such? I was under the > impression that the Map used was keyed off the thread ID and that was > fixed. Plus I also thought they were all weak references. >
not weak references as such, from the ThreadLocal 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)." so it depends on the life of the thread - usually the leaking thread is the primordial thread that started the application, which is often long-lived. the other common leak is when you don't clear the thread-local before returning a thread to its pool - this could keep alive a lot of data until the thread is pulled out of the pool and re-assigned (and the thread local is reset) I could see some possibility of issues if your thread pools shrink and > grow, but as long as the references are traversable and self contained > not bound to any long lived object, the weak references in the map > should work as expected, correct? > except the references aren't weak, but tied to the life of the thread > -bp > > On Sep 30, 2008, at 4:59 PM, Bob Lee wrote: > > > Are you sure you actually want thread local scope? It's very prone > > to memory leaks. > > > > Bob > > > > > > > > > > -- Cheers, Stuart --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "google-guice" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/google-guice?hl=en -~----------~----~----~----~------~----~------~--~---
