Java引用详解

1 Java中的四种引用

在Java中提供了四个级别的引用:强引用,软引用,弱引用和虚引用。在这四个引用类型中,只有强引用FinalReference类是包内可见,其他三种引用类型均为public,可以在应用程序中直接使用。引用类型的类结构如图所示。

1.1 强引用

Java中的强引用指的是,程序中有直接可达的引用。如

    Object obj = new Object();

强引用的特点:

  1. 强引用可以直接访问目标对象。
  2. 强引用所指向的对象在任何时候都不会被系统回收。JVM宁愿抛出OOM异常,也不会回收强引用所指向的对象。
  3. 强引用可能导致内存泄漏。

1.2 软引用

软引用是除了强引用外,最强的引用类型。可以通过java.lang.ref.SoftReference使用软引用。

SoftReference<Object> softRef = new SoftReference<Object>(new Object());

软引用的特点:

1.软引用的对象,只有在内存不足的时候(抛出OOM异常前),垃圾收集器会决定回收该软引用所指向的对象。软引用通常用于实现内存敏感的缓存。

2.在垃圾线程对 这个Java对象回收前,SoftReference类所提供的get()方法返回Java对象的强引用。一旦垃圾线程回收该Java对象之后,get()方法将返回null。

1.3 弱引用

弱引用是一种比软引用较弱的引用类型。可以用java.lang.ref.WeakReference实例来保存对一个Java对象的弱引用。

WeakReference<Object> weakRef = new WeakReference<Object>(new Object());

软引用的特点:

1.不管内存是否足够,只要被垃圾收集器发现,该引用的对象就会被回收

1.4 虚引用

虚引用是所有类型中最弱的一个。一个持有虚引用的对象,和没有引用几乎是一样的,可以用java.lang.ref.WeakReference实例来保存对一个Java对象的弱引用。

Object obj = new Object();
ReferenceQueue<Object> refQueue = new ReferenceQueue<>();
PhantomReference<Object> phantom = new PhantomReference<Object>(obj, refQueue);

虚引用的特点:

1.随时可能被垃圾回收器回收。

2.当试图通过虚引用的get()方法取得强引用时,总是返回null。

3.虚引用必须和引用队列一起使用。

当垃圾回收器准备回收一个对象时,如果发现它还有虚引用,就会在垃圾回收后,销毁这个对象,将这个虚引用加入引用队列。程序可以通过判断引用队列中是否已经加入了虚引用,来了解被引用的对象是否将要被垃圾回收。如果程序发现某个虚引用已经被加入到引用队列,那么就可以在所引用的对象的内存被回收之前采取必要的行动。

2 ReferenceQueue

引用队列,当检测到对象的可到达性更改时,垃圾回收器将已注册的引用对象添加到队列中,ReferenceQueue实现了入队(enqueue)和出队(poll),还有remove操作,内部元素head就是泛型的Reference。

//创建一个引用队列  
ReferenceQueue queue = new ReferenceQueue();  

// 创建弱引用,此时状态为Active,并且Reference.pending为空,当前Reference.queue = 上面创建的queue,并且next=null  
WeakReference reference = new WeakReference(new Object(), queue);  
System.out.println(reference);  
// 当GC执行后,由于是弱引用,所以回收该object对象,并且置于pending上,此时reference的状态为PENDING  
System.gc();  

/* ReferenceHandler从pending中取下该元素,并且将该元素放入到queue中,此时Reference状态为ENQUEUED,Reference.queue = ReferenceENQUEUED */  

/* 当从queue里面取出该元素,则变为INACTIVE,Reference.queue = Reference.NULL */  
Reference reference1 = queue.remove();  
System.out.println(reference1);

3 源码分析

3.1Reference定义的4种状态

Reference类首先把内存分为4种状态Active,Pending,Enqueued,Inactive。

  • Active,一般来说内存一开始被分配的状态都是 Active,
  • Pending 大概是指快要被放进队列的对象,也就是马上要回收的对象,
  • Enqueued 就是对象的内存已经被回收了,我们已经把这个对象放入到一个队列中,方便以后我们查询某个对象是否被回收,
  • Inactive就是最终的状态,不能再变为其它状态。

3.2 Reference成员变量

// 用于保存对象的引用,GC会根据不同Reference来特别对待
private T referent;
// 如果需要通知机制,则保存的对对应的队列
ReferenceQueue<? super T> queue;
/* 这个用于实现一个单向循环链表,用以将保存需要由ReferenceHandler处理的引用 */
Reference next;

static private class Lock { };
// 锁,用于同步pending队列的进队和出队
private static Lock lock = new Lock();

transient private Reference<T> discovered;  /* used by VM */  

