Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!eternal-september.org!feeder.eternal-september.org!mx04.eternal-september.org!.POSTED!not-for-mail From: "Mike Schilling" Newsgroups: comp.lang.java.programmer Subject: Re: Proposed new Java feature Date: Sun, 27 May 2012 12:59:05 -0700 Organization: A noiseless patient Spider Lines: 71 Message-ID: References: <8Euwr.47425$On2.20024@newsfe16.iad> Injection-Date: Sun, 27 May 2012 19:58:53 +0000 (UTC) Injection-Info: mx04.eternal-september.org; posting-host="P5j3IZ/M0ehOxHRbp7DrKw"; logging-data="12521"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18fnU8FcO+ahgYCQw2xZEt2Q3iPzuwryeM=" X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-RFC2646: Format=Flowed; Response X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 Cancel-Lock: sha1:Enqa64pISSHPHWCHVO73VGO6bAw= X-Priority: 3 X-MSMail-Priority: Normal Xref: csiph.com comp.lang.java.programmer:14839 "Eric Sosman" wrote in message news:jptvdf$1s5$1@dont-email.me... > On 5/27/2012 3:04 PM, Mike Schilling wrote: >> "Daniel Pitts" wrote in message >> news:8Euwr.47425$On2.20024@newsfe16.iad... >>> On 5/27/12 11:00 AM, Mike Schilling wrote: >>>> "markspace"<-@.> wrote in message news:jptkmp$vbg$1@dont-email.me... >>>>> On 5/26/2012 4:11 PM, Mike Schilling wrote: >>>>> >>>>>> Proposed feature: a static method on Thread that clears all >>>>>> ThreadLocals >>>>>> for >>>>>> the current thread. >>>>>> >>>>> >>>>> >>>>> I can see your points. However, I don't have any real experience with >>>>> ThreadLocal, and when a neophyte agrees with your argument, that's a >>>>> red >>>>> flag. >>>>> >>>>> Here's a blog where someone seems to have the same issue as you. >>>>> >>>>> >>>>> >>>>> At the end of the comments, there's a suggestion to use >>>>> ThreadLocal::remove(), with the implication that it allows the thread >>>>> local variable to be garbage collection. Is there a reason that >>>>> doesn't >>>>> work for you? >>>> >>>> That acts on an individual ThreadLocal (and works quite well), but it >>>> doens't allow removing all ThreadLocals that might have been >>>> accumlated. >>> You're basically saying "This type of resource can leak if not cleared >>> appropriately, so there should be a 'Release all resources' method." >>> >>> When paraphrased that way, does that make it clearer why it isn't a good >>> idea? It would be about the same as a "File.closeAll()" or a >>> "Socket.closeAll()" call. Extremely dangerous and only a crutch for not >>> doing the right thing to begin with. >> >> Or a "collect all unused memory" call . Clearly, that's a crutch for not >> keeping track of memory allocation properly in the first place. And the >> fact that files and sockets are closed when a process exits is yet >> another >> crutch. > > I'm with Daniel. Your code uses classes that you wrote, and > classes you got from somewhere else -- Sioux Unusuals, perhaps. > And if those classes use ThreadLocals for their own purposes, and > you blithely destroy them all, what happens then? Or what about > the class that invoked your code, passing an InheritableThreadLocal? > Is it a good idea to change parts of your invoker's state that you > don't understand, that you aren't even aware of? Consider the use case again. I've written a container. It procures a thread and lets third-party code run in it. Currently I have two choices: 1. Create a fresh thread each time. This kills all the ThreadLocals that might be lying around, but doesn't perform very well. 2. Use a ThreadPool. This improves performance at the cost of letting ThreadLocals packrat (which, in the worst case, holds entire ClassLoaders in memory). I'm greedy; I want the performance without the memory issues. Or, to say it another way, when getting a Thread from a ThreadPool, it should be completely indistinguishable whether it's a recycled or brand-new thread.