[Java知识库]一篇文章搞懂 ThreadLocal

ThreadLocal 如何保证对象只被当前线程访问呢?

下面让我们一起深入 ThreadLocal 的内部实现。

我们需要关注的自然是 ThreadLocal 的 set() 方法和 get() 方法。

set

先从 set() 方法说起:

?
 ?  /**
 ? ? * Sets the current thread's copy of this thread-local variable
 ? ? * to the specified value.  Most subclasses will have no need to
 ? ? * override this method, relying solely on the {@link #initialValue}
 ? ? * method to set the values of thread-locals.
 ? ? *
 ? ? * @param value the value to be stored in the current thread's copy of
 ? ? * ? ? ?  this thread-local.
 ? ? */
 ?  public void set(T value) {
 ? ? ?  Thread t = Thread.currentThread();
 ? ? ?  ThreadLocalMap map = getMap(t);
 ? ? ?  if (map != null)
 ? ? ? ? ?  map.set(this, value);
 ? ? ?  else
 ? ? ? ? ?  createMap(t, value);
 ?  }

在 set 时，首先获得当前线程对象，然后通过 getMap() 方法拿到线程的 ThreadLocalMap ，并将值存入 ThreadLocalMap 中。

而 ThreadLocalMap 可以理解为一个 Map (虽然不是，但是你可以把它简单地理解成 HashMap )，但是它是定义在 Thread 内部的成员。

注意下面的定义是从 Thread 类中摘出来的

 ?  /* ThreadLocal values pertaining to this thread. This map is maintained
 ? ? * by the ThreadLocal class. */
 ?  ThreadLocal.ThreadLocalMap threadLocals = null;

而设置到 ThreadLocal 中的数据，也正是写入了 threadLocals 的这个 Map 。

其中， key 为 ThreadLocal 当前对象， value 就是我们需要的值。

而 threadLocals 本身就保存了当前自己所在线程的所有“局部变量”，也就是一个 ThreadLocal 变量的集合。

在这里也给想提升的开发人们安利一个福利：Java高级进阶笔记，完整版PDF文档点击此处免费领取。

get

在进行 get() 方法操作时，自然就是将这个 Map 中的数据拿出来。

?
?
 ?  /**
 ? ? * Returns the value in the current thread's copy of this
 ? ? * thread-local variable.  If the variable has no value for the
 ? ? * current thread, it is first initialized to the value returned
 ? ? * by an invocation of the {@link #initialValue} method.
 ? ? *
 ? ? * @return the current thread's value of this thread-local
 ? ? */
 ?  public T get() {
 ? ? ?  Thread t = Thread.currentThread();
 ? ? ?  ThreadLocalMap map = getMap(t);
 ? ? ?  if (map != null) {
 ? ? ? ? ?  ThreadLocalMap.Entry e = map.getEntry(this);
 ? ? ? ? ?  if (e != null) {
 ? ? ? ? ? ? ?  @SuppressWarnings("unchecked")
 ? ? ? ? ? ? ?  T result = (T)e.value;
 ? ? ? ? ? ? ?  return result;
 ? ? ? ? ?  }
 ? ? ?  }
 ? ? ?  return setInitialValue();
 ?  }

get() 方法先取得当前线程的 ThreadLocalMap 对象，然后通过将自己作为 key 取得内部的实际数据。

Thread.exit()

在了解了 ThreadLocal 的内部实现后，我们自然会引出一个问题:

那就是这些变量是维护在 Thread 类内部的( ThreadLocalMap 定义所在类)，这也意味着只要线程不退出，对象的引用将一直存在。

当线程退出时， Thread 类会进行一些清理工作，其中就包括清理 ThreadLocalMap 。