// 此属性保存一个PENDING的队列,配合上述next一起使用
private static Reference pending = null;
  • referent表示其引用的对象,即在构造的时候需要被包装在其中的对象。
  • queue 是对象即将被回收时所要通知的队列。当对象即将被回收时,整个reference对象,而不仅仅是被回收的对象,会被放到queue 里面,然后外部程序即可通过监控这个 queue 即可拿到相应的数据了。
  • next 即当前引用节点所存储的下一个即将被处理的节点。但 next 仅在放到queue中才会有意义,因为只有在enqueue的时候,会将next设置为下一个要处理的Reference对象。为了描述相应的状态值,在放到队列当中后,其queue就不会再引用这个队列了。而是引用一个特殊的 ENQUEUED(内部定义的一个空队列)。因为已经放到队列当中,并且不会再次放到队列当中。
  • discovered 表示要处理的对象的下一个对象。即可以理解要处理的对象也是一个链表,通过discovered进行排队,这边只需要不停地拿到pending,然后再通过discovered 不断地拿到下一个对象赋值给pending即可,直到取到了最有一个。它是被JVM 使用的。
  • pending 是等待被入队的引用列表。JVM 收集器会添加引用到这个列表,直到Reference-handler线程移除了它们。这个列表使用 discovered 字段来连接它下一个元素(即 pending 的下一个元素就是discovered对象。r = pending; pending = r.discovered)。

3.3 ReferenceQueue成员变量

// 用于标识没有注册Queue
static ReferenceQueue NULL = new Null();
// 用于标识已经处于对应的Queue中
static ReferenceQueue ENQUEUED = new Null();

static private class Lock { };
/* 互斥锁,用于同步ReferenceHandler的enqueue和用户线程操作的remove和poll出队操作 */
private Lock lock = new Lock();
// 队列
private volatile Reference<? extends T> head = null;
// 队列中的元素个数
private long queueLength = 0;

3.4 对象的入队过程

当 Reference 类被加载的时候,会执行静态代码块。在静态代码块里面,会启动 ReferenceHandler 线程,并设置线程的级别为最大级别, Thread.MAX_PRIORITY。

检查 pending 是否为 null,如果pending不为 null,则将 pending 进行 enqueue,否则线程进入 wait 状态。

