ThreadLocal leak

[GoogleCodeExporter]

Hi

Once I've unloaded my app from my web container (Jetty or Tomcat), I see the 
following ThreadLocal sticking around in InjectorImpl.

I assume it needs to be cleaned up when Context is destroyed.
Cheers
Chris

Class Name                                                                      
                             | Ref. Objects | Shallow Heap | Ref. Shallow Heap 
| Retained Heap
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
---------------
java.lang.Thread @ 0xad6b8d0  qtp1633127083-14 Native Stack, Thread             
                             |            1 |          176 |                88 
|        21,896
'- threadLocals java.lang.ThreadLocal$ThreadLocalMap @ 0xb76c730                
                             |            1 |           32 |                88 
|        21,312
   '- table java.lang.ThreadLocal$ThreadLocalMap$Entry[32] @ 0xb76c750                                       |            1 |          280 |                88 |        21,280
      '- [16] java.lang.ThreadLocal$ThreadLocalMap$Entry @ 0xb76cde8                                         |            1 |           56 |                88 |            88
         '- referent com.google.inject.internal.InjectorImpl$1 @ 0xaebd2b8                                   |            1 |           32 |                88 |       384,440
            '- this$0 com.google.inject.internal.InjectorImpl @ 0xaebd2d8                                    |            1 |           88 |                88 |       384,408
               '- state com.google.inject.internal.InheritingState @ 0xaebd330                               |            1 |           88 |                88 |         9,912
                  '- explicitBindingsMutable java.util.LinkedHashMap @ 0xaebd398                             |            1 |           80 |                88 |         5,608
                     '- table java.util.HashMap$Entry[128] @ 0xaebd400                                       |            1 |        1,048 |                88 |         1,048
                        '- [119] java.util.LinkedHashMap$Entry @ 0xb0170f8                                   |            1 |           64 |                88 |            64
                           '- value com.google.inject.internal.ProviderInstanceBindingImpl @ 0xb0171b8       |            1 |           80 |                88 |           536
                              '- providerInstance com.google.inject.servlet.ServletDefinition @ 0xaec2cc0    |            1 |           64 |                88 |           504
                                 '- httpServlet java.util.concurrent.atomic.AtomicReference @ 0xaec2ec0      |            1 |           24 |                88 |            24
                                    '- value com.tyndalehouse.step.rest.framework.FrontController @ 0xb2a7c70|            1 |           88 |                88 |        43,968
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
---------------

Original issue reported on code.google.com by christop...@gmail.com on 2 Jun 2012 at 6:25

• Merged into: #288

[GoogleCodeExporter]

Anybody on this one?

Original comment by christop...@gmail.com on 20 Jul 2012 at 5:19

[GoogleCodeExporter]

This is the localContext ThreadLocal from InjectorImpl - this is actually an 
array of Objects, length 1, which holds the internal context while processing 
nested injection requests. The content of this array is nulled out when the 
outermost call completes, and it is only referenced from inside the injector, 
so technically there is nothing to stop the GC from collecting this chain. See 
http://blog.crazybob.org/2006/07/hard-core-java-threadlocal.html for the 
overall approach. However, due to a long-standing bug in the JDK's ThreadLocal 
design this entry may still appear in the thread's internal book-keeping map 
that Tomcat introspects. The entry should disappear after more ThreadLocals are 
created, as this then mutates the book-keeping map which clears the entry.

So if you are hot-deploying applications then this shouldn't cause a leak in 
practice, it's just the eager Tomcat detector warning about a potential leak 
based on it's internal introspection. There are ways we could force an 
immediate cleanup of the entry, but the downside is that this could then affect 
performance for everyone while fixing a theoretical issue.

Original comment by mccu...@gmail.com on 20 Jul 2012 at 5:53

[GoogleCodeExporter]

The attached patch (which I attached yesterday to issue 288) should also clear 
up this warning.

Original comment by mccu...@gmail.com on 7 Aug 2012 at 6:56

Attachments:

• GUICE_288_decouple_thread_local.patch

[GoogleCodeExporter]

Original comment by sberlin on 5 Dec 2013 at 11:51

• Changed state: Duplicate