?
 ?  /**
 ? ? * This method is called by the system to give a Thread
 ? ? * a chance to clean up before it actually exits.
 ? ? */
 ?  private void exit() {
 ? ? ?  if (group != null) {
 ? ? ? ? ?  group.threadTerminated(this);
 ? ? ? ? ?  group = null;
 ? ? ?  }
 ? ? ?  /* Aggressively null out all reference fields: see bug 4006245 */
 ? ? ?  target = null;
 ? ? ?  /* Speed the release of some of these resources */
 ? ? ?  threadLocals = null;
 ? ? ?  inheritableThreadLocals = null;
 ? ? ?  inheritedAccessControlContext = null;
 ? ? ?  blocker = null;
 ? ? ?  uncaughtExceptionHandler = null;
 ?  }

因此，使用线程池就意味着当前线程未必会退出(比如固定大小的线程池，线程总是存在)。

如果这样，将一些大的对象设置到 ThreadLocal 中(它实际保存在线程持有的 ThreadLocalMap 内)，可能会使系统出现内存泄漏的可能。

这里我的意思是:你设置了对象到 Threadlocal 中，但是不清理它，在你使用几次后，这个对象也不再有用了，但是它却无法被回收。

此时，如果你希望及时回收对象，最好使用 ThreadLocal.remove() 方法将这个变量移除，就像我们习惯性地关闭数据库连接一样。

如果你确实不需要这个对象了，就应该告诉虚拟机，请把它回收，防止内存泄漏。

tl = null

另外一种有趣的情况是 JDK 也可能允许你像释放普通变量一样释放 ThreadLocal 。

比如，我们有时候为了加速垃圾回收，会特意写出类似 obj = null 的代码。

如果这么做，那么 obj 所指向的对象就会更容易地被垃圾回收器发现，从而加速回收。

同理，如果对于 ThreadLocal 的变量，我们也手动将其设置为 null ，比如 tl = null ，那么这个 ThreadLocal 对应的所有线程的局部变量都有可能被回收。

这里面的奥秘是什么呢?

先来看一个简单的例子。

package com.shockang.study.java.concurrent.thread_local;
?
import java.text.ParseException;
import java.text.SimpleDateFormat;
import java.util.Date;
import java.util.concurrent.CountDownLatch;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
?
public class ThreadLocalDemo_Gc {
    static volatile ThreadLocal<SimpleDateFormat> tl = new ThreadLocal<SimpleDateFormat>() {
        protected void finalize() throws Throwable {
            System.out.println(this.toString() + " is gc");
        }
    };
    static volatile CountDownLatch cd = new CountDownLatch(10000);
?
    public static class ParseDate implements Runnable {
        int i = 0;
?
        public ParseDate(int i) {
            this.i = i;
        }
?
        public void run() {
            try {
                if (tl.get() == null) {
                    tl.set(new SimpleDateFormat("yyyy-MM-dd HH:mm:ss") {
                        protected void finalize() throws Throwable {
                            System.out.println(this.toString() + " is gc");
                        }
                    });
                    System.out.println(Thread.currentThread().getId() + ":create SimpleDateFormat");
                }
                Date t = tl.get().parse("2015-03-29 19:29:" + i % 60);
            } catch (ParseException e) {
                e.printStackTrace();
            } finally {
                cd.countDown();
            }
        }
    }
?
    public static void main(String[] args) throws InterruptedException {
        ExecutorService es = Executors.newFixedThreadPool(10);
        for (int i = 0; i < 10000; i++) {
            es.execute(new ParseDate(i));
        }
        cd.await();
        System.out.println("mission complete!!");
        tl = null;
        System.gc();
        System.out.println("first GC complete!!");
        //在设置ThreadLocal的时候，会清除ThreadLocalMap中的无效对象
        tl = new ThreadLocal<SimpleDateFormat>();
        cd = new CountDownLatch(10000);
        for (int i = 0; i < 10000; i++) {
            es.execute(new ParseDate(i));
        }
        cd.await();
        Thread.sleep(1000);
?
        System.gc();
        System.out.println("second GC complete!!");
?
    }
}

上述案例是为了跟踪 ThreadLocal 对象，以及内部 SimpleDateFormat 对象的垃圾回收。

为此，我们重载了 finalize() 方法。

这样，我们在对象被回收时，就可以看到它们的踪迹。

在主函数 main 中，先后进行了两次任务提交，每次 10000 个任务。

