一次ThreadLocal源码解析之旅

写这篇解析再一次花费了本人整整一天时间,希望通过本篇文章,能将ThreadLocal的原理说清楚,讲明白。全文主要完成了以下四个部分的工作:

  • 摸清了ThreadLocal是如何做到在不同线程set()、get()的值不被其它线程访问的;
  • 介绍了弱引用在ThreadLocalMap中的应用;
  • 探寻了ThreadLocalMap如何实现hash map功能;
  • 列举了一个使用ThreadLocal而出现的内存泄漏问题并加以分析;

首先,让我们看看ThreadLocal能产生什么样的效果:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
public class ThreadLocalDemo {
public static void main(String[] args) {
final ThreadLocal<Integer> local = new ThreadLocal<>();
local.set(100);
Thread t = new Thread(new Runnable() {
@Override
public void run() {
System.out.println(Thread.currentThread().getName() + " local: " + local.get());
}
});
t.start();
System.out.println("Main local: " + local.get());
}
}

打印结果如下:

1
2
Thread-0 local: null
Main local: 100

local在主线程set的值,可以在主线程调用get方法得到,但在线程t内调用get方法,结果结果为null。

本文接下来以local调用的set方法为入口,探究产生这一结果的原因。

set()基础

在ThreadLocal源码中set()是这样实现的:

1
2
3
4
5
6
7
8
public void set(T value) {
Thread t = Thread.currentThread();
ThreadLocalMap map = getMap(t);
if (map != null)
map.set(this, value);
else
createMap(t, value);
}

首先获得当前执行local.set()语句所在的线程对象,也就是t,然后通过local的getMap()获得t内部持有的ThreadLocalMap对象,进入Thread类的源码查看,其中就包含名为threadLocals的字段:

1
ThreadLocal.ThreadLocalMap threadLocals = null;

而查看getMap()的源码,返回的就是threadLocals:

1
2
3
ThreadLocalMap getMap(Thread t) {
return t.threadLocals;
}

map != null

如果map != null,则执行map.set(this, value),这里的this就是local。

ThreadLocalMap的具体实现后面再展开,在这里姑且先简单的理解为按键值对存储数据的数据结构,那么我们很容易发现,local还是那个local,并没有在每个线程产生local副本,只不过调用set方法的时候,将它与传入的值以键值对的形式,存储于每个线程内部持有的ThreadLocalMap对象里。

map == null

如果map == null,则执行createMap(t, value),源码如下:

1
2
3
void createMap(Thread t, T firstValue) {
t.threadLocals = new ThreadLocalMap(this, firstValue);
}

创建ThreadLocalMap对象赋给threadLocals。

至此,ThreadLocal的基本原理就已经很清晰了:各线程对共享的ThreadLocal实例进行操作,实际上是以该实例为键对内部持有的ThreadLocalMap对象进行操作

除了set(),ThreadLocal还提供了get()、remove()等操作,实现比较简单,就不敷述了。

ThreadLocalMap结构

要想真正理解ThreadLocal,还需要知道ThreadLocalMap究竟是什么。

注释中是这样介绍的:ThreadLocalMap is a customized hash map suitable only for maintaining thread local values.

ThreadLocalMap属于自定义的map,是一个带有hash功能的静态内部类,和java.util包下提供的Map类并没有关系。内部有一个静态的Entry类,下面具体分析Entry。

Entry实现原理

首先,这个类代码如下:

1
2
3
4
5
6
7
8
9
static class Entry extends WeakReference<ThreadLocal<?>> {
/** The value associated with this ThreadLocal. */
Object value;
Entry(ThreadLocal<?> k, Object v) {
super(k);
value = v;
}
}

这里引用代码中给出的注释: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。

第一句话实际上告诉了我们,entry继承自WeakReference,用main方法引用的字段作为entry中的key。

第二句的意思是,当entry.get() == null的时候,意味着键将不再被引用。

后续将解析这两句注释。

弱引用基础知识

在开始这一小结之前,需要先掌握两点:

  • 什么是弱引用。《深入理解Java虚拟机》中这样写道:“被弱引用关联的对象只能生存到下一次垃圾收集发生之前,当垃圾收集器工作时,无论当前内存是否足够,都会回收掉,只被弱引用关联的对象。”
  • 什么是参数的引用传递,这属于Java SE基础知识就不赘述了。

接下来,先阅读源代码,当构造器传入参数后,代表键的k会传入super()中,也就是它会首先执行父类的构造器:

1
2
3
public WeakReference(T referent) {
super(referent);
}

WeakReference的构造器继续先调用父类的构造器:

1
2
3
4
5
6
7
8
Reference(T referent) {
this(referent, null);
}
Reference(T referent, ReferenceQueue<? super T> queue) {
this.referent = referent;
this.queue = (queue == null) ? ReferenceQueue.NULL : queue;
}

除此之外,我们在Reference类里面看不到任何native方法,但能看到一些实例方法,比如get(),后续我们还将谈到这个方法。

