ThreadLocal介绍以及源码分析

释放双眼,带上耳机,听听看~!

ThreadLocal 线程主变量
前面部分引用其他优秀博客,后面源码自己分析的,如有冒犯请私聊我。
用Java语言开发的同学对 ThreadLocal 应该都不会陌生,这个类的使用场景很多,特别是在一些框架中经常用到,比如数据库事务操作,还有MVC框架中数据跨层传递。这里我们简要探讨下 ThreadLocal 的内部实现及可能存在的问题。
首先问自己一个问题,让自己实现一个这个的功能类的话怎么去做?第一反应就是简单构造一个 Map<Thread, T> 数据结构,key是 Thread,value就是我们要保存的线程变量 T。我们看下这种设计有哪些问题:

  • 随着运行时间越久,存在Map里的Thread越多,当Thread退出时,资源也没有释放,存在内存泄漏问题
  • Map数据因为会被多线程访问,存在资源竞争,所以还必需对Map做同步安全操作,效率低下

JDK中的 ThreadLocal 精妙的设计来解决问题上述两个问题。首先每个Thread(线程)内部都有一个Map结构数据ThreadLocalMap<ThreadLocal, T>,当我们对线程变量赋值时ThreadLocal.set(T value)时,其实是先获取当前线程Thread.currentThread())的内部属性字段ThreadLocalMap,然后以当前ThreadLocal为key设置线程变量值T。这种设计的精髓是,每个Thread线程都维护一份自己的ThreadLocalMap数据结构,这样就解决了上面所述问题中的第二个,不存在竞争条件。
既然每个Thread内部都维护一个ThreadLocalMap字典数据结构,字典的Key值是ThreadLocal,那么当某个ThreadLocal对象不再使用(没有其它地方再引用)时,每个已经关联了此ThreadLocal的线程怎么在其内部的ThreadLocalMap里做清除此资源呢?JDK中的ThreadLocalMap又做了一次精彩的表演,它没有继承java.util.Map类,而是自己实现了一套专门用来定时清理无效资源的字典结构。其内部存储实体结构Entry<ThreadLocal, T>继承自java.lan.ref.WeakReference,这样当ThreadLocal不再被引用时,因为弱引用机制原因,当jvm发现内存不足时,会自动回收弱引用指向的实例内存,即其线程内部的ThreadLocalMap会释放其对ThreadLocal的引用从而让jvm回收ThreadLocal对象。这里是重点强调下,是回收对ThreadLocal对象,而非整个Entry,所以线程变量中的值T对象还是在内存中存在的,所以内存泄漏的问题还没有完全解决。接着分析JDK的实现,会发现在调用ThreadLocal.get()或者ThreadLocal.set(T)时都会定期执行回收无效的Entry操作。所以这就解决了上述问题中的第1个问题。
问题真的都解决了吗,好像都解决了。因为即没有竞争资源操作,也不会存在内存泄漏。但是细想一下,总感觉哪里不对劲,真的不会存在内存溢出(OOM)问题吗?上面一段的分析中,强调ThreadLocalMap定期清理内部的无效Entry对象,触发的条件就是对TrheadLocal执行 set,get,remove()等操作时会触发,但是如果存在这样的场景,当我们在某个线程上下文中执行ThreadLocal.set(T)设置了一个很大内存的数据结构,然后该ThreadLocal被清除引用回收,之前的线程又一直存活着,则这个大内存数据对象T是一直不回收的,这里很容易写个代码测试出OOM来。怎么解决这个问题呢?
Lucene中的org.apache.lucene.util.CloseableThreadLocal类解决了上述特殊场景引起的问题:即解决JDK中因为定期才执行无效对象回收的问题。CloseableThreadLocal在内部维护了一个ThreadLocal,当执行CloseableThreadLocal.set(T)时,内部其实只是代理的把值赋给内部的ThreadLocal对象,即执行ThreadLocal.set(new WeakReference(T))。看到这里应该明白了,这里不是直接存储T,则是包装成弱引用对象,目的就是当内存不足时,jvm可以回收此对象。但是细心的你会发现会引入一个新的问题,即当前线程还存活着的时候,因为内存不足而回收了弱引用对象,这样会在下次调用get()时取不到值返回null,这是不可接受的。所以CloseableThreadLocal在内部还创建了一个数据,WeakHashMap<Thread, T>,当线程只要存活时,则T就至少有一个引用存在,所以不会被提前回收。但是又引入的第2个问题,对WeakHashMap的操作要做同步synchronized限制。你看,所有的东西都不是十全十美的,我们掌握那个平衡点就行了。
ThreadLocal源码分析   源码介绍 1、每个线程访问自己维护的的一份副本 2、ThreadLocal 类内部维护了一个私有的字段去跟对应的线程联系(例如 userid 或者TranslationId) 这个字段第一次调用时生成后面调用不会改变

3、只要这个线程活着而且实例可以被访问,这个线程会持有这个变量副本的隐性引用,直到线程消亡,被垃圾回收

 
ThreadLocal get方法 1、根据当前thread获取对应的ThreadLocalMap 如果没有就初始化设置一个,如果有就返回 ThreadLocalMap 里面维护的Entry存储的值

 1 public T get() {
 2  Thread t = Thread.currentThread();
 3  ThreadLocalMap map = getMap(t);
 4  if (map != null) {
 5  ThreadLocalMap.Entry e = map.getEntry(this);
 6  if (e != null) {
 7  @SuppressWarnings(\"unchecked\")
 8  T result = (T)e.value;
 9  return result;
10  }
11  }
12  return setInitialValue();
13 }

 

 

  ThreadLocal 初始化value 俩个步骤 1、在原有的map上设置值 2、创建一个ThreadLocalMap

private T setInitialValue() {
 T value = initialValue();
 Thread t = Thread.currentThread();
 ThreadLocalMap map = getMap(t);
 if (map != null)
 map.set(this, value);
 else
 createMap(t, value);
 return value;
}

 

 

  ThreadLocal rehash 1、先删除陈旧的Entriy ,如果不能有效的收缩table的长度,而且长度已经大于threshold 的0.75(装载因子)倍了,就直接扩展一倍长度

 1  
 2 /**
 3  * Re-pack and/or re-size the table. First scan the entire
 4  * table removing stale entries. If this doesn\'t sufficiently
 5  * shrink the size of the table, double the table size.
 6  */
 7 private void rehash() {
 8  expungeStaleEntries();
 9  
10  // Use lower threshold for doubling to avoid hysteresis
11  if (size >= threshold - threshold / 4)
12  resize();
13 }

如果你也有此类问题,可以一起探讨(私聊或者评论),一起不断完善自己的理解,如果觉得可以欢迎关注我。

   

人已赞赏
随笔日记

ES 10 - Elasticsearch的索引别名和索引模板

2020-11-9 4:09:07

随笔日记

以最简单的方式了解--Github

2020-11-9 4:09:09

0 条回复 A文章作者 M管理员
    暂无讨论,说说你的看法吧
个人中心
购物车
优惠劵
今日签到
有新私信 私信列表
搜索