JUC并发编程高级篇第四章之ThreadLocal(人手一份,天下安)

文章目录

  • 1、ThreadLocal的简介
    • 1.1、常见的面试题(也是本次的讲解的内容)
    • 1.2、什么是ThreadLocal
    • 1.3、ThreadLocal的所用
    • 1.4、没有出现ThreadLocal前后的变化
    • 1.5、ThreadLocal代码示例
    • 1.6、阿里巴巴对ThreadLocal的使用要求
    • 1.7、ThreadLocal的源码分析
  • 2、ThreadLocal弱引用问题
    • 2.1、什么是内存泄露?
    • 2.2、什么是强/软/弱/虚 引用?
    • 2.3、ThreadLocal为什么要使用软引用
      • 2.3.1、如果使用强引用会内存泄漏吗?
      • 2.3.2、如果使用弱引用会内存泄漏吗?
      • 2.3.3、出现内存泄漏的真实原因
      • 2.3.4、JDK为什么最后选择弱引用呢?
      • 2.3.4、清楚脏entry
      • 2.3.5、为什么ThreadLocal有自动清理entry的机制,我们还需要注意调用remove
  • 3、ThreadLocalMap 没有Map中的链表,如何解决hash冲突?
    • 3.1、构造方法
    • 3.2、set方法
  • 4、ThreadLocal的最佳实践
  • 5、ThreadLocal的总结

1、ThreadLocal的简介

1.1、常见的面试题(也是本次的讲解的内容)

  1. ThreadLocal当中ThreadLocalMap的数据结构和关系
  2. ThreadLocal的key是弱引用,为什么
  3. ThreadLocal的内存泄露
  4. ThreadLocal为什么最后加入了remove方法

1.2、什么是ThreadLocal

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

1.3、ThreadLocal的所用

  • 实现每一个线程都有自己专属的本地变量副本(自己用自己的变量禧麻烦别人,不和其他人共享,人人有份,人各一份),
  • 主要解决了让每个线程绑定自己的值,通过使用get()和.set()方法,获取默认值或将其值更改为当前线程所存的副本的值从而避免了线程安全问题,比如我们之前讲解的8锁案例,资源类是使用同一部手机,多个线程抢夺同一部手机使用,假如人手一份是不是天下太平

特别注意:ThreadLocal设计的目的是帮助当前线程有属于自己的变量,并不是为了解决并发或共享变量的问题

1.4、没有出现ThreadLocal前后的变化

  • 没出现ThreadLocal之前, 不管是sync/local/cas 他们都是多个线程抢占一个资源
  • 出现ThreadLocal之后,每个线程都有属于自己的资源

1.5、ThreadLocal代码示例

需求1:: 5个销售卖房子,集团高层只关心销售总量的准确统计数,按照总销售额统计,方便集团公司给部分发送奖金

public class DeadlockExample {

    //5个销售卖房子,集团高层只关心销售总量的准确统计数,按照总销售额统计,方便集团公司给部分发送奖金
    public static void main(String[] args) throws InterruptedException {
        Hourse hourse = new Hourse();
        CountDownLatch countDownLatch = new CountDownLatch(5);
        for (int i = 0; i < 5; i++) {
            new Thread(()->{
                int size = new Random().nextInt(5) + 1;
                System.out.println(Thread.currentThread().getName()+"线程卖了"+size+"套");
                for (int j = 0; j < size; j++) {
                    hourse.saleHourse();
                }
                countDownLatch.countDown();
            },String.valueOf(i)).start();
        }
        countDownLatch.await();
        System.out.println("一共卖了"+hourse.getSaleCount());
    }
}


class Hourse {
    int saleCount = 0;
    public synchronized void saleHourse() {
        ++saleCount;
    }

    public int getSaleCount() {
        return saleCount;
    }
}


3线程卖了11线程卖了52线程卖了54线程卖了40线程卖了5套
一共卖了20