这个时候会疑惑弱引用的功能是怎么实现的,在注释中,有这样的字眼:“special treatment by the garbage collector.” 可见WeakReference的功能实现交给了垃圾回收器处理,那么这里就不展开了,感兴趣的可以参考文末的链接。在这里我们只需要了解WeakReference的使用方法。

弱引用和强引用的使用方法并不相同,下面是一个弱引用的示例:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
public class WeakReferenceDemo {
public static void main(String[] args) {
WeakReference<Fruit> fruitWeakReference = new WeakReference<>(new Fruit());
// Fruit f = fruitWeakReference.get();
if (fruitWeakReference.get() != null) {
System.out.println("Before GC, this is the result");
}
System.gc();
if (fruitWeakReference.get() != null) {
System.out.println("After GC, fruitWeakReference.get() is not null");
} else {
System.out.println("After GC, fruitWeakReference.get() is null");
}
}
}
class Fruit {
}

输出结果如下:

1
2
Before GC, this is the result
After GC, fruitWeakReference.get() is null

通过fruitWeakReference.get(),可以得到弱引用指向的对象,当执行System.gc()后,该对象被回收。

用一张图表示强弱引用彼此间的关系:

图1

要明确的是,类似“Object obj = new Object()”这般产生的引用属于强引用,所以fruitWeakReference是强引用,此时它指向的是一个WeakReference对象,在new这个对象时,我们还传入了一个new出来的Fruit对象,整行代码的目的,就是要创造一个弱引用,指向这个Fruit对象。而这个弱引用,就在fruitWeakReference指向的对象里。

用个不严谨的比喻,弱引用就像一只薛定谔的猫,我们想知道它的状态,却不能通过普通的Java代码调用出它本身来观测它,如果将前文列出的WeakReferenceDemo内的双斜杠注释去掉,用一个变量f指向fruitWeakReference.get(),不过就是将一个强引用指向了原本由弱引用指向的对象而已,此时再运行程序,得到如下结果:

1
2
3
4
Before GC, this is the result
After GC, fruitWeakReference.get() is not null
Process finished with exit code 0

由于对象被强引用,所以不会被垃圾回收。

弱引用Entry的键

有了前面的基础,很容易就能理解Entry的构造原理。为了方便说明,不妨假设我们能创建一个Entry对象,代码如下:

1
Entry entry = new Entry(local, 100);

此时强弱引用彼此间的关系图如下:

图2

到这里,就能理解前面那两句注释了,entry继承自WeakReference,内部维护一个弱引用,指向main方法中local指向的对象;entry.get()返回的是弱引用指向的对象,如果entry.get() == null,自然表示的就是键将不再被引用了。

所以,和普通Map的Entry类不同,ThreadLocalMap的Entry实例被创建是时,键是弱引用,至此ThreadLocal内部ThreadLocalMap的基本结构也就清楚了。

set()进阶

再次贴出ThreadLocal中set()的源码:

1
2
3
4
5
6
7
8
public void set(T value) {
Thread t = Thread.currentThread();
ThreadLocalMap map = getMap(t);
if (map != null)
map.set(this, value);
else
createMap(t, value);
}

注意第5行的语句,local调用set()时,一旦当前线程对象持有的ThreadLocalMap类型变量threadLocals不为null,则会执行map.set(this, value)这一行语句,上一节分析了ThreadLocalMap的结构,这一节将聚焦ThreadLocalMap的操作方法set()。

下面给出set()的源码:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
private void set(ThreadLocal<?> key, Object value) {
Entry[] tab = table;
int len = tab.length;
// 计算出hash表的位置i
int i = key.threadLocalHashCode & (len-1);
// 处理set方法关键逻辑
for (Entry e = tab[i];
e != null;
e = tab[i = nextIndex(i, len)]) {
ThreadLocal<?> k = e.get();
if (k == key) {
e.value = value;
return;
}
if (k == null) {
replaceStaleEntry(key, value, i);
return;
}
}
// 在hash表中保存新生成的Entry对象
tab[i] = new Entry(key, value);
int sz = ++size;
if (!cleanSomeSlots(i, sz) && sz >= threshold)
rehash();
}

代码中i是hash表(亦称hash桶)的索引,也就是存放新设置的entry的位置,当然在存放之前还要进行一番比较操作。threadLocalHashCode是如下方式得到的:

1
2
3
4
5
6
7
8
9
private static AtomicInteger nextHashCode = new AtomicInteger();
private static final int HASH_INCREMENT = 0x61c88647;
private static int nextHashCode() {
return nextHashCode.getAndAdd(HASH_INCREMENT);
}
private final int threadLocalHashCode = nextHashCode();

采用0x61c88647是为了实现更好的散列,每当有新的ThreadLocal对象调用threadLocalHashCode的时候,后者自增一个0x61c88647大小的值。至于为什么0x61c88647可以实现更好的散列,这涉及到Fibonacci Hashing算法(这个数的二进制形式取反加1就是一个Fibonacci Hashing常数),具体细节可跳转到文末参考链接。

当然,在计算i之前还要进行一个位运算,非常简单,比如在没扩展之前len是16(2的4次方),那么len - 1的二进制形式就是1111,按位与也就是取后四位。

为了防止碰撞冲突,这里采用的是线性探测法,并没有采用拉链法。探测的索引规则如下:

