1. ThreadLocal简介
1.1 应用场景
ThreadLocal在日常业务开发中并不多见,但应用底层必不可少,在多线程环境下,为每个线程提供一份变量副本,实现变量隔离,防止产生线程安全问题。
比如Hibernate就是用了ThreadLocal来管理session的线程安全问题;
再比如controller注入HttpServletRequest对象,属于共享的全局变量,但是如何保证每个线程接受的数据是属于自己的呢?底层是spring生成的是HttpServletRequest代理对象,在实际使用的时候,通过代理拿到ThreadLocal保存的request副本,详见AutoWireUtils类源码。
1.2 举例
举一个应用的例子,SimpleDateFormat转换日期是通过Calendar来操作的,而Calendar是线程不安全的,如果不想在方法内频繁创建SimpleDateFormat对象,而是想做为共享变量来使用,ThreadLocal可以为每个线程提供一个SimpleDateFormat副本,以下是封装的工具类。
public class SimpleDateFormatUtil {
private static ThreadLocal<Map<String, SimpleDateFormat>> threadLocal = new ThreadLocal<>();
public static SimpleDateFormat getFormat(String pattern) {
Map<String, SimpleDateFormat> map = threadLocal.get();
if (map == null) {
map = new HashMap<>();
}
SimpleDateFormat sdf = map.get(pattern);
if (sdf == null) {
sdf = new SimpleDateFormat(pattern);
map.put(pattern, sdf);
threadLocal.set(map);
}
return sdf;
}
}
这里建议用java8的 LocalDate、LocalTime
2. 内存泄漏
长生命周期的对象持有短生命周期的引用,就可能发生内存泄漏;
通俗的说就是一个不再被程序使用的对象由于被异常持有引用,导致无法垃圾回收,从而引发内存泄漏。
举一个简单的例子:这里期望a被垃圾回收,虽然方法栈里a引用无法再指向堆内存中创建的对象,但由于b的内部持有对象a的引用,即b内部的成员a仍然能指向堆内存中创建的对象,导致内存泄漏,除非能找到所有引用a的地方将其赋值为null,否则a的生命周期会持续到所有引用对象被回收而一起结束;
A a = new A();
B b = new B(a);
a = null;
System.out.println(b.getA());
再看一个JDK源码设计的例子,ArrayList在移除一个元素的时候,会把 index + 1及后面的元素复制到以index开始的位置,即把后面的元素往前移动一位,然后把最后一个元素置空,否则ArrayList会一直持有最后一个元素的引用,导致内存泄漏,直到ArrayList被垃圾回收;
public E remove(int index) {
rangeCheck(index);
modCount++;
E oldValue = elementData(index);
int numMoved = size - index - 1;
if (numMoved > 0)
System.arraycopy(elementData, index+1, elementData, index,
numMoved);
elementData[--size] = null; // clear to let GC do its work
return oldValue;
}
3. ThreadLocal为什么可能产生内存泄漏
ThreadLocal的内部类ThreadLocalMap中,有一个Entry内部类设计。ThreadLocal做变量隔离都是通过ThreadLocalMap来操作的,里面有一个Entry数组,Entry是真正存值的地方。
产生内存泄漏的关键在于内部类Entry的设计。
static class Entry extends WeakReference<ThreadLocal<?>> {
/** The value associated with this ThreadLocal. */
Object value;
Entry(ThreadLocal<?> k, Object v) {
super(k);
value = v;
}
}
Entry继承WeakReference,即泛型ThreadLocal是弱引用,所以在垃圾回收的时候可以顺利被回收,但是对应的value可能不会被回收,原因在于ThreadLocalMap。
ThreadLocalMap是Thread的成员属性,所以生命周期跟随当前线程。
- 如果线程正常结束,ThreadLocal,ThreadLocalMap,Entry都因不可达而会被回收,这样是都是正常的;
- 如果使用的是线程池,线程复用导致ThreadLocalMap一直存在,Entry内部的value就不会被垃圾回收,产生k为null但是value不为null的情况,从而导致内存泄漏。
问题1:k值弱引用导致内存泄漏,为什么不设置为强引用?
答:如果把k设置为强引用,那么当threadLocal被垃圾回收,当前线程因复用等情况而未结束,持有ThreadLocalMap的强引用,ThreadLocalMap的Entry又强引用threadLocal和value,这样导致连threadLocal都不能正常回收。
4. 如何解决这个问题
JDK源码设计的时候已经考虑过这个问题,所以ThreadLocal的set和get方法通过ThreadLocalMap做了对旧值的擦除操作。
ThreadLocalMap.set方法:每一次set新值的时候,首先根据threadLocal的hashCode计算在Entry数组中的位置,然后向后环形对entry进行以下操作:
- 如果entry为null,则直接插入,然后调用cleanSomeSlots方法检测并清除旧entry;
- 如果entry的k等于当前的threadLocal,代表是同一个threadLocal,直接替换value;
- 如果当前的entry不为null但k为null,代表上述内存泄漏的情况,调用replaceStaleEntry处理旧entry并set新值;
- 如果entry不为null,entry的k不为null也不等于当前的threadLocal,代表hash冲突,可能是不同的threadLocal计算出相同的位置,已经有其他threadLocal在这个位置了,然后向后环形重复上述操作;
private void set(ThreadLocal<?> key, Object value) {
// We don't use a fast path as with get() because it is at
// least as common to use set() to create new entries as
// it is to replace existing ones, in which case, a fast
// path would fail more often than not.
Entry[] tab = table;
int len = tab.length;
int i = key.threadLocalHashCode & (len-1);
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;
}
}
tab[i] = new Entry(key, value);
int sz = ++size;
if (!cleanSomeSlots(i, sz) && sz >= threshold)
rehash();
}
ThreadLocalMap.getEntry方法:每一次get的时候,首先根据threadLocal的hashCode计算在Entry数组中的位置,然后进行以下操作:
- 如果entry不为null,并且entry中的k等于当前threadLocal,返回entry中存储的value;
- 如果entry为null,或者entry的k不等于当前threadLocal,查看getEntryAfterMiss方法,对entry数组向后环形遍历:当entry不为null且entry的k等于当前threadLocal,返回entry里的value;当entry不为null但entry的k为null,处理当前entry及其value防止内存泄漏;当entry既不等于当前threadLocal也不为null,说明hash冲突,向后查找下一个entry继续上述操作;
private Entry getEntry(ThreadLocal<?> key) {
int i = key.threadLocalHashCode & (table.length - 1);
Entry e = table[i];
if (e != null && e.get() == key)
return e;
else
return getEntryAfterMiss(key, i, e);
}
private Entry getEntryAfterMiss(ThreadLocal<?> key, int i, Entry e) {
Entry[] tab = table;
int len = tab.length;
while (e != null) {
ThreadLocal<?> k = e.get();
if (k == key)
return e;
if (k == null)
expungeStaleEntry(i);
else
i = nextIndex(i, len);
e = tab[i];
}
return null;
}
问题2:如果两个threadLocal产生hash冲突,按相邻位置set,比如[0]和[1],如果第一个已经垃圾回收,按上述条件会调用expungeStaleEntry,第二个threadLocal处于正常状态是怎么取到值的?
答:关键就在于expungeStaleEntry,如代码所示,首先会将第一个threadLocal所属entry清理掉,然后把相邻threadLocal的entry改到这个位置,即由[1]改到[0],并将[1]上的entry置为null。
private int expungeStaleEntry(int staleSlot) {
Entry[] tab = table;
int len = tab.length;
// expunge entry at staleSlot
tab[staleSlot].value = null;
tab[staleSlot] = null;
size--;
// Rehash until we encounter null
Entry e;
int i;
for (i = nextIndex(staleSlot, len);
(e = tab[i]) != null;
i = nextIndex(i, len)) {
ThreadLocal<?> k = e.get();
if (k == null) {
e.value = null;
tab[i] = null;
size--;
} else {
int h = k.threadLocalHashCode & (len - 1);
if (h != i) {
tab[i] = null;
// Unlike Knuth 6.4 Algorithm R, we must scan until
// null because multiple entries could have been stale.
while (tab[h] != null)
h = nextIndex(h, len);
tab[h] = e;
}
}
}
return i;
}
更多关于ThreadLocal源码的解释可参考:
https://www.jianshu.com/p/dde92ec37bd1
5. 开发中如何避免
每次使用完ThreadLocal及时调用remove()方法,remove方法会将key和value擦除;
c.clear负责清楚entry的k,expungeStaleEntry负责清楚entry的value。
private void remove(ThreadLocal<?> key) {
Entry[] tab = table;
int len = tab.length;
int i = key.threadLocalHashCode & (len-1);
for (Entry e = tab[i];
e != null;
e = tab[i = nextIndex(i, len)]) {
if (e.get() == key) {
e.clear();
expungeStaleEntry(i);
return;
}
}
}