编程语言
首页 > 编程语言> > JDK源码分析(7)之 Reference 框架概览

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 框架结构

reference

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

  1. 如果 new Reference 的时候如果没有传入 ReferenceQueue,相当于使用 JVM 的默认处理流程,达到一定条件的时候由GC回收;

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

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

三、可达性分析

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

  1. 引用计数法,即每当有一个对象引用他的时候就加1,引用失效时减1,当任何时候计数都为0时,就代表对象可以被回收了;

  2. 可达性分析法,即从一组 GC Roots 对象出发,引用可达即代表存活,引用不可达就代表是可回收对象;如图所示:

可达性分析法1

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

可达性分析法2

已上图为例:

四、成员变量和构造函数

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;
}

五、重要函数

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 Bitsstatic 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);
    }
  }
}

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

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,JDK,链表,源码,GC,ReferenceQueue,pending,引用
来源: https://blog.51cto.com/14028890/2389807