从源码看ThreadLocal 实现原理及其内存泄露分析

古城微笑少年丶 2022-05-16 14:08 218阅读 0赞

## 前言 ##

ThreadLocal的作用:

ThreadLocal提供的实际上就是一种线程隔离，不同的线程的变量归属不同的线程，线程之间不能想问访问各自的变量，当线程生命周期结束的时候，线程会被销毁。

之前只知道它的作用，大概还了解一点原理知道内部用的是Map，今天又遇见了，于是有了这篇源码分析.

## 几个变量 ##

//线程hashcode值来标识线程,nextHashCode()是获得下一次的值 private final int threadLocalHashCode = nextHashCode(); //AtomicInteger类型的hashcode，从0开始 private static AtomicInteger nextHashCode =new AtomicInteger(); //每次hash增长的值 private static final int HASH_INCREMENT = 0x61c88647;

依稀记得AtomicInteger是通过自选式的CAS操作来维护原子性的，通常类似于i++这种，读取，计算，写的步骤都不是原子性的。

## 构造函数 ##

public ThreadLocal() { }

构造函数很简单，啥也没有。

## ThreadLocal Set方法 ##

public void set(T value) { Thread t = Thread.currentThread(); ThreadLocalMap map = getMap(t); if (map != null) map.set(this, value); else createMap(t, value); }

这里关键的是getMap这个方法，它把Thread传进getMap去获得ThreadLocalMap。`ThreadLocal.ThreadLocalMap threadLocals = null;`虽然写在了Thread中，但是用的确实ThreadLocal中的map。初次使用map一定为空，这个时候就会创建map

## CreateMap ##

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

抛砖引玉，我们进入ThreadLocalMap中。

## ThreadLocalMap ##

ThreadLocalMap(ThreadLocal<?> firstKey, Object firstValue) { table = new Entry[INITIAL_CAPACITY]; int i = firstKey.threadLocalHashCode & (INITIAL_CAPACITY - 1); table[i] = new Entry(firstKey, firstValue); size = 1; setThreshold(INITIAL_CAPACITY); }

由这个构造函数，我们可以画出ThreadLocal所用的map结构。  
![这里写图片描述][70]  
  图中，黄线代表弱引用。我们挑出这两个重要的引用，别的不用特别看。需要注意的是，当弱引用作为不可达对象的时候，会在下一次GC的时候会被回收。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 set方法 ##

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(); }

代码逻辑比hashMap简单多了，hashMap是拉链法，它这边直接使用的table数组，如果那个位置已经有了对象，就nextIndex，探测下一个位置，就是标准的线性探测法解决冲突，HashMap是链地址法。就是如果冲突了就向后再挂一个对象。由此我们引入内存泄露的问题。

## 内存泄露 ##

这里面的细节小逻辑，新手也看不懂，但是需要挑出来的是这里的`cleanSomeSlots`，清除引用，因为key ThreadLocal是弱引用，当外面没有强引用引用它的时候，即成为无法到达的key将会被GC掉，但是这个时候会存在键为null的value还没有被清除，所以就要通过这个方法去清除。这个清除方法就不贴出来了，只要知道它是一次遍历看看有哪些key为null的，然后将值设置为null来帮助GC。  
　　总结下来就是，set方法会触发一次清除弱引用残留下来的value值。同样get和remove也会进行清理。

`特殊情况:` from:[例子出处][Link 1]

