JUC之ThreadLocal

面试题

  1. ThreadLocal中ThreadLocalMap的数据结构和关系?
  2. ThreadLocal的key是弱引用,这是为什么?
  3. ThreadLocal内存泄露问题你知道吗?
  4. ThreadLocal中最后为什么要加remove方法?

介绍

ThreadLocal提供线程局部变量。这些变量与正常的变量不同,因为每一个线程在访问ThreadLocal实例的时候(通过其get或set方法)都有自己的、独立初始化的变量副本。ThreadLocal实例通常是类中的私有静态字段,使用它的目的是希望将状态(例如,用户ID或事务ID)与线程关联起来。

作用

实现每一个线程都有自己专属的本地变量副本,主要解决了让每个线程绑定自己的值,通过使用get()和set()方法,获取默认值或将其值更改为当前线程所存的副本的值从而避免了线程安全问题;

  1. 因为每个 Thread 内有自己的实例副本且该副本只由当前线程自己使用
  2. 既然其它 Thread 不可访问,那就不存在多线程间共享的问题。
  3. 统一设置初始值,但是每个线程对这个值的修改都是各自线程互相独立的

非线程安全的SimpleDateFormat

阿里开发手册

JUC之ThreadLocal_第1张图片

每个SimpleDateFormat对象中会引用一个Calendar,当我们使用静态的SimpleDateFormat对象时 第一个线程刚在calendar设置完,这个线程的cpu分片时间到了,下一个线程同时也设置了这个值,这样就把第一个线程设置的值给覆盖了,那么在第一个线程拿到cpu调度权时,结果已经被改了,导致线程不安全!!
例如:

public class DateUtil {

    static SimpleDateFormat format = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");

    public static void main(String[] args) {
        for (int i = 0; i < 30; i++) {
            new Thread(() -> {
                try {
                    System.out.println(DateUtil.format.parse("2023-08-07 11:11:11"));
                } catch (ParseException e) {
                    e.printStackTrace();
                }
            }).start();
        }
    }
}

JUC之ThreadLocal_第2张图片

源码解析

JUC之ThreadLocal_第3张图片
JUC之ThreadLocal_第4张图片
SimpleDateFormat类内部有一个Calendar对象引用,它用来储存和这个SimpleDateFormat相关的日期信息;
例如sdf.parse(dateStr),sdf.format(date) 诸如此类的方法参数传入的日期相关String,Date等等, 都是交由Calendar引用来储存的.这样就会导致一个问题如果你的SimpleDateFormat是个static的, 那么多个thread 之间就会共享这个SimpleDateFormat, 同时也是共享这个Calendar引用。

解决1

将SimpleDateFormat定义成局部变量。缺点:每调用一次方法就会创建一个SimpleDateFormat对象,方法结束又要作为垃圾回收;

解决2

ThreadLocal,也叫做线程本地变量或者线程本地存储;

其他
  1. 加锁
  2. 第三方时间库

ThreadLocal源码解析

Thread

public
class Thread implements Runnable {
    ...
    /* ThreadLocal values pertaining to this thread. This map is maintained
     * by the ThreadLocal class. */
    // ThreadLocalMap 是以ThreadLocal为key,以设置的value为value的Entry的对象
    ThreadLocal.ThreadLocalMap threadLocals = null;
    ...
}

ThreadLocal

public class ThreadLocal<T> {

	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();
    }
    
     public void set(T value) {
        Thread t = Thread.currentThread();
        ThreadLocalMap map = getMap(t);
        if (map != null)
            map.set(this, value);
        else
            createMap(t, value);
    }

    public void remove() {
         ThreadLocalMap m = getMap(Thread.currentThread());
         if (m != null)
             m.remove(this);
     }

    ThreadLocalMap getMap(Thread t) {
        return t.threadLocals;
    }

    /**
     * Create the map associated with a ThreadLocal. Overridden in
     * InheritableThreadLocal.
     *
     * @param t the current thread
     * @param firstValue value for the initial entry of the map
     */
    void createMap(Thread t, T firstValue) {
        t.threadLocals = new ThreadLocalMap(this, firstValue);
    }
    
     static class ThreadLocalMap {

        /**
         * The entries in this hash map extend WeakReference, using
         * its main ref field as the key (which is always a
         * ThreadLocal object).  Note that null keys (i.e. entry.get()
         * == null) mean that the key is no longer referenced, so the
         * entry can be expunged from table.  Such entries are referred to
         * as "stale entries" in the code that follows.
         */
        static class Entry extends WeakReference<ThreadLocal<?>> {
            /** The value associated with this ThreadLocal. */
            Object value;

            Entry(ThreadLocal<?> k, Object v) {
                super(k);
                value = v;
            }
        }
     }
}

