关于java:撸完腾讯T4大佬整理的ThreadLocal笔记解决内存泄漏只是小儿科

上一篇是分享的是《pring Boot中AOP与SpEL》,这篇分享的是《ThreadLocal应用与原理》。

ThreadLocal应用与原理

在解决多线程并发平安的办法中,最罕用的办法,就是应用锁,通过锁来管制多个不同线程对临界区的拜访。
然而,无论是什么样的锁,乐观锁或者乐观锁,都会在并发抵触的时候对性能产生肯定的影响。
那有没有一种办法,能够彻底防止竞争呢?
答案是必定的,这就是ThreadLocal。
从字面意思上看,ThreadLocal能够解释成线程的局部变量,也就是说一个ThreadLocal的变量只有以后本身线程能够拜访,别的线程都拜访不了,那么天然就防止了线程竞争。
因而,ThreadLocal提供了一种不同凡响的线程平安形式,它不是在产生线程抵触时想方法解决抵触,而是彻底的防止了抵触的产生。
ThreadLocal的根本应用
创立一个ThreadLocal对象:

private ThreadLocal localInt = new ThreadLocal<>();

上述代码创立一个localInt变量,因为ThreadLocal是一个泛型类,这里指定了localInt的类型为整数。
上面展现了如果设置和获取这个变量的值:

public int setAndGet(){ localInt.set(8); return localInt.get(); }

上述代码设置变量的值为8,接着获得这个值。

因为ThreadLocal里设置的值,只有以后线程本人看得见,这意味着你不可能通过其余线程为它初始化值。为了补救这一点,ThreadLocal提供了一个withInitial()办法对立初始化所有线程的ThreadLocal的值:

private ThreadLocal localInt = ThreadLocal.withInitial(() -> 6);

上述代码将ThreadLocal的初始值设置为6,这对整体线程都是可见的。

ThreadLocal的实现原理
ThreadLocal变量只在单个线程内可见,那它是如何做到的呢?咱们先从最根本的get()办法说起:

public T get() {
    //取得以后线程
    Thread t = Thread.currentThread();
    //每个线程 都有一个本人的ThreadLocalMap,
    //ThreadLocalMap里就保留着所有的ThreadLocal变量
    ThreadLocalMap map = getMap(t);
    if (map != null) {
        //ThreadLocalMap的key就是以后ThreadLocal对象实例,
        //多个ThreadLocal变量都是放在这个map中的
        ThreadLocalMap.Entry e = map.getEntry(this);
        if (e != null) {
            @SuppressWarnings("unchecked")
            //从map里取出来的值就是咱们须要的这个ThreadLocal变量
            T result = (T)e.value;
            return result;
        }
    }
    // 如果map没有初始化,那么在这里初始化一下
    return setInitialValue();
}

能够看到,所谓的ThreadLocal变量就是保留在每个线程的map中的。这个map就是Thread对象中的threadLocals字段。如下:

ThreadLocal.ThreadLocalMap threadLocals = null;

ThreadLocal.ThreadLocalMap是一个比拟非凡的Map,它的每个Entry的key都是一个弱援用:

static class Entry extends WeakReference> {
    /** The value associated with this ThreadLocal. */
    Object value;
    //key就是一个弱援用
    Entry(ThreadLocal k, Object v) {
        super(k);
        value = v;
    }
}

这样设计的益处是,如果这个变量不再被其余对象应用时,能够主动回收这个ThreadLocal对象,防止可能的内存泄露(留神,Entry中的value,仍然是强援用,如何回收,见下文合成)。

了解ThreadLocal中的内存透露问题
尽管ThreadLocalMap中的key是弱援用,当不存在内部强援用的时候,就会主动被回收,然而Entry中的value仍然是强援用。这个value的援用链条如下:

能够看到,只有当Thread被回收时,这个value才有被回收的机会,否则,只有线程不退出,value总是会存在一个强援用。然而,要求每个Thread都会退出,是一个极其刻薄的要求,对于线程池来说,大部分线程会始终存在在零碎的整个生命周期内,那样的话,就会造成value对象呈现透露的可能。解决的办法是,在ThreadLocalMap进行set(),get(),remove()的时候,都会进行清理:

以getEntry()为例:

private Entry getEntry(ThreadLocal key) {
    int i = key.threadLocalHashCode & (table.length - 1);
    Entry e = table[i];
    if (e != null && e.get() == key)
        //如果找到key,间接返回
        return e;
    else
        //如果找不到,就会尝试清理,如果你总是拜访存在的key,那么这个清理永远不会进来
        return getEntryAfterMiss(key, i, e);
}

