深入理解Java多线程——ThreadLocal

目录 定义 API 场景分析 场景实验,观察Spring框架在多线程场景的执行情况 10000此请求,单线程 10000次请求,线程数加到100 对c的访问加锁...

定义

ThreadLocal是线程局部变量,不同线程的threadlocal相互独立。它是一种保存线程私有信息的机制,因为在现成的整个生命周期都有效,
所以可以方便地在一个线程关联的不同业务模块之间传递信息,比如事务ID、Cookie等上下文相关信息。

特点:

  • 简单,开箱即用。
  • 快速,无额外开销。
  • 安全,线程安全。

    threadlocal设计实现的优点:开箱即用,代码易读,符合经常阅读偶尔使用的原则

场景:资源持有、线程一致性、并发计算等多线程场景。

API

场景分析


如jdbc事务的请求,part i 代表不同事务,如更新用户信息、更新订单信息等,需要保证各事务资源的一致性。
每一个事务请求连接时,先去threadlocal map里找,如果不存在,到连接池中请求分配连接,并存入map。

总结,ThreadLocal的主要作用是:

  • 持有线程资源,供线程的各个部分使用
  • 帮助维护多线程共享资源的一致性
  • 线程安全的一种方案

场景实验,观察Spring框架在多线程场景的执行情况

压力测试工具,apache2-util

10000此请求,单线程

10000次请求,线程数加到100


虽然完成10000请求的速度变快了,但最终curl请求get到的数据会不一致。
原因是,多线程下,c是临界资源,c=c+1不具备原子性,要先读取c,在执行加1,再执行赋值。

对c的访问加锁


测试发现curl get到的结果是10000,但速度会很慢,原因是加锁导致排队,并发实质上变成了串行,性能被锁卡住。
解决方法就是使用ThreadLocal,让线程在自己的局部变量资源上运行。

把c设为ThreadLocal


测试发现,最终统计数据依然不准确。

原因是spring默认线程池有20多个线程,这些线程每一个都有自己的局部变量c,执行10000请求后,需要收集各个线程的数据。

收集多个ThreadLocal中的数据

虽然threadlocal是各个线程独占的数据,但也是进程持有的,不过java没有提供收集数据的接口,所以可以通过hashmap或
hashset来存储threadlocal,最后一并收集。



改进,因为set访问需要同步,所以addset中加入同步锁,而且set访问次数最多是线程池的线程数,相对c的访问次数要少,
属于低频访问,所以对总体性能影响小。

实验总结

  • 基于线程池模型加同步锁很危险,可能因排队等锁,导致cpu使用不充分,从而严重拖慢性能。
  • 虽然多线程不能完全避免同步问题,但使用ThreadLocal,可以把高频同步化为低频同步。

实现原理

自定义HashMap存放ThreadLocal弱引用,延续了lazy-load模式,初始容量16,门限2/3

satic class ThreadLocalMap {
 satic class Entry extends WeakReference<ThreadLocal<?>> {
 /** The value associated with this ThreadLocal. */
 Object value;
 Entry(ThreadLocal<?> k, Object v) {
 super(k);
 value = v;
 }
 }
 // …
}

回收被内存回收的弱引用所占的槽是超级复杂问题。当Key为null时,该条目就变成“废弃条目”,
相关“value”的回收,往往依赖于几个关键点,即set、remove、rehash。

下面set的精简代码,具体的清理逻辑是实现在cleanSomeSlots和expungeStaleEntry之中。

private void set(ThreadLocal<?> key, Object value) {
 Entry[] tab = table;
 int len = tab.length;
 int i = key.threadLocalHashCode & (len-1);
 for (Entry e = tab[i];; …) {
 //…
 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!这就是很多OOM的来源,
所以应用一定要自己负 责remove,并且不要和线程池配合,因为worker线程往往是不会退出的。

hash算法

散列更均匀,减少冲突

解决冲突的方法是后移法。

总结

解决一致性问题,除了排队(加锁)、投票(拜占庭将军)、CAS+voilate外,ThreadLocal不失为一个更轻量级的优选方案。

  • 发表于 2020-03-09 17:47
  • 阅读 ( 188 )
  • 分类:网络文章

条评论

请先 登录 后评论
不写代码的码农
小编

篇文章

作家榜 »

  1. 小编 文章
返回顶部
部分文章转自于网络,若有侵权请联系我们删除