前言

平时并发编程，除了保护批改共享变量的场景，有时咱们也须要为每一个线程设置一个公有的变量，进行线程隔离，java提供的ThreadLocal能够帮忙咱们实现，而讲到ThreadLocal则不得不讲讲java的四种援用，不同的援用类型在GC时体现是不一样的，援用类型Reference有助于咱们理解如何疾速回收某些对象的内存或对实例的GC管制

• 四种援用类型在JVM的生命周期
• 援用队列(ReferenceQueue)
• ThreadLocal的实现原理和应用
• FinalReference和finalize办法的实现原理
• Cheaner机制

关注公众号，一起交换，微信搜一搜: 潜行前行

1 四种援用类型在JVM的生命周期

强援用(StrongReference)

• 创立一个对象并赋给一个援用变量，强援用有援用变量指向时，永远也不会垃圾回收，JVM宁愿抛出OutOfMemory异样也不会回收该对象；强援用对象的创立，如

Integer index = new Integer(1);String name = "csc";

• 如果中断所有援用变量和强援用对象的分割（将援用变量赋值为null），JVM则会在适合的工夫就会回收该对象

软援用(SoftReference)

• 和强用援用不同点在于内存不足时，该类型援用对象会被垃圾处理器回收
• 应用软援用能避免内存泄露，加强程序的健壮性。SoftReference的特点是它的一个实例保留对一个Java对象的软援用，该软援用的存在不障碍垃圾收集线程对该Java对象的回收
• SoftReference类所提供的get()办法返回Java对象的强援用。另外，一旦垃圾线程回收该对象之后，get()办法将返回null

    String name = "csc";    //软援用的创立    SoftReference<String> softRef = new SoftReference<String>(name);    System.out.println(softRef.get());

弱援用(WeakReference)

• 特点：无论内存是否短缺，只有进行GC，都会被回收

    String name = "csc";    //弱援用的创立    WeakReference<String> softRef = new WeakReference<String>(name);    System.out.println(softRef.get()); //输入 csc    System.gc();    System.out.println(softRef.get()); //输入 null    //弱援用Map    WeakHashMap<String, String> map = new WeakHashMap<String, String>();

虚援用(PhantomReference)

• 特点：如同虚设，和没有援用没什么区别；虚援用和软援用、弱援用不同，它并不决定对象的生命周期。如果一个对象与虚援用关联，则跟没有援用与之关联一样，在任何时候都可能被垃圾回收器回收
• 要留神的是，虚援用必须和援用队列关联应用，当垃圾回收器筹备回收一个对象时，如果发现它还有虚援用，就会把这个虚援用退出到与之关联的援用队列中。程序能够通过判断援用队列中是否曾经退出了虚援用，来理解被援用的对象是否将要被垃圾回收