需求2: 5个销售卖完随机数房子,各自独立销售额度,自己业绩按提成走,分灶吃饭,各个销售自己动手,丰衣足食

public class DeadlockExample {

    //5个销售卖房子,集团高层只关心销售总量的准确统计数,按照总销售额统计,方便集团公司给部分发送奖金
    public static void main(String[] args) throws InterruptedException {
        Hourse hourse = new Hourse();
        CountDownLatch countDownLatch = new CountDownLatch(5);
        for (int i = 0; i < 5; i++) {
            new Thread(() -> {
                int size = new Random().nextInt(5) + 1;
                for (int j = 0; j < size; j++) {
                    hourse.saleSyncHourse();
                    hourse.saleThreadLocal();
                }
                System.out.println(Thread.currentThread().getName() + "线程卖了" + hourse.saleVolume.get() + "套");
                countDownLatch.countDown();
            }, String.valueOf(i)).start();
        }
        countDownLatch.await();
        System.out.println("一共卖了" + hourse.getSaleCount());
    }
}


class Hourse {
    ThreadLocal<Integer> saleVolume = ThreadLocal.withInitial(() -> 0);
    int saleCount = 0;

    public int getSaleCount() {
        return saleCount;
    }

    public synchronized void  saleSyncHourse(){
        ++saleCount;
    }

    public void saleThreadLocal(){
        saleVolume.set(1+saleVolume.get());
    }
}


4线程卖了41线程卖了32线程卖了13线程卖了20线程卖了1套
一共卖了11

1.6、阿里巴巴对ThreadLocal的使用要求

JUC并发编程高级篇第四章之ThreadLocal(人手一份,天下安)_第1张图片
原因:因为实际开发的场景中, 我们都是使用线程池,此时有些线程就会存在反复复用的情况,如果没有清理线程的ThreadLocal变量,则到了线程复用的时候,可能还是携带者过去的老数据,导致业务逻辑混乱

1.7、ThreadLocal的源码分析

结论1:Thread类包含ThreadLocal,ThreadLocal包含了ThreadLocalMap
JUC并发编程高级篇第四章之ThreadLocal(人手一份,天下安)_第2张图片
结论2:ThreadLocalMap中包含了继承弱引用的Entry
JUC并发编程高级篇第四章之ThreadLocal(人手一份,天下安)_第3张图片
结论3:ThreadLocalMap其实就是以ThreadLocal为key ,任意对象obejct为valu的entry
JUC并发编程高级篇第四章之ThreadLocal(人手一份,天下安)_第4张图片

2、ThreadLocal弱引用问题

谈到这个问题,我们需要先回归下基础知识

2.1、什么是内存泄露?

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

2.2、什么是强/软/弱/虚 引用?

强引用(Java默认new一个对象就是强引用)

  • 当内存不足,JVM开始垃圾回收,对于强引用的对象,就算是出现了OOM也不会对该对象进行回收,死都不收。
class MyClass{
    @Override
    protected void finalize() throws Throwable {
        System.out.println("我被调用了,我快要死了");
    }
}
public class ReferenceDemo {

    public static void main(String[] args) throws InterruptedException {
        MyClass myClass = new MyClass();
        System.out.println("gc object "+myClass);
        myClass =null;
        //主动触发gc
        System.gc();
        Thread.sleep(500);
        System.out.println("gc object "+myClass);
    }
}

gc object com.tvu.deathLock.MyClass@43556938
我被调用了,我快要死了
gc object null

软引用

  • 当系统内存充足时它不会回收
  • 当系统内存不充足时它会回收
  • 软引用通常用在对内存敏感的程序中,比如高速缓存就有用到软引用,内存够用的时候就保留,不够用就回收!
class MyClass{
    @Override
    protected void finalize() throws Throwable {
        System.out.println("我被调用了,我快要死了");
    }
}
public class ReferenceDemo {

