【JUC】ThreadLocal
文章目录
1. 概述
ThreadLocal 提供线程局部变量。这些变量与正常的变量不同,因为每一个线程在访问ThreadLocal实例的时候(通过其get或set方法)都有自己的、独立初始化的变量副本。ThreadLocal实例通常是类中的私有静态字段,使用它的目的是希望将状态(例如,用户ID或事务ID)与线程关联起来。
常用API:
ThreadLocal 初始化:
方式1:
ThreadLocal<Integer> threadLocal1 = new ThreadLocal<Integer>(){
@Override
protected Integer initialValue()
{
return 0;
}
};
方式2(推荐):
ThreadLocal<Integer> threadLocal2 = ThreadLocal.withInitial(() -> 0);
使用示例:
需求:5个房屋中介,每个人随机卖出几套房子,统计各自的销售额
代码如下:
class House //资源类
{
int saleCount = 0;
public synchronized void saleHouse() {
++saleCount;
}
ThreadLocal<Integer> saleVolume = ThreadLocal.withInitial(() -> 0);
public void saleVolumeByThreadLocal() {
saleVolume.set(1 + saleVolume.get());
}
}
/**
* 需求1: 5个销售卖房子,集团高层只关心销售总量的准确统计数。
* <p>
* 需求2: 5个销售卖完随机数房子,各自独立销售额度,自己业绩按提成走,分灶吃饭,各个销售自己动手,丰衣足食
*/
public class ThreadLocalDemo {
public static void main(String[] args) throws InterruptedException {
House house = new House();
for (int i = 1; i <= 5; i++) {
new Thread(() -> {
int size = new Random().nextInt(5) + 1;
try {
for (int j = 1; j <= size; j++) {
house.saleHouse();
house.saleVolumeByThreadLocal();
}
System.out.println(Thread.currentThread().getName() + "\t" + "号销售卖出:" + house.saleVolume.get());
} finally {
house.saleVolume.remove();
}
}, String.valueOf(i)).start();
}
;
//暂停毫秒
try {
TimeUnit.MILLISECONDS.sleep(300);
} catch (InterruptedException e) {
e.printStackTrace();
}
System.out.println(Thread.currentThread().getName() + "\t" + "共计卖出多少套: " + house.saleCount);
}
}
运行结果如下:
总结:
- 因为每个 Thread 内有自己的实例副本且该副本只由当前线程自己使用
- 既然其他 Thread 不可访问,那就不存在多线程间共享的问题
- 统一设置初始值,但是每个线程对这个值的修改都是各自线程相互独立的
- 如何才能“不争抢”
- 加入
synchronized
或者 Lock 控制资源的访问顺序 - 人手一份,各自安好。(ThreadLocal)
- 加入
2. Thread、ThreadLocal、ThreadLocalMap 关系
2.1 Thread 和 ThreadLocal
Thread 和 ThreadLocal 之间的关系是,每个线程都拥有自己的 ThreadLocal 副本。也就是说,一个线程可以访问它自己的 ThreadLocal 对象,但无法访问其他线程的 ThreadLocal 对象。
2.2 ThreadLocal 和 ThreadLocalMap
ThreadLocalMap 是 ThreadLocal 的静态内部类,是实现 ThreadLocal 的关键之一,它是与当前线程相关联的一个映射表。当在一个线程中调用 ThreadLocal 的 set() 方法时,实际上是在该线程的 ThreadLocalMap 中存储了一个键值对,其中键是 ThreadLocal 对象本身,值是 set() 方法传入的值。而当调用 get() 方法时,则是从 ThreadLocalMap 中获取对应的值。
2.3 三者之间的关系
ThreadLocalMap 实际上就是一个以 ThreadLocal 实例为key,任意对象为value的 Entry 对象。
当我们为threadLocal变量赋值,实际上就是把当前threadLocal实例为key,值为value的Entry往这个threadLocalMap中存放。
近似的可以理解为:
ThreadLocalMap 从字面上就可以看出这是一个保存 ThreadLocal 对象的map(其实是以ThreadLocal为key),不过是经过了两层包装的ThreadLocal对象:
JVM内部维护了一个线程版的 Map<Thread,T>
(通过ThreadLocal对象的set方法,结果把ThreadLocal对象当作自己的key,放进了ThreadLocalMap中),每个线程要用到这个T的时候,用当前的线程去Map里面获取,通过这样让每个线程都拥有了自己独立的变量,人手一份,竞争条件被彻底消除,在并发模式下是绝对安全的变量。
3. ThreadLocal 内存泄漏问题
内存泄漏:不再会被使用的对象或者变量占用的内存不能被回收,就算内存泄漏。
回顾 ThreadLocalMap:
ThreadLocalMap 从字面上就可以看出这是一个保存 ThreadLocal 对象的map(其实是以它为key),不过是经过了两层包装的 ThreadLocal 对象:
- 第一层包装是使用 WeakReference<ThreadLocal<?>> 将 ThreadLocal 对象变成一个 弱引用对象。
- 第二层包装是定义了一个专门的类 Entry 来扩展 WeakReference<ThreadLocal<?>> 。
每个Thread对象维护着一个ThreadLocalMap的引用
ThreadLocalMap是ThreadLocal的内部类,用Entry来进行存储
调用ThreadLocal的set()方法时,实际上就是往ThreadLocalMap设置值,key是ThreadLocal对象,值Value是传递进来的对象
调用ThreadLocal的get()方法时,实际上就是往ThreadLocalMap获取值,key是ThreadLocal对象
ThreadLocal本身并不存储值,它只是自己作为一个key来让线程从ThreadLocalMap获取value,正因为这个原理,所以ThreadLocal能够实现“数据隔离”,获取当前线程的局部变量值,不受其他线程影响~
3.1 四大引用
四大引用参考文档:参考文档
引用类的整体架构:
3.1.1 强引用
当内存不足,JVM开始垃圾回收,对于强引用的对象,就算是出现了OOM也不会对该对象进行回收,死都不收。
对于一个普通的对象,如果没有其他的引用关系,只要超过了引用的作用域或者显式地将相应(强)引用赋值为 null,
一般认为就是可以被垃圾收集的了(当然具体回收时机还是要看垃圾收集策略)。
class MyObject
{
//这个方法一般不用复写,我们只是为了教学给大家演示案例做说明
@Override
protected void finalize() throws Throwable
{
// finalize的通常目的是在对象被不可撤销地丢弃之前执行清理操作。
System.out.println("-------invoke finalize method~!!!");
}
}
public class ReferenceDemo {
public static void main(String[] args) {
MyObject myObject = new MyObject();
System.out.println("-----gc before: "+myObject);
myObject = null;
System.gc();
try { TimeUnit.SECONDS.sleep(1); } catch (InterruptedException e) { e.printStackTrace(); }
System.out.println("-----gc after: "+myObject);
}
}
运行结果:
3.2 ThreadLocal 为什么要用弱引用?
示例:
public void function01()
{
ThreadLocal tl = new ThreadLocal<Integer>(); //line1
tl.set(2021); //line2
tl.get(); //line3
}
line1新建了一个ThreadLocal对象,t1 是强引用指向这个对象;
line2调用set()方法后新建一个Entry,通过源码可知Entry对象里的k是弱引用指向这个对象。
当function01方法执行完毕后,栈帧销毁强引用 tl 也就没有了。但此时线程的ThreadLocalMap里某个entry的key引用还指向这个对象。
若这个key引用是强引用,就会导致key指向的ThreadLocal对象及v指向的对象不能被gc回收,造成内存泄漏;
若这个key引用是弱引用就大概率会减少内存泄漏的问题(还有一个key为null的雷)。使用弱引用,就可以使ThreadLocal对象在方法执行完毕后顺利被回收且Entry的key引用指向为null。
3.2.1 使用了弱引用就没问题了吗?
- 当我们为threadLocal变量赋值,实际上就是当前的Entry(threadLocal实例为key,值为value)往这个threadLocalMap中存放。Entry中的key是弱引用,当threadLocal外部强引用被置为null(tl=null),那么系统 GC 的时候,根据可达性分析,这个threadLocal实例就没有任何一条链路能够引用到它,这个ThreadLocal势必会被回收,这样一来,ThreadLocalMap中就会出现key为null的Entry,就没有办法访问这些key为null的Entry的value,如果当前线程再迟迟不结束的话,这些key为null的Entry的value就会一直存在一条强引用链:Thread Ref -> Thread -> ThreaLocalMap -> Entry -> value永远无法回收,造成内存泄漏。
- 当然,如果当前thread运行结束,threadLocal,threadLocalMap,Entry没有引用链可达,在垃圾回收的时候都会被系统进行回收。
- 但在实际使用中我们有时候会用线程池去维护我们的线程,比如在Executors.newFixedThreadPool()时创建线程的时候,为了复用线程是不会结束的,所以threadLocal内存泄漏就值得我们小心
ThreadLocalMap使用ThreadLocal的弱引用作为key,如果一个ThreadLocal没有外部强引用引用他,那么系统gc的时候,这个ThreadLocal势必会被回收,这样一来,ThreadLocalMap中就会出现key为null的Entry,就没有办法访问这些key为null的Entry的value,如果当前线程再迟迟不结束的话(比如正好用在线程池),这些key为null的Entry的value就会一直存在一条强引用链。
虽然弱引用,保证了key指向的ThreadLocal对象能被及时回收,但是v指向的value对象是需要ThreadLocalMap调用get、set时发现key为null时才会去回收整个entry、value,因此弱引用不能100%保证内存不泄露。我们要在不使用某个ThreadLocal对象后,手动调用remoev方法来删除它,尤其是在线程池中,不仅仅是内存泄露的问题,因为线程池中的线程是重复使用的,意味着这个线程的ThreadLocalMap对象也是重复使用的,如果我们不手动调用remove方法,那么后面的线程就有可能获取到上个线程遗留下来的value值,造成bug。
**调用get,set或remove方法时,就会尝试删除key为null的entry,可以释放value对象所占用的内存。**在threadLocal的生命周期里,针对threadLocal存在的内存泄漏的问题,都会通过expungeStaleEntry,cleanSomeSlots,replaceStaleEntry这三个方法清理掉key为null的脏entry。
3.3 总结
- ThreadLocal 并不解决线程间共享数据的问题
- ThreadLocal 适用于变量在线程间隔离且在方法间共享的场景
- ThreadLocal 通过隐式的在不同线程内创建独立实例副本避免了实例线程安全的问题
- 每个线程持有一个只属于自己的专属Map并维护了ThreadLocal对象与具体实例的映射,该Map由于只被持有它的线程访问,故不存在线程安全以及锁的问题
- ThreadLocalMap的Entry对ThreadLocal的引用为弱引用,避免了ThreadLocal对象无法被回收的问题
- 都会通过expungeStaleEntry,cleanSomeSlots,replaceStaleEntry这三个方法回收键为 null 的 Entry对象的值(即为具体实例)以及 Entry 对象本身从而防止内存泄漏,属于安全加固的方法