结构图

JUC之ThreadLocal_第5张图片

  • threadLocalMap实际上就是一个以threadLocal实例为key,任意对象为value的Entry对象。
  • 当我们为threadLocal变量赋值,实际上就是以当前threadLocal实例为key,值为value的Entry往这个threadLocalMap中存放

JVM内部维护了一个线程版的Map(通过ThreadLocal对象的set方法,结果把ThreadLocal对象自己当做key,放进了ThreadLoalMap中),每个线程要用到这个T的时候,用当前的线程去Map里面获取,通过这样让每个线程都拥有了自己独立的变量,竞争条件被彻底消除,在并发模式下是绝对安全的变量。

ThreadLocal内存泄露问题

不再会被使用的对象或者变量占用的内存不能被回收,就是内存泄露。

阿里开发手册

JUC之ThreadLocal_第6张图片

四种引用分别是什么

强引用(默认支持模式)

  • 当内存不足,JVM开始垃圾回收,对于强引用的对象,就算是出现了OOM也不会对该对象进行回收,死都不收。
  • 强引用是我们最常见的普通对象引用,只要还有强引用指向一个对象,就能表明对象还“活着”,垃圾收集器不会碰这种对象。在 Java 中最常见的就是强引用,把一个对象赋给一个引用变量,这个引用变量就是一个强引用。当一个对象被强引用变量引用时,它处于可达状态,它是不可能被垃圾回收机制回收的,即使该对象以后永远都不会被用到JVM也不会回收。因此强引用是造成Java内存泄漏的主要原因之一。
  • 对于一个普通的对象,如果没有其他的引用关系,只要超过了引用的作用域或者显式地将相应(强)引用赋值为 null,一般认为就是可以被垃圾收集的了(当然具体回收时机还是要看垃圾收集策略)。

软引用

  • 软引用是一种相对强引用弱化了一些的引用,需要用java.lang.ref.SoftReference类来实现,可以让对象豁免一些垃圾收集。
  • 对于只有软引用的对象来说
    1. 当系统内存充足时它不会被回收;
    2. 但系统内存不足时它会被回收;

软引用通常用在对内存敏感的程序中,比如高速缓存就有用到软引用,内存够用的时候就保留,不够用就回收!

弱引用

  • 弱引用需要用java.lang.ref.WeakReference类来实现,它比软引用的生存期更短,
  • 对于只有弱引用的对象来说,只要垃圾回收机制一运行,不管JVM的内存空间是否足够,都会回收该对象占用的内存。 虚引用需要java.lang.ref.PhantomReference类来实现。

顾名思义,就是形同虚设,与其他几种引用都不同,虚引用并不会决定对象的生命周期。如果一个对象仅持有虚引用,那么它就和没有任何引用一样,在任何时候都可能被垃圾回收器回收,它不能单独使用也不能通过它访问对象,虚引用必须和引用队列 (ReferenceQueue)联合使用。
虚引用的主要作用是跟踪对象被垃圾回收的状态。 仅仅是提供了一种确保对象被 finalize以后,做某些事情的机制。 PhantomReference的get方法总是返回null,因此无法访问对应的引用对象。
其意义在于:说明一个对象已经进入finalization阶段,可以被gc回收,用来实现比finalization机制更灵活的回收操作。
换句话说,设置虚引用关联的唯一目的,就是在这个对象被收集器回收的时候收到一个系统通知或者后续添加进一步的处理。

虚引用

虚引用需要java.lang.ref.PhantomReference类来实现。
顾名思义,就是形同虚设,与其他几种引用都不同,虚引用并不会决定对象的生命周期。如果一个对象仅持有虚引用,那么它就和没有任何引用一样,在任何时候都可能被垃圾回收器回收,它不能单独使用也不能通过它访问对象,虚引用必须和引用队列 (ReferenceQueue)联合使用。
虚引用的主要作用是跟踪对象被垃圾回收的状态。 仅仅是提供了一种确保对象被 finalize以后,做某些事情的机制。 PhantomReference的get方法总是返回null,因此无法访问对应的引用对象。
其意义在于:说明一个对象已经进入finalization阶段,可以被gc回收,用来实现比finalization机制更灵活的回收操作。
换句话说,设置虚引用关联的唯一目的,就是在这个对象被收集器回收的时候收到一个系统通知或者后续添加进一步的处理。

