zoukankan      html  css  js  c++  java
  • JDK源码分析(7)之 Reference 框架概览

    对于Reference类大家可能会比较陌生,平时用的也比较少,对他的印象可能仅停在面试的时候查看引用相关的知识点;但在仔细查看源码后发现Reference还是非常实用的,平时我们使用的类都是强引用的,它的回收完全依赖于 GC;但是对于有些类我们想要自己控制的时候就比较麻烦,比如我想在内存还足够的时候就保留,不够的时候就回收,这时使用Reference就能够十分灵活的控制类的存亡了。

    一、类定义

    reference
    /**
     * Abstract base class for reference objects.  This class defines the
     * operations common to all reference objects.  Because reference objects are
     * implemented in close cooperation with the garbage collector, this class may
     * not be subclassed directly.
     *
     * @author Mark Reinhold
     * @since 1.2
     */
    public abstract class Reference<T> {}
    

    从注释和类图中可以清楚的看到:

    • Reference类是直接配合GC操作的,所以不能直接子类化,但是可以继承Reference的子类;
    • Reference类定义了子类的主要逻辑,所以在SoftReferenceWeakReferencePhantomReference中几乎完全复用了Reference的逻辑;

    二、Reference 框架结构

    reference

    如图所示,Reference 的处理流程相当于事件处理

    1. 如果 new Reference 的时候如果没有传入 ReferenceQueue,相当于使用 JVM 的默认处理流程,达到一定条件的时候由GC回收;
    2. 如果 new Reference 的时候传入了 ReferenceQueue,相当于使用自定义的事件处理流程,此时的 ReferenceQueue 相当于事件监听器Reference 则相当于每个事件,GC 标记的时候添加 discovered链表 相当于事件发现过程,pending和enqueued则相当于注册事件的过程,最后需要用户自定义事件处理逻辑

    在 Reference 的生命周期里面,一共有四个状态:

    • Active:每个引用的创建之初都是活动状态,直到下次 GC 的时候引用的强弱关系发生变化,同时不同的引用根据不同的策略改变状态;
    • Pending:正准备加入引用链表;
    • Enqueued:已经加入引用链表,相当于已经注册成功等待处理;
    • Inactive:所有的引用对象的终点,可回收状态;

    三、可达性分析

    上面我们提到当引用强弱关系发生变化的时候,他的状态会发生改变,那么这个强弱关系是如何判断的呢?
    熟悉 JVM 的同学应该知道判断对象是否存活的算法大致有两种;

    1. 引用计数法,即每当有一个对象引用他的时候就加1,引用失效时减1,当任何时候计数都为0时,就代表对象可以被回收了;
    2. 可达性分析法,即从一组 GC Roots 对象出发,引用可达即代表存活,引用不可达就代表是可回收对象;如图所示:
    可达性分析法1

    上图仅表示了,强引用的回收,当加入了软引用,弱引用和虚应用之后:

    可达性分析法2
    • 单路径中,以最弱的引用为准
    • 多路径中,以最强的引用为准

    已上图为例:

    • 对于 Obj 1:单路径可达,所以 GC Roots 到 Obj 1为弱引用;
    • 对于 Obj 5:多路径可达,所以 GC Roots 到 Obj 5为软引用;

    四、成员变量和构造函数

    private T referent; /* Treated specially by GC */
    volatile ReferenceQueue<? super T> queue;
    volatile Reference next;
    transient private Reference<T> discovered; /* used by VM */
    private static Reference<Object> pending = null;
    
    Reference(T referent) {
      this(referent, null);
    }
    
    Reference(T referent, ReferenceQueue<? super T> queue) {
      this.referent = referent;
      this.queue = (queue == null) ? ReferenceQueue.NULL : queue;
    }
    
    • referent:引用指向的对象,即需要Reference包装的对象;
    • queue:虽然ReferenceQueue的名字里面有队列,但是它的内部却没有包含任何队列和链表的结构;他的内部封装了单向链表的添加,删除和遍历等操作,实际作用相当于事件监听器;
    • next:引用单向链表;
    • discovered:discovered单向链表,由 JVM 维护;在 GC 标记的时候,当引用强弱关系达到一定条件时,由 JVM 添加;需要注意的是这个字段是 transient 修饰的,但是 Reference 类声明的时候却没有实现 Serializable 接口,这是因为 Reference 子类的子类可能实现 Serializable 接口,另外一般情况下也不建议实现 Serializable 接口;
    • pending:表示正在排队等待入队的引用;

    五、重要函数

    1. 初始化

    static {
      ThreadGroup tg = Thread.currentThread().getThreadGroup();
      for (ThreadGroup tgn = tg;
        tgn != null;
        tg = tgn, tgn = tg.getParent());
      Thread handler = new ReferenceHandler(tg, "Reference Handler");
      /* If there were a special system-only priority greater than
       * MAX_PRIORITY, it would be used here
       */
      handler.setPriority(Thread.MAX_PRIORITY);
      handler.setDaemon(true);
      handler.start();
    
      // provide access in SharedSecrets
      SharedSecrets.setJavaLangRefAccess(new JavaLangRefAccess() {
        @Override
        public boolean tryHandlePendingReference() {
          return tryHandlePending(false);
        }
      });
    }
    

    可以看到在初始化的时候首先得到了层级最高的线程组即 System线程组,然后在里面加入了一个名为 “Reference Handler” 的 优先级最高 的 ReferenceHandler 线程;
    接下来的一段代码是用于保证 JVM 在抛出 OOM 之前,原子性的清除非强引用的所有引用,如果空间仍然不足才会抛出 OOM;其中 SharedSecrets用于访问类的私有变量,于反射不同的是,它不会创建新的对象;比如:

    package java.nio;
    // Class Bits
    static void reserveMemory(long size, int cap) {
      ...
      // optimist!
      if (tryReserveMemory(size, cap)) {
        return;
      }
      
      // 走到这里就说明空间已经不足了
      final JavaLangRefAccess jlra = SharedSecrets.getJavaLangRefAccess();
      
      // retry while helping enqueue pending Reference objects
      // which includes executing pending Cleaner(s) which includes
      // Cleaner(s) that free direct buffer memory
      while (jlra.tryHandlePendingReference()) {
       if (tryReserveMemory(size, cap)) {
         return;
       }
      }
      ...
    }
    

    有关 “Reference Handler” 的线程信息可以使用jstack [] <pid>抓取栈信息查看:

    "Reference Handler" #2 daemon prio=10 os_prio=0 tid=0x00007fa1ac154170 nid=0x32a7 in Object.wait() [0x00007fa19661f000]
       java.lang.Thread.State: WAITING (on object monitor)
    	at java.lang.Object.wait(Native Method)
    	at java.lang.Object.wait(Object.java:502)
    	at java.lang.ref.Reference.tryHandlePending(Reference.java:191)
    	- locked <0x00000006c7e79bc0> (a java.lang.ref.Reference$Lock)
    	at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:153)
    

    2. ReferenceHandler 线程

    private static class ReferenceHandler extends Thread {
      private static void ensureClassInitialized(Class<?> clazz) {
        try {
          Class.forName(clazz.getName(), true, clazz.getClassLoader());
        } catch (ClassNotFoundException e) {
          throw (Error) new NoClassDefFoundError(e.getMessage()).initCause(e);
        }
      }
    
      static {
        // pre-load and initialize InterruptedException and Cleaner classes
        // so that we don't get into trouble later in the run loop if there's
        // memory shortage while loading/initializing them lazily.
        ensureClassInitialized(InterruptedException.class);
        ensureClassInitialized(Cleaner.class);
      }
    
      ReferenceHandler(ThreadGroup g, String name) {
        super(g, name);
      }
    
      public void run() {
        while (true) {
          tryHandlePending(true);
        }
      }
    }
    

    可以看到这个线程只做了一件很简单的事情:

    • 首先确保InterruptedExceptionCleaner已经加载,关于Cleaner就是一个虚引用的实际应用,后面还会详细讲到;
    • 然后死循环执行tryHandlePending

    3. tryHandlePending 核心方法

    /**
     * Try handle pending {@link Reference} if there is one.<p>
     * Return {@code true} as a hint that there might be another
     * {@link Reference} pending or {@code false} when there are no more pending
     * {@link Reference}s at the moment and the program can do some other
     * useful work instead of looping.
     *
     * @param waitForNotify if {@code true} and there was no pending
     *                      {@link Reference}, wait until notified from VM
     *                      or interrupted; if {@code false}, return immediately
     *                      when there is no pending {@link Reference}.
     * @return {@code true} if there was a {@link Reference} pending and it
     *         was processed, or we waited for notification and either got it
     *         or thread was interrupted before being notified;
     *         {@code false} otherwise.
     */
    static boolean tryHandlePending(boolean waitForNotify) {
      Reference<Object> r;
      Cleaner c;
      try {
        synchronized (lock) {
          if (pending != null) {
            r = pending;
            // 'instanceof' might throw OutOfMemoryError sometimes
            // so do this before un-linking 'r' from the 'pending' chain...
            c = r instanceof Cleaner ? (Cleaner) r : null;
            // unlink 'r' from 'pending' chain
            pending = r.discovered;
            r.discovered = null;
          } else {
            // The waiting on the lock may cause an OutOfMemoryError
            // because it may try to allocate exception objects.
            if (waitForNotify) {
              lock.wait();
            }
            // retry if waited
            return waitForNotify;
          }
        }
      } catch (OutOfMemoryError x) {
        // Give other threads CPU time so they hopefully drop some live references
        // and GC reclaims some space.
        // Also prevent CPU intensive spinning in case 'r instanceof Cleaner' above
        // persistently throws OOME for some time...
        Thread.yield();
        // retry
        return true;
      } catch (InterruptedException x) {
        // retry
        return true;
      }
    
      // Fast path for cleaners
      if (c != null) {
        c.clean();
        return true;
      }
    
      ReferenceQueue<? super Object> q = r.queue;
      if (q != ReferenceQueue.NULL) q.enqueue(r);
      return true;
    }
    

    这个方法主要完成了discovered -> pending -> enqueued的整个入队注册流程;值得注意的是虽然Cleaner是虚引用,但是它并不会入队,而是直接执行clean操作,也就意味着在使用Cleaner的时候不需要在起一个线程监听ReferenceQueue了;

    4. ReferenceQueue 概览

    static ReferenceQueue<Object> NULL = new Null<>();
    
    // 用于标记是否已经入队,防止重复入队
    static ReferenceQueue<Object> ENQUEUED = new Null<>();
    private volatile Reference<? extends T> head = null;
    private long queueLength = 0;
    
    // reference入队操作
    boolean enqueue(Reference<? extends T> r) { /* Called only by Reference class */
    
    // poll 移除reference链表头元素
    public Reference<? extends T> poll() { }
    
    // 移除reference链表下一个元素
    public Reference<? extends T> remove(long timeout) { }
    public Reference<? extends T> remove() throws InterruptedException { }
    void forEach(Consumer<? super Reference<? extends T>> action) { }
    

    从上面的代码也可以看出ReferenceQueue 的确没有包含任何链表或者队列的结构,但是封装了单向的链表的操作;

    总结

    • Reference 主要用于更加灵活的控制对象的生死,其实现类似于事件处理,可以是 JVM 默认处理,也可以是用户自定义的处理逻辑;
    • 在 Java 语言中 Reference 类定义了子类(SoftReference,WeakReference,PhantomReference)的主要逻辑,但是判断引用回收的条件主要在 JVM 中定义(主要发生在 GC 标记阶段),如果你有兴趣可以到 OpenJDK 里面继续深入研究;
    • 如果在使用 Reference 的时候传入了 ReferenceQueue,即使用自定义的逻辑处理,那么最后一定要把 ReferenceQueue 中注册的 Reference 移除,因为此时 GC 不会回收 ReferenceQueue 中的链表;
    • Reference Handler 线程只有一个,但是 Reference 链表却有很多条(所以在注册的时候需要加锁),另外每个 Class 对象都能同时生成多个引用对象,并注册 ReferenceQueue ;
  • 相关阅读:
    今天我正式走出公司...
    PHP图片处理函数
    PHP缓存知识-转载
    Nginx 服务器伪静态配置实例
    PHP防止跨站攻击的脚本
    <
    <
    <- OPENGL 10 NormalMAP ->
    <-OPENGL 9-> 阴影篇
    - OPENGL8
  • 原文地址:https://www.cnblogs.com/sanzao/p/10337291.html
Copyright © 2011-2022 走看看