上面是getEntryAfterMiss()的实现:

private Entry getEntryAfterMiss(ThreadLocal key, int i, Entry e) {
    Entry[] tab = table;
    int len = tab.length;

    while (e != null) {
        // 整个e是entry ,也就是一个弱援用
        ThreadLocal k = e.get();
        //如果找到了,就返回
        if (k == key)
            return e;
        if (k == null)
            //如果key为null,阐明弱援用曾经被回收了
            //那么就要在这里回收外面的value了
            expungeStaleEntry(i);
        else
            //如果key不是要找的那个,那阐明有hash抵触,这里是解决抵触,找下一个entry
            i = nextIndex(i, len);
        e = tab[i];
    }
    return null;
}

真正用来回收value的是expungeStaleEntry()办法,在remove()和set()办法中,都会间接或者间接调用到这个办法进行value的清理:

从这里能够看到,ThreadLocal为了防止内存泄露,也算是花了一番大心理。不仅应用了弱援用保护key,还会在每个操作上查看key是否被回收,进而再回收value。

然而从中也能够看到,ThreadLocal并不能100%保障不产生内存透露。

比方,很可怜的,你的get()办法总是拜访固定几个始终存在的ThreadLocal,那么清理动作就不会执行,如果你没有机会调用set()和remove(),那么这个内存透露仍然会产生。

因而,一个良好的习惯仍然是:当你不须要这个ThreadLocal变量时,被动调用remove(),这样对整个零碎是有益处的。

ThreadLocalMap中的Hash抵触解决
ThreadLocalMap作为一个HashMap和java.util.HashMap的实现是不同的。对于java.util.HashMap应用的是链表法来解决抵触:

然而,对于ThreadLocalMap,它应用的是简略的线性探测法,如果产生了元素抵触,那么就应用下一个槽位寄存:

具体来说,整个set()的过程如下:

能够被继承的ThreadLocal——InheritableThreadLocal
在理论开发过程中,咱们可能会遇到这么一种场景。主线程开了一个子线程,然而咱们心愿在子线程中能够拜访主线程中的ThreadLocal对象,也就是说有些数据须要进行父子线程间的传递。比方像这样:

public static void main(String[] args) {
    ThreadLocal threadLocal = new ThreadLocal();
    IntStream.range(0,10).forEach(i -> {
        //每个线程的序列号,心愿在子线程中可能拿到
        threadLocal.set(i);
        //这里来了一个子线程,咱们心愿能够拜访下面的threadLocal
        new Thread(() -> {
            System.out.println(Thread.currentThread().getName() + ":" + threadLocal.get());
        }).start();
        try {
            Thread.sleep(1000);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    });
}

执行上述代码,你会看到:

Thread-0:null
Thread-1:null
Thread-2:null
Thread-3:null

因为在子线程中,是没有threadLocal的。如果咱们心愿子线能够看到父线程的ThreadLocal,那么就能够应用InheritableThreadLocal。顾名思义,这就是一个反对线程间父子继承的ThreadLocal,将上述代码中的threadLocal应用InheritableThreadLocal:

InheritableThreadLocal threadLocal = new InheritableThreadLocal();

再执行,就能看到:

Thread-0:0
Thread-1:1
Thread-2:2
Thread-3:3
Thread-4:4

能够看到,每个线程都能够拜访到从父过程传递过去的一个数据。尽管InheritableThreadLocal看起来挺不便的,然而仍然要留神以下几点:

变量的传递是产生在线程创立的时候,如果不是新建线程,而是用了线程池里的线程,就不灵了

变量的赋值就是从主线程的map复制到子线程,它们的value是同一个对象,如果这个对象自身不是线程平安的,那么就会有线程平安问题

写在最初的话
明天,咱们介绍了ThreadLocal,ThreadLocal在Java的多线程开发中有着非常重要的作用。

在这里,咱们介绍了ThreadLocal的根本应用和实现原理,尤其重点介绍了基于以后实现原理下可能存在的内存透露问题。

最初,还介绍了一个用于在父子线程间传递数据的非凡的ThreadLocal实现,心愿对大家有所帮忙。

  • 以上就是《《ThreadLocal应用与原理》的分享。
  • 也欢送大家交换探讨,该文章若有不正确的中央,心愿大家多多包涵。
  • 你们的反对就是我最大的能源,如果对大家有帮忙给个赞哦~~~

评论

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注

这个站点使用 Akismet 来减少垃圾评论。了解你的评论数据如何被处理