Java ThreadPool中的ThreadLocal值是否被GC？

Question

In my code, I want to test ThreadLocal's GC strategy. I use two methods. One is ThreadPool , the other is a self-created thread. In the first scenarios, JVM doesn't GC Thread's ThreadLocalMap seemly(No finalize() output). The other works well.

I've found. In October 2007, Josh Bloch (co-author of java.lang.ThreadLocal along with Doug Lea) wrote:

"The use of thread pools demands extreme care. Sloppy use of thread pools in combination with sloppy use of thread locals can cause unintended object retention, as has been noted in many places."

I guess ThreadPool may be dangerous to use ThreadLocal .

Here is my code(JDK8 environment)

public class ThreadLocalDemo_Gc {
    static volatile ThreadLocal<SimpleDateFormat> tl = new ThreadLocal<SimpleDateFormat>(){
        // overwrite finalize, such that the message will be printed when GC happens.
        protected void finalize() throws Throwable{
            System.out.println(this.toString() + " is gc(threadlocal)");
        }
    };

    // Let the main thread wait for all workers.
    static volatile CountDownLatch cd = new CountDownLatch(10);

    public static class ParseDate implements Runnable{
        int i = 0;
        public ParseDate(int i) {
            super();
            this.i = i;
        }

        @Override
        public void run() {
            try {
                if(tl.get() == null){
                    tl.set(new SimpleDateFormat("yyyy-MM-dd HH:mm:ss"){
                        // overwrite finalize, such that the message will be printed when GC happens.
                        protected void finalize() throws Throwable {
                            System.out.println(this.toString() + " is gc(sdf)");
                        }
                    });
                    // new sdf object is created in ThreadLocalMap
                    System.out.println(Thread.currentThread().getId() + ":create SimpleDateFormat");
                }

                Date t = tl.get().parse("2017-3-26 17:03:" + i % 60);

            } catch (ParseException e) {
                e.printStackTrace();
            } finally {
                cd.countDown();
            }
        }   
    }

    // code with ThreadPool
//  public static void main(String[] args) throws InterruptedException {
//      ExecutorService es = Executors.newFixedThreadPool(10);
//      
//      for(int i = 0; i < 10; i++){
//          es.execute(new ParseDate(i));
//      }
//      cd.await();
//      
//      System.out.println("mission complete");
//      
//      tl = null;  // free the weak reference
//      System.gc();
//      System.out.println("First GC complete");
//      es.shutdown();
//  }

    // not pooling threads
    public static void main(String[] args) throws InterruptedException {
        Thread[] all = new Thread[10];

        for(int i = 0; i < 10; i++){
            all[i] = new Thread(new ParseDate(i));
        }

        for(int i =  0; i < 10; i++){
            all[i].start();
        }

        cd.await();

        tl = null;

        System.gc();
        System.out.println("First GC complete");
    }

}

After running the first main() function. None of the SimpleDateFormat object is GCed. The second main() function indeed does that job.

first main function

second main function

Edit #1 Thanks to Gray's remind. The real problem, which results in no output in the function finalize() , is the ThreadPool may not be truly collected. In the test code, only shutdown() was used. However, the worker threads may not be collected after this process. So more safer way is invoking awaitTermination() . This function does generate all worker threads instance, and the resource those belongs to is collected, spefically ThreadLocalMap .

Here is the revision of the main() with ThreadPool

// code with ThreadPool
    public static void main(String[] args) throws InterruptedException {
        ExecutorService es = Executors.newFixedThreadPool(10);

        for(int i = 0; i < 10; i++){
            es.execute(new ParseDate(i));
        }
        cd.await();

        es.shutdown();
        es.awaitTermination(Long.MAX_VALUE, TimeUnit.MILLISECONDS);
        System.gc();

    }

This version of main() works well, all the collection message from finalize() method are printed.

Finally, Java GC may not collect the value when the instance of Entry 's key has no stable reference. As ThreadLocalMap 's key is the weak reference, the Entry 's key becomes null . However, the Entry 's value is not GCed. This conclusion may be proved in my test.

Answer 1

Instances of ThreadLocal itself are merely a view into a map stored on the thread itself. The instance being collected does not actually guarantee that the reference is severed.

It can be approximated as threadInstance.privateField = WeakHashMap<ThreadLocal<T>,T> .

That means if the Thread instance becomes unreachable so become all associated values held by ThreadLocal . On the other hand when the ThreadLocal instance becomes unreachable that only means the map key is nulled (being a weak reference), the value is still held alive by the map until some accesses to the map clean the value.The map cleaning is performed lazily, so cleaning up ThreadLocal references does not have the same effect as letting threads terminate. The third way of cleaning it is calling threadLocal.remove() from within the thread.

And of course it's a common pattern to have shared static final ThreadLocal<T> tl accessors within a class. When combined with a thread pool that means those values will stay alive as long as the thread pool does unless you use remove()

Answer 2

I guess ThreadPool may be dangerous to use ThreadLocal.

I wouldn't go this far. I would say that you need to take into account that the ThreadLocal storage won't be reaped unless the thread itself terminates.

But in looking at your test code, there are a lot of problems with both the ExecutorService and direct thread main methods. In both cases you are not properly joining with the completed threads. Ditch the CountDownLatch and do the following before the gc() call:

for (int i = 0; i < 10; i++) {
    all[i].join();
}

or

es.shutdown();
es.awaitTermination(Long.MAX_VALUE, TimeUnit.MILLISECONDS);

But the real problem with your code is that you have a race condition with the Finalizer thread. The gc thread finishes but the actually finalizing of the objects happens in another "Finalizer" thread after the GC completed. If you just put a 1 second sleep at the end of the main() you should see all 10 SDFs reaped.

What this demonstrates really is that it is hard to force objects to the GC'd in such a way. Putting System.out.println(...) commands in a finalizer() gives me the chills even thinking about it even though I know you are doing it to learn more about ThreadLocal 's memory usage.

I think that storing things in ThreadLocal s if done carefully shouldn't be a problem. In your thread's run method, I would just do a try / finally block and make sure to do a threadLocal.remove() in the finally so the thread cleans itself up before exiting. But I don't even bother with that if I have a background thread which is running for the life of my application. It is really only threads that come and go that you need to be particularly worried about.

Lastly, there is no need for a ThreadLocal field to be volatile and it should be a static within the ParseDate if possible.

Hope this helps.

Answer 3

A Thread in a ThreadPool may never terminate until the ThreadPool does. That's the whole point of ThreadPool . So it never gets GC'd. So of course the Thread 's ThreadLocal doesn't get GC'd either.