    public static void main(String[] args) throws InterruptedException {
        SoftReference<MyClass> myClassSoftReference = new SoftReference<>(new MyClass());
        System.gc();
        System.out.println("gc after:" + myClassSoftReference.get());
    }
}

gc 内存够用 after:com.tvu.deathLock.MyClass@43556938

弱引用

  • 弱引用需要用java.lang.ref.WeakReference类来实现,它比软引用的生存期更短,
  • 对于只有弱引用的对象来说,只要垃圾回收机制一运行,不管JVM的内存空间是否足够,都会回收该对象占用的内存。
    假如有一个应用需要读取大量的本地图片,如果每次读取图片都从硬盘读取则会严重影响性能,
    如果一次性全部加载到内存中又可能造成内存溢出。此时使用软引用可以解决这个问题。设计思路是:用一个HashMap来保存图片的路径和相应图片对象关联的软引用之间的映射关系,在内存不足时,JVM会自动回收这些缓存图片对象所占用的空间,从而有效地避免了OOM的问题。Map>imageCache = new HashMap>();

虚引用

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

2.3、ThreadLocal为什么要使用软引用

2.3.1、如果使用强引用会内存泄漏吗?

在这里插入图片描述
1:上面ThreadLocalRef he CurrentThreadRef 分别代码ThreadLocal和CurrentThread的引用,他们分别存储在栈里面

2.3.2、如果使用弱引用会内存泄漏吗?

在这里插入图片描述

2.3.3、出现内存泄漏的真实原因

在这里插入图片描述

2.3.4、JDK为什么最后选择弱引用呢?

在这里插入图片描述

2.3.4、清楚脏entry

ThreadLocal 再进行set/get/remove的时候都对空的entry进行检查和清除;

set()

JUC并发编程高级篇第四章之ThreadLocal(人手一份,天下安)_第5张图片
JUC并发编程高级篇第四章之ThreadLocal(人手一份,天下安)_第6张图片

get()
JUC并发编程高级篇第四章之ThreadLocal(人手一份,天下安)_第7张图片
JUC并发编程高级篇第四章之ThreadLocal(人手一份,天下安)_第8张图片
remove
JUC并发编程高级篇第四章之ThreadLocal(人手一份,天下安)_第9张图片

2.3.5、为什么ThreadLocal有自动清理entry的机制,我们还需要注意调用remove

虽然set和get方法会帮我们清理entry为null的值,但是如果一个ThreadLocal对象被创建后,在某个线程中调用了set方法设置了一个值,但是在后续的代码中没有调用get或remove方法来清除这个值,那么这个值就会一直存在于这个ThreadLocal对象中,直到线程结束。如果这个线程是一个长期运行的线程,那么这个值就会一直存在于内存中,占用一定的空间,从而导致内存泄漏。

3、ThreadLocalMap 没有Map中的链表,如何解决hash冲突?

3.1、构造方法

     ThreadLocalMap(ThreadLocal<?> firstKey, Object firstValue) {
            table = new Entry[INITIAL_CAPACITY];
            //计算索引
            int i = firstKey.threadLocalHashCode & (INITIAL_CAPACITY - 1);
            table[i] = new Entry(firstKey, firstValue);
            //entry存储的个数,因为是构造函数,所以是1
            size = 1;
            setThreshold(INITIAL_CAPACITY);
        }


===========================threadLocalHashCode 相关代码======================================
 private final int threadLocalHashCode = nextHashCode();

 private static int nextHashCode() {
         //HASH_INCREMENT 是为了让hash均匀的分布,尽量避免
        return nextHashCode.getAndAdd(HASH_INCREMENT);
    }

 public final int getAndAdd(int delta) {
        return unsafe.getAndAddInt(this, valueOffset, delta);
    }
    
   public final int getAndAddInt(Object var1, long var2, int var4) {
        int var5;
        do {
            var5 = this.getIntVolatile(var1, var2);
        } while(!this.compareAndSwapInt(var1, var2, var5, var5 + var4));

        return var5;
    }
 ==========================INITIAL_CAPACITY - 1)============================================
 学过HashMap的都知道,容量被设置为2的n次方,当进行-1的时候,此时2进制的最后一位都是1,此时相当于提高了效率,比如此时10进行4预算,此时如果为1的话,后面基本上就不用看啦
 