private static class ReferenceHandler extends Thread {
   ----- // 核心代码如下
    public void run() {
        while (true) {
            tryHandlePending(true);
        }
    }
static boolean tryHandlePending(boolean waitForNotify) {
    Reference<Object> r;
    Cleaner c;
    try {
        synchronized (lock) {
            // 检查 pending 是否为 null,不为 null,制定 pending enqueue
            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 { // 为 null。等待
                // 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;
  }
}

/******************************ReferenceQueue*************************/

boolean enqueue(Reference<? extends T> r) { /* Called only by Reference class */
    synchronized (lock) {
        // Check that since getting the lock this reference hasn't already been
        // enqueued (and even then removed)
        ReferenceQueue<?> queue = r.queue;
        // queue 为 null 或者 queue 已经被回收了,直接返回
        if ((queue == NULL) || (queue == ENQUEUED)) {
            return false;
        }
        assert queue == this;
        // 将 Reference 的状态置为 Enqueued,表示已经被回收
        r.queue = ENQUEUED;
        // 接着,将 Reference 插入到链表
        // 判断当前链表是否为 null,不为 null,将 r.next 指向 head,为 null,head 直接指向 r
        r.next = (head == null) ? r : head;
        // head 指针指向 r
        head = r;
        queueLength++;
        if (r instanceof FinalReference) {
            sun.misc.VM.addFinalRefCount(1);
        }
        lock.notifyAll();
        return true;
    }
}

注意:

  1. JVM在GC时会把回收了内存的对象的'Reference'通过'discovered'连接成链表。

  2. ‘pending’属性相对于'discovered'链表上面的指针,每次把当前的元素放入引用队列,然后指向链表的下一个元素。

  3. 'Reference'的'next'属于用于指向一个已经在队列中被回收的对象。

4 Object的finalize()方法原理

4.1 finalize()方法简介

  • 如果一个类实现了finalize方法,那么GC在回收这个对象之前,会将finalize方法进行调用。finalize的一般约定是,jvm虚拟机已经确定没有任何引用或者线程访问此对象,就会调用这个finalize方法。在finalize方法中可以进行任何操作,包括该对象再次对其他线程进行调用。这个方法的目的是在gc回收对象之前,再次对之前未关闭的资源进行回收。如IO操作中的连接等。
  • java虚拟机并不保证哪个线程会具体调用finalize方法,但是可以保证调用finalize方法的时候不会有任何用户可见的同步锁。如果finalize方法中出现任何异常,则这些异常会被忽略,且finalize方法会终止。
  • 在一个对象调用finalize方法之后,在jvm确认这个对象没有任何其他对象能访问之前,也就是说jvm确认这个对象不是垃圾之前。finalize方法不会执行。
  • finalize 方法只会被虚拟机执行一次。
  • finalize方法中的异常会被忽略,之后finalize方法会终止。

4.2 FinalReference

FinalReference的实现非常简单,这个类不是public的,其作用域在protected,也就是说除了java.lang.ref包中的类能访问之外,不能在任何自定义的代码中调用。这也说明这是一个jvm才能访问的类。

class FinalReference<T> extends Reference<T> {

    public FinalReference(T referent, ReferenceQueue<? super T> q) {
        super(referent, q);
    }
}

4.3 Finalizer

Finalizer是finalReference的子类,对queue和lock进行了重写。Finalizer也是protected作用域,另外通过final修饰。不可被继承。

//final修饰的类不可被继承
final class Finalizer extends FinalReference<Object> { 

   //重写了queue属性,Finalizer必须使用ReferenceQueue,因此一开始就对queue进行了实例化
    private static ReferenceQueue<Object> queue = new ReferenceQueue<>();
    private static Finalizer unfinalized = null;
    //重载了锁
    private static final Object lock = new Object();

    //链表指针,Finalizer是个双向链表
    private Finalizer
        next = null,
        prev = null;
}

4.4 FinalizerThread

jvm在注册的时候,实际上就是创建了一个Finalizer的链表。在GC的时候,如果发现对象只被Finalizer引用,则说明这个对象可以被回收了。那么就将其从引用对象链中取出,放入ReferenceQueue中。之后通知Finalizer Thread线程去消费。之后去调用finalize方法。


private static class FinalizerThread extends Thread {
        private volatile boolean running;
        FinalizerThread(ThreadGroup g) {
            super(g, "Finalizer");
        }
        public void run() {
            if (running)
                return;

            // Finalizer thread starts before System.initializeSystemClass
            // is called.  Wait until JavaLangAccess is available
            while (!VM.isBooted()) {
                // delay until VM completes initialization
                try {
                    VM.awaitBooted();
                } catch (InterruptedException x) {
                    // ignore and continue
                }
            }
            final JavaLangAccess jla = SharedSecrets.getJavaLangAccess();
            running = true;
            for (;;) {
                try {
                    Finalizer f = (Finalizer)queue.remove();
                    f.runFinalizer(jla);
                } catch (InterruptedException x) {
                    // ignore and continue
                }
            }
        }
    }
/*********************************Finalizer****************************/

private void runFinalizer(JavaLangAccess jla) {
        synchronized (this) {
            if (hasBeenFinalized()) return;
            remove();
        }
        try {
            Object finalizee = this.get();
            if (finalizee != null && !(finalizee instanceof java.lang.Enum)) {
                jla.invokeFinalize(finalizee);

                /* Clear stack slot containing this variable, to decrease
                   the chances of false retention with a conservative GC */
                finalizee = null;
            }
        } catch (Throwable x) { }
        super.clear();
    }

流程:

  • 在创建对象的时候,如果重写了finalize方法,jvm就会同时创建一个Finalizer对象。
  • 所有的Finalizer对象构成一个双向链表
  • 所有的Finalizer对象都有一个名为queue的ReferenceQueue队列
  • GC在执行标记的最后阶段,会把Finalizer的对象加入到Reference的pending-list 链表中。
  • ReferenceHandler会将pending-list中的对象取出,放置到这个ReferenceQueue中。对于finalReference而言,这个queue即使初始化的时候创建的static的queue。对于所有的FinalReference全局只有一个ReferenceQueue。
  • Finalizer中有一个专门的守护线程 Finalizer Thread,这个线程中有一个死循环,专门从queue中取出对象,并执行Finalizer中引用对象的finalize方法。之后从队列中移除,强引用消除。
  • 再次GC 这个Finalizer的对象没有任何引用,因此可能被回收掉。

java虚引用的使用说明 - followus - 博客园

Java Reference 源码分析 - Jabnih - 博客园

java 源码系列 - 带你读懂 Reference 和 ReferenceQueue_gdutxiaoxu的博客(微信公众号 stormjun94)-CSDN博客

java中的reference(三): FinalReference和Finalizer的源码分析_dhaibo1986的专栏-CSDN博客

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 219,539评论 6 508
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 93,594评论 3 396
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 165,871评论 0 356
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 58,963评论 1 295
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 67,984评论 6 393
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 51,763评论 1 307
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 40,468评论 3 420
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 39,357评论 0 276
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 45,850评论 1 317
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 38,002评论 3 338
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 40,144评论 1 351
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 35,823评论 5 346
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 41,483评论 3 331
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 32,026评论 0 22
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 33,150评论 1 272
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 48,415评论 3 373
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 45,092评论 2 355

推荐阅读更多精彩内容

  • 在堆里存放着几乎多有的java对象实例,垃圾搜集器在对堆进行回收之前,第一件事情就是确定这些对象之中哪些还“存活”...
    fishlovecat阅读 97评论 0 0
  • 在堆里存放着几乎多有的java对象实例,垃圾搜集器在对堆进行回收之前,第一件事情就是确定这些对象之中哪些还“存活”...
    kylinxiang阅读 27,894评论 2 15
  • 概述 Java的引用分为StrongReference、SoftReference、WeakReference、P...
    allanYan阅读 365评论 0 0
  • 1、引用级别 在JVM中,垃圾回收器一直在背后默默地承担着内存回收的工作,我们不需要像使用C语音开发那样小心翼翼地...
    冰河winner阅读 997评论 0 1
  • 大家都知道java里面引用有SoftReference、WeakReference、PhantomReferenc...
    Java天天阅读 463评论 0 0