在第一次任务提交后，我们将 tl 设置为 null ，并进行一次 GC 。

接着，我们进行第二次任务提交，完成后，再进行一次 GC 。

执行上述代码，最有可能的一种输出如下所示。

19:create SimpleDateFormat
15:create SimpleDateFormat
17:create SimpleDateFormat
18:create SimpleDateFormat
20:create SimpleDateFormat
14:create SimpleDateFormat
11:create SimpleDateFormat
12:create SimpleDateFormat
13:create SimpleDateFormat
16:create SimpleDateFormat
mission complete!!
first GC complete!!
com.shockang.study.java.concurrent.thread_local.ThreadLocalDemo_Gc$1@5041865d is gc
11:create SimpleDateFormat
14:create SimpleDateFormat
20:create SimpleDateFormat
12:create SimpleDateFormat
16:create SimpleDateFormat
13:create SimpleDateFormat
18:create SimpleDateFormat
15:create SimpleDateFormat
17:create SimpleDateFormat
19:create SimpleDateFormat
second GC complete!!

注意这些输出所代表的含义。

首先，线程池中 10 个线程都各自创建了一个 SimpleDateFormat 对象实例。

接着进行第一次 GC ，可以看到 ThreadLocal 对象被回收了(这里使用了匿名类，所以类名看起来有点怪，这个类就是开头创建的 t 对象)。

提交第 2 次任务，这次一样也创建了 10 个 SimpleDateFormat 对象，然后进行第二次 GC 。

在第二次 GC 后，第一次创建的 10 个 SimpleDateFormat 的子类实例全部被回收。

虽然我们没有手工 remove (这些对象，但是系统依然有可能回收它们)。

ThreadLocal.ThreadLocalMap

要了解上面的回收机制，我们需要更进一步了解 ThreadLocal.ThreadLocalMap 的实现。

之前我们说过， ThreadLocalMap 是一个类似 HashMap 的东西。

更准确地说，它更加类似 WeakHashMap。

ThreadLocalMap 的实现使用了弱引用。

弱引用是比强引用弱得多的引用。

Java 虚拟机在垃圾回收时，如果发现弱引用，就会立即回收。

ThreadLocalMap 内部由一系列 Entry 构成，每一个 Entry 都是 WeakReference< ThreadLocal>。

 ? ? ?  /**
 ? ? ? ? * The entries in this hash map extend WeakReference, using
 ? ? ? ? * its main ref field as the key (which is always a
 ? ? ? ? * ThreadLocal object).  Note that null keys (i.e. entry.get()
 ? ? ? ? * == null) mean that the key is no longer referenced, so the
 ? ? ? ? * entry can be expunged from table.  Such entries are referred to
 ? ? ? ? * as "stale entries" in the code that follows.
 ? ? ? ? */
 ? ? ?  static class Entry extends WeakReference<ThreadLocal<?>> {
 ? ? ? ? ?  /** The value associated with this ThreadLocal. */
 ? ? ? ? ?  Object value;
?
 ? ? ? ? ?  Entry(ThreadLocal<?> k, Object v) {
 ? ? ? ? ? ? ?  super(k);
 ? ? ? ? ? ? ?  value = v;
 ? ? ? ? ?  }
 ? ? ?  }

这里的参数 k 就是 Map 的 key ， v 就是 Map 的 value ，其中 k 也是 ThreadLocal 实例，作为弱引用使用。

super(k) 就是调用了 WeakReference 的构造函数

因此，虽然这里使用 ThreadLocal 作为 Map 的 key ，但是实际上，它并不真的持有 Threadlocal 的引用。

而当 ThreadLocal 的外部强引用被回收时， ThreadLocalMap 中的 key 就会变成 null 。

当系统进行 ThreadLocalMap 清理时(比如将新的变量加入表中，就会自动进行一次清理，虽然 JDK 不定会进行一次彻底的扫描，但显然在这个案例中，它奏效了)，就会将这些垃圾数据回收。

ThreadLocal 的回收机制

ThreadLocal 的回收机制，如图所示。