public class HelloWorldExample extends HttpServlet { private static final long serialVersionUID = 1L; static class LocalVariable { private Long[] a = new Long[1024 * 1024 * 100]; } final static ThreadLocal<LocalVariable> localVariable = new ThreadLocal<LocalVariable>(); @Override public void doGet(HttpServletRequest request, HttpServletResponse response) throws IOException, ServletException { //(2) localVariable.set(new LocalVariable()); response.setContentType("text/html"); PrintWriter out = response.getWriter(); out.println("<html>"); out.println("<head>"); out.println("<title>" + "title" + "</title>"); out.println("</head>"); out.println("<body bgcolor=\"white\">"); //(3) out.println(this.toString()); //(4) out.println(Thread.currentThread().toString()); out.println("</body>"); out.println("</html>"); } }

在Servlet中，有一个类为ThreadLocal的静态变量，打个比方，如果说有5个线程访问这个Servlet实例，Servlet 为5个线程都创建了map，但是没有进行remove久而久之内存自然会蹭蹭往上涨, 用完了线程没有被销毁而是回到了线程池里面，当Thread被销毁了还好，强引用链断了，自然就会被销毁了。官方tomcat在7.0+的时候会解决这个问题，上面的from连接最后给出了答案，重新启动的时候线程会被renew。

> 十二月 31, 2017 5:44:24 下午 org.apache.catalina.loader.WebappClassLoader checkThreadLocalMapForLeaks  
> 严重: The web application \[/examples\] created a ThreadLocal with key of type \[java.lang.ThreadLocal\] (value \[java.lang.ThreadLocal@63a3e00b\]) and a value of type \[HelloWorldExample.LocalVariable\] (value \[HelloWorldExample$LocalVariable@4fd7564b\]) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak.

`不得不注意的问题:` 试想一下，当Thread被销毁的时候，静态变量是在类加载的时候就初始化了的，所以说内存中除非JVM停掉，那么这个静态变量永远会存在，及时Thread线程被回收了，那么这个ThreadLocal引用还是存在的，所以remove方法对ThreadLocalMap中的引用清除是清除了就是说map里面的Entry被清掉了，但是这个强引用new 出来的实例依旧是存在的。

总结一下: 用完了就remove掉，静态变量 会一直存在。

## get方法 ##

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(); } 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; }

不难看出在最后expungeStaleEntry(i);也执行了一次清理。

## remove方法 ##

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; } } }

remove方法是最正宗的手动清除了

## get，set，remove总结 ##

由上面的分析不难发现，在进行set方法的时候是清除some，get和remove的时候是大清除，如果是同一个线程执行代码的话，那么还可以通过多次的get，set进行清楚，如果是多线程的环境下，你用了不remove，极有可能会造成内存泄漏，不完全清理的问题也可能存在。线程不结束，那么这个Thread引用链将会永远存在。所以用完了remove掉是个好习惯。也是必须这样用的。

## 总结 ##

此次就ThreadLocal这个类的实现进行了分析，从get、set、remove这三个方法把内存泄漏的问题搞清楚了，它的内部是Thread维护的一个Map属性，键是ThreadLocal变量，值是set进去的值，冲突处理是线性探测法。重要的部分都已经列出来了，每一个字都是手打，希望对和我一样不了解的人一些帮助。如果错误或者理解不对的地方还望纠正

经典一句:  
　　同步机制`以时间换空间`，多个线程排队等待资源释放。ThreadLocal`空间换时间`每个线程单独一份资源，互不相干。妙哉妙哉。

## 参考链接 ##

[https://www.sczyh30.com/posts/Java/java-concurrent-threadlocal/][https_www.sczyh30.com_posts_Java_java-concurrent-threadlocal]  
[http://blog.xiaohansong.com/2016/08/06/ThreadLocal-memory-leak/][http_blog.xiaohansong.com_2016_08_06_ThreadLocal-memory-leak]

9.18日补充：  
　　为什么ThreadLocal内部用的是弱引用？大概是因为内部ThreadLocalMap不是人new出来的，它不归人管，而是在内部使用的，倘若new出来的ThreadLocal变量被gc了，那么ThreadLocalMap中引用ThreadLocal的Entry也应该被gc，这就是所说的弱引用一旦没有了别处的引用就会被gc这个道理，Entry继承的是WeakReference，它应该被回收，毕竟key是ThreadLocal。

[70]: /images/20220516/c478b78eb8154ee5860e443daeddc001.png
[Link 1]: http://ifeve.com/%E4%BD%BF%E7%94%A8threadlocal%E4%B8%8D%E5%BD%93%E5%8F%AF%E8%83%BD%E4%BC%9A%E5%AF%BC%E8%87%B4%E5%86%85%E5%AD%98%E6%B3%84%E9%9C%B2/
[https_www.sczyh30.com_posts_Java_java-concurrent-threadlocal]: https://www.sczyh30.com/posts/Java/java-concurrent-threadlocal/
[http_blog.xiaohansong.com_2016_08_06_ThreadLocal-memory-leak]: http://blog.xiaohansong.com/2016/08/06/ThreadLocal-memory-leak/