public static void main(String[] args) {    String name = "csc";    ReferenceQueue<String> queue = new ReferenceQueue<String>();      PhantomReference<String> pr = new PhantomReference<String>(name, queue);      //PhantomRefrence的get办法总是返回null，因而无法访问对应的援用对象。    System.out.println(pr.get());  // null    System.gc();    System.out.println(queue.poll()); //获取被垃圾回收的"xb"的援用ReferenceQueue}

2 援用队列(ReferenceQueue)

• 援用队列能够配合软援用、弱援用及虚援用应用；当援用的对象将要被JVM回收时，会将其退出到援用队列中

  ReferenceQueue<String> queue = new ReferenceQueue<String>();    WeakReference<String> pr = new WeakReference<String>("wxj", queue);   System.gc();  System.out.println(queue.poll().get()); // 获取行将被回收的字符串　wxj

3 ThreadLocal的原理和应用

ThreadLocal 的实现原理

• 每个线程都内置了一个ThreadLocalMap对象

public class Thread implements Runnable {    /* 以后线程对于的ThreadLocalMap实例，ThreadLocal<T>作为Key,      * T对应的对象作为value */    ThreadLocal.ThreadLocalMap threadLocals = null;

• ThreadLocalMap作为ThreadLocal的外部类，实现了相似HashMap的性能，它元素Entry继承于WeakReference，key值是ThreadLocal，value是援用变量。也就是说jvm产生GC时value对象则会被回收

public class ThreadLocal<T> {    //ThreadLocal对象对应的hash值，应用一个动态AtomicInteger实现    private final int threadLocalHashCode = nextHashCode();    //设置value    public void set(T value) {        Thread t = Thread.currentThread();          ThreadLocalMap map = getMap(t);        if (map != null)            map.set(this, value);        else            createMap(t, value);    }    //获取value    public T get() {        Thread t = Thread.currentThread();        ThreadLocalMap map = getMap(t);        if (map != null) {      　　　　//获取以后线程的ThreadLocalMap，再应用对象ThreadLocal获取对应的value            ThreadLocalMap.Entry e = map.getEntry(this);            if (e != null) {                @SuppressWarnings("unchecked")                T result = (T)e.value;                return result;            }        }        return setInitialValue();    }    ....    //相似HashMap的类    static class ThreadLocalMap {        //应用凋谢地址法解决hash抵触        //如果hash出的index曾经有值，通过算法在前面的若干地位寻找空位        private Entry[] table;        ...        //Entry 是弱援用        static class Entry extends WeakReference<ThreadLocal<?>> {            /** The value associated with this ThreadLocal. */            Object value;            Entry(ThreadLocal<?> k, Object v) {                super(k);                value = v;            }        }   }     

ThreadLocal不保障共享变量在多线程的安全性

• 从ThreadLocal的实现原理可知，ThreadLocal只是为每个线程保留一个正本变量，正本变量的批改不影响其余线程的变量值，因而ThreadLocal不能实现共享变量的安全性

ThreadLocal 应用场景

• 线程平安，包裹线程不平安的工具类，比方java.text.SimpleDateFormat类，当然jdk1.8曾经给出了对应的线程平安的类java.time.format.DateTimeFormatter
• 线程隔离，比方数据库连贯治理、Session治理、mdc日志追踪等。

ThreadLocal内存泄露和WeakReference

• ThreadLocalMap.Entry是弱援用，弱援用对象是不论有没有被援用都会被垃圾回收
• 产生内存透露个别是在线程池的线程，生命周期长，threadLocals援用会始终存在，当其寄存的ThreadLocal被回收（弱援用生命周期短）后，它对应的Entity成了e.get()==null的实例。线程不死则Entity始终不会被回收，这就产生了内存透露
• 如果线程跨业务操作雷同的ThreadLocal，还会造成变量平安问题
• 通常在应用完ThreadLocal最好调用它的remove()；在ThreadLocal的get、set的时候，最好查看以后Entity的key是否为null，如果是null就把Entity开释掉，value则会被垃圾回收

4 finalize办法的实现原理FinalReference

final class Finalizer extends FinalReference<Object> { 　　private static ReferenceQueue<Object> queue = new ReferenceQueue<>();      /* Invoked by VM */   static void register(Object finalizee) {        new Finalizer(finalizee);   }   private static class FinalizerThread extends Thread {        ....        public void run() {            ...            for (;;) {                try {                    Finalizer f = (Finalizer)queue.remove();                    //这里会实现Object.finalize的调用                    f.runFinalizer(jla);           ....    }       static {        ...        Thread finalizer = new FinalizerThread(tg);        ...　//执行Object.finalize的守护线程        finalizer.setDaemon(true);        finalizer.start();    }    

• cpu资源比拟稀缺的状况下FinalizerThread线程有可能因为优先级比拟低而提早执行finalizer对象的finalize办法
• 因为finalizer对象的finalize办法迟迟没有执行，有可能会导致大部分finalizer对象进入到old分代，此时容易引发old分代的gc，甚至fullgc，gc暂停工夫显著变长

5 Cheaner机制

• 上一篇文章有介绍到jdk1.8的Cleaner框架篇：ByteBuffer和netty.ByteBuf详解

欢送指注释中谬误

参考文章

• ThreadLocal原理及应用场景大揭秘
• JDK源码剖析之FinalReference齐全解读
• 一次 Young GC 的优化实际
• Netty资源泄露检测
• 防止应用Finalizer和Cleaner机制
• 【JAVA Reference】Cleaner 源码分析（三）