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 变量的集合。
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 的回收机制，如图所示。