引用队列

虚引用对象:在对象回收前发现有虚引用,先去队列中查看是否有该虚引用,如果有则回收,如果没有则先将其加入后回收;
软引用和弱引用对象在标记为可回收状态时,并非立即加入引用队列,而是等待垃圾回收线程在适当适
合加入(不同的垃圾回收机制,加入队列世纪可能有所不同)

为什么会造成内存泄漏

ThreadLocalMap与WeakReference

JUC之ThreadLocal_第7张图片
ThreadLocalMap从字面上就可以看出这是一个保存ThreadLocal对象的map(其实是以它为Key),不过是经过了两层包装的ThreadLocal对象:

  1. 第一层包装是使用 WeakReference> 将ThreadLocal对象变成一个弱引用的对象;
  2. 第二层包装是定义了一个专门的类 Entry 来扩展 WeakReference>

关系

JUC之ThreadLocal_第8张图片
每个Thread对象维护着一个ThreadLocalMap的引用ThreadLocalMap是ThreadLocal的内部类,用Entry来进行存储调用ThreadLocal的set()方法时,实际上就是往ThreadLocalMap设置值,key是ThreadLocal对象,值Value是传递进来的对象调用ThreadLocal的get()方法时,实际上就是往ThreadLocalMap获取值,key是ThreadLocal对象ThreadLocal本身并不存储值,它只是自己作为一个key来让线程从ThreadLocalMap获取value,正因为这个原理,所以ThreadLocal能够实现“数据隔离”,获取当前线程的局部变量值,不受其他线程影响

为什么要用弱引用,弱引用可以解决内存泄漏吗

JUC之ThreadLocal_第9张图片

  1. 当线程结束了会释放对ThreadLocal的引用,如果ThreadLocalMap时强引用的话就会造成一会存在对ThreadLocal的引用,导致ThreadLocal对象无法回收;
  2. 当我们为threadLocal变量赋值,实际上就是当前的Entry(threadLocal实例为key,值为value)往这个threadLocalMap中存放。Entry中的key是弱引用,当threadLocal外部强引用被置为null,那么系统 GC 的时候,根据可达性分析,这个threadLocal实例就没有任何一条链路能够引用到它,这个ThreadLocal势必会被回收,这样一来,ThreadLocalMap中就会出现key为null的Entry,就没有办法访问这些key为null的Entry的value,如果当前线程再迟迟不结束的话,这些key为null的Entry的value就会一直存在一条强引用链:Thread Ref -> Thread -> ThreaLocalMap -> Entry -> value永远无法回收,造成内存泄漏。(每个线程中存在对ThreadLocalMap的引用)
    1. 当然,如果当前thread运行结束,threadLocal,threadLocalMap,Entry没有引用链可达,在垃圾回收的时候都会被系统进行回收。
    2. 但在实际使用中我们有时候会用线程池去维护我们的线程,比如在Executors.newFixedThreadPool()时创建线程的时候,为了复用线程是不会结束的;

在threadLocal的生命周期里,针对threadLocal存在的内存泄漏的问题,都会通过expungeStaleEntry,cleanSomeSlots,replaceStaleEntry这三个方法清理掉key为null的脏entry。

总结

  1. ThreadLocal 并不解决线程间共享数据的问题
  2. ThreadLocal 适用于变量在线程间隔离且在方法间共享的场景
  3. ThreadLocal 通过隐式的在不同线程内创建独立实例副本避免了实例线程安全的问题
  4. 每个线程持有一个只属于自己的专属Map并维护了ThreadLocal对象与具体实例的映射,该Map由于只被持有它的线程访问,故不存在线程安全以及锁的问题
  5. ThreadLocalMap的Entry对ThreadLocal的引用为弱引用,避免了ThreadLocal对象无法被回收的问题
  6. 都会通过expungeStaleEntry,cleanSomeSlots,replaceStaleEntry这三个方法回收键为 null 的 Entry 对象的值(即为具体实例)以及 Entry 对象本身从而防止内存泄漏,属于安全加固的方法

你可能感兴趣的:(JUC,JUC,线程,Java,高并发,java,面试,ThreadLocal)