1
2
3
private static int nextIndex(int i, int len) {
return ((i + 1 < len) ? i + 1 : 0);
}

for循环的执行逻辑是这样的:

  1. 首先获取hash表索引位置为i的Entry元素tab[i];
  2. 判断tab[i]为是否为null,如果tab[i]为null,说明这个位置之前还没有存在过Entry实例,跳出循环,在hash表中该位置保存新生成的Entry对象;
  3. 如果tab[i]不为null,要么存在指向相同对象的键,如果是这种情况,则修改value为需要设定的值;要么弱引用指向为null,如果是这种情况,执行replaceStaleEntry方法;
  4. 用nextIndex方法修改i值,跳到第二步继续判断;

在跳出循环并在hash表相应位置保存新生成的Entry对象后,size也会加1,在满足!cleanSomeSlots(i, sz) && sz >= threshold的条件下,还要重新进行rehash()处理。

replaceStaleEntry以及cleanSomeSlots的主要作用都是用来删除弱引用为null的entry,后者查找的时间是log2(n),限于篇幅就不展开了,而threshold和HashMap中定义的预置作用相似,主要是扩容用的,这里为len * 2 / 3。

内存清理

还是沿用最初的例子,如果将local置为null,那么new出来的ThreadLocal对象就只被线程中的ThreadLocalMap实例弱引用,此时只要调用System.gc(),对象将在下一次垃圾收集时被回收。如果要主动断掉弱引用呢?Java提供了如下方法:

1
clear()

它是Reference抽象类提供的方法。

接下来用一个例子讨论ThreadLocal可能出现的内存泄漏问题。

内存泄漏实例

实例源码如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
public class ThreadLocalTest throws InterruptedException{
public static void main(String[] args) {
MyThreadLocal<Create50MB> local = new MyThreadLocal<>();
ThreadPoolExecutor poolExecutor = new ThreadPoolExecutor(5, 5, 1,
TimeUnit.MINUTES, new LinkedBlockingQueue<Runnable>());
for (int i = 0; i < 5; i++) {
final int[] a = new int[1];
final ThreadLocal[] finallocal = new MyThreadLocal[1];
finallocal[0] = local;
a[0] = i;
poolExecutor.execute(new Runnable() {
@Override
public void run() {
finallocal[0].set(new Create50MB());
System.out.println("add i = " + a[0]);
}
});
}
Thread.sleep(50000);
local = null;
}
static class Create50MB {
private byte[] bytes = new byte[1024 * 1024 * 50];
}
static class MyThreadLocal<T> extends ThreadLocal {
private byte[] bytes = new byte[1024 * 1024 * 500];
}
}

先说一说该小程序的设计思路:

该程序旨在构造出一种内存泄漏的情况:当线程池执行完当前任务处于等待状态的时候,将local置null,回收main方法一开始new出来的MyThreadLocal对象,线程池内单个线程的ThreadLocalMap实例虽然弱引用于这个MyThreadLocal对象,但内部持有的value却仍然被强引用着不能回收。

在该程序中,我们自定义了一个MyThreadLocal,目的是使new出来的MyThreadLocal对象的大小能达到500MB;Create50MB是创建出来的容量包,每个线程最后持有的value就是一个50MB大小的Create50MB对象;线程池也是自定义传参,做到更好的掌控,一次能同时工作5个线程;for循环中用到了两个临时变量,是为了规避匿名内部类引用外部变量必须要声明为final的语言限制。

启动程序,运行状态见下图:

001

使用的堆的大小是750MB,这符合预期,new出来的MyThreadLocal对象500MB,有五个线程,每个线程50MB,加起来一共750MB。

50秒后,将local置null,这个时候不再有强引用指向new的MyThreadLocal对象,此时执行垃圾回收,结果如下:

002

使用的堆大小变为250MB,单就这个结果还不能证明每个线程内对MyThreadLocal对象存在弱引用,但是一定不存在强引用。

之前本人曾研究过线程池的源码,线程池内的线程在执行完一个任务后,并没有销毁,在本例中,它们处于waiting状态,所以,本程序始终维持在250MB大小,得不到释放,一旦将程序中的条件改得足够大,就能出现明显的性能问题。解决的方法通常是在线程内调用ThreadLocal的remove方法,实际上,ThreadLocal提供的公有API并不多,但是这个方法足够解决问题。

小结

不得不说,通过对ThreadLocal的解析,本人收获很多。整篇文章写起来也是一气呵成(所以可能也包藏着错误),估摸着如果以后有对共享变量进行私有设置的需求时,也可以参考这种方法来写;之前对四种引用只是了解,这次算是弄明白怎么运用;用线性探测解决hash表的碰撞冲突,有别于HashMap,也是ThreadLocal的特点;最后列举的内存泄漏,算是对前面写的内容进行了一次实战。

cool.

参考

WeakReference

JVM原理与实现——Reference

What is the meaning of 0x61C88647 constant in ThreadLocal.java

Fibonacci Hashing

打印GC:-XX:+PrintGCDetails,更多可见:查看GC日志时使用的虚拟机参数