3.2、set方法

private void set(ThreadLocal<?> key, Object value) {

            // We don't use a fast path as with get() because it is at
            // least as common to use set() to create new entries as
            // it is to replace existing ones, in which case, a fast
            // path would fail more often than not.

            Entry[] tab = table;
            int len = tab.length;
            //计算索引,刚刚分析过啦
            int i = key.threadLocalHashCode & (len-1);
            //使用线性查找法查找元素
            for (Entry e = tab[i];
                 e != null;
                 e = tab[i = nextIndex(i, len)]) {
                ThreadLocal<?> k = e.get();
                 //threadlocal对应的key存在,覆盖之前的值
                if (k == key) {
                    e.value = value;
                    return;
                }
                //如果不存在,说明被回收啦,当前数据中entry是一个陈旧的元素
                if (k == null) {
                   //用新元素代替旧元素,这个方法进行了不少清理垃圾的动作,防止内存泄漏
                    replaceStaleEntry(key, value, i);
                    return;
                }
            }
           //如果key不存在,并且没有找到陈旧的元素,则在空位置上进行新创建新的entry
            tab[i] = new Entry(key, value);
            int sz = ++size;
            //清除e.get() = null的元素
            //这种数据关联key关联的对象,已经被回收啦,所以entry(table (index)可以设置为null
            //如果没有清楚任何的entry,并且当前的使用量达到了负载银子,那么进行rehash
            if (!cleanSomeSlots(i, sz) && sz >= threshold)
                rehash();
        }

在这里插入图片描述

总结:

和HashMap的最大的不同在于,ThreadLocalMap结构非常简单,没有next引用,也就是说ThreadLocalMap中解决Hash冲突的方式并非链表的方式,而是采用线性探测的方式,所谓线性探测,就是根据初始key的hashcode值确定元素在table数组中的位置,如果发现这个位置上已经有其他key值的元素被占用,则利用固定的算法寻找一定步长的下个位置,依次判断,直至找到能够存放的位置。

ThreadLocalMap解决Hash冲突的方式就是简单的步长加1或减1,寻找下一个相邻的位置。

/**
 * Increment i modulo len.
 */
private static int nextIndex(int i, int len) {
    return ((i + 1 < len) ? i + 1 : 0);
}
 
/**
 * Decrement i modulo len.
 */
private static int prevIndex(int i, int len) {
    return ((i - 1 >= 0) ? i - 1 : len - 1);
}

显然ThreadLocalMap采用线性探测的方式解决Hash冲突的效率很低,如果有大量不同的ThreadLocal对象放入map中时发送冲突,或者发生二次冲突,则效率很低。

所以这里引出的良好建议是:每个线程只存一个变量,这样的话所有的线程存放到map中的Key都是相同的ThreadLocal,如果一个线程要保存多个变量,就需要创建多个ThreadLocal,多个ThreadLocal放入Map中时会极大的增加Hash冲突的可能

4、ThreadLocal的最佳实践

  • 1.尽量初始化 ThreadLocal tl = ThreadLocal.withInitial(()->“1”);
  • 2.建议把ThreadLocal修饰为static (ThreadLocal能够实现数据的隔离,不在于它自己本身,而是Thead的ThreadLocalMap所以ThreadLocal可以只初始化一次,只分配一块存储空间就行了,没必要作为成员变量多次被初始化)
  • 3.用完记得remove

5、ThreadLocal的总结

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

你可能感兴趣的:(java,jvm,开发语言)