做图网站有哪些东西吗,罗源城乡建设网站,哪个网站上做自媒体最好,wordpress qux主题一 概述 简介 在JDK1.2之前#xff0c;Java中引用的定义是十分传统的#xff1a;如果引用类型的变量中存储的数值代表的是另一块内存的起始地址#xff0c;就称这块内存代表着一个引用。在这种定义之下#xff0c;一个对象只有被引用和没有被引用两种状态。 实际上#xf…一 概述 简介 在JDK1.2之前Java中引用的定义是十分传统的如果引用类型的变量中存储的数值代表的是另一块内存的起始地址就称这块内存代表着一个引用。在这种定义之下一个对象只有被引用和没有被引用两种状态。 实际上我们还希望存在这样的一类对象当内存空间还足够的时候这些对象能够保留在内存空间中如果当内存空间在进行了垃圾收集之后还是非常紧张则可以抛弃这些对象。基于这种特性可以满足很多系统缓存功能的使用场景。 从JDK1.2起Java对引用概念进行了扩充将引用分为强引用Strong Reference、软引用Soft Reference、弱引用Weak Reference、虚引用Phantom Reference及终引用Final Reference。其中强引用就是JDK1.2之前的引用日常代码中绝大多数引用都是强引用。而其它几种引用则是JDK1.2中引入的这些引用有着各自的特性及作用例如软引用就代表了上述需求的“将对象在内存空闲时保留不足时舍弃”的功能。这些引用概念存在着相应的类实现Java通过Java类与底层机制相结合的方式实现了这些概念而重点是这些类又全都继承自同一个父类也是本文真正的核心 —— Referecne引用抽象类下文简称引用。 引用抽象类是强引用之外引用下文简称特殊引用概念的实质化产物其作用在于定义并实现了特殊引用的生命周期及运行流程使得特殊引用不再是一个虚幻的设想而是实际独立于强/无引用之外的第三存在为软、弱等具体特殊引用实现提供了实质性基础该知识点会在下文详述。 特殊引用实现思想 事实上作为API层面上的实现单纯依靠引用抽象类是无法实现特殊引用的需要JVM层面GC的配合。因此与其说引用抽象类实现了特殊引用倒不如说其为GC分辨特殊引用提供了判断依据更加合适具体如下图所示 由上图可知通过在对象的强引用关系之间插入引用的方式GC可以判断得出对象A/B之间存在特殊引用关系由此就可以避开强引用的执行逻辑转而进行对特殊引用对象的特殊处理从而实现不同于强引用的奇妙回收效果例如“在剩余内存充裕时保留紧张时回收”及“对象实际可达但依然被回收”等。
二 使用 初始化 引用抽象类由于是抽象类因此构造方法自然是无法直接执行的只能在子类的构造方法中调用。 Reference(T referent) —— 初始化指定所指对象但未注册ReferenceQueue引用队列类对象下文简称引用队列的引用。 Reference(T referent, ReferenceQueue? super T queue) —— 初始化指定所指对象且注册引用队列的引用。 方法 public T get() —— 获取 —— 获取当前引用的所指对象当所指对象不存在时返回null。所指对象初始是必然存在的但可以在后期被清除。 public void clear() —— 清除 —— 清除当前引用的所指对象即断开两者的引用关系并不会将当前引用加入到注册引用队列中。该方法专为开发者提供GC线程不会调用该方法断开引用与所指对象的关联。 public boolean isEnqueued() —— 是否入队 —— 判断当前引用是否已加入注册引用队列是则返回true否则返回false。引用加入注册引用队列时会将注册引用队列替换为“入队”引用队列这是一个在引用队列类内部创建的全局静态引用队列被作为引用加入注册引用队列的标志位来使用。因此判断当前引用是否加入注册引用队列无需遍历注册引用队列直接判断注册引用队列是否是“入队”引用队列即可。 public boolean enqueue() —— 入队 —— 将当前引用加入注册引用队列中成功返回true否则返回false。该方法底层调用引用队列类的enqueue(Reference? extends T r) 方法实现。该方法专为开发者提供“引用处理器”线程不会调用该方法将当前引用加入注册引用队列。
三 实现 所指对象 所谓的所指对象即是被引用所持有的对象每个引用在创建时必须且只能持有一个对象这个对象将因为引用的原因被GC认为存在特殊引用从而受到特殊处理。根据引用类型的不同软、弱及虚等其收到的特殊处理也不尽相同。 引用队列 引用在创建时可以设置/注册引用队列当引用的所指对象被GC回收时引用会被安排加入注册引用队列中。因此可知注册引用队列的实际作用是追踪所指对象的GC状态通过判断引用是否处于注册引用队列中的方式开发者可以知道其所指对象是否已被GC回收并以此为契机来执行某些自定义操作例如回收资源等。 当然引用队列的注册并非是强制的引用抽象类提供了构造方法Reference(T referent)来创建不注册引用队列的引用。此时引用中用于持有注册引用队列的queue队列字段会被默认赋值为“空”引用队列。“空”引用队列与“入队”引用队列一样是在引用队列类内部创建的全局静态引用队列被作为“引用未注册引用队列”及“引用退出注册引用队列”的标志位来使用两种状态的具体区分还需要搭配其它字段该知识点会在下文详述。 如果引用未注册引用队列则其自然就无法被加入到注册引用队列中自然而然也就无法通过该方式来判断其所指对象是否被GC回收。但话虽如此开发者依然可以通过调用get()方法的方式来进行判断。如果引用抽象类的子类没有重写该方法或在重写时没有添加额外的限制则可以通过判断get()方法返回值是否为null的方式来判断所指对象是否被GC回收。事实上由于将引用加入注册引用队列需要一定的程序与步骤因此使用get()方法进行判断通常具有更高的实时性。 待定列表 待定列表是全局唯一的引用列表以全局静态变量的方式保存在引用抽象类中即用于持有待定列表引用的pending待定字段是一个静态变量。实际上待定列表是逻辑列表并非真正的列表即pending待定字段持有的实际是其头节点而非类似于ArrayList数组列表类对象的对象。由于引用抽象类在设计上兼容了节点即组合了用于持有后继引用的discovered发现字段当引用为尾节点时该字段值为自身即自引用因此可以通过遍历的方式来访问整个列表从而只要持有了头节点就相当于持有了整个列表。如此设计的原因是因为待定列表本质上被作为堆栈来使用节点/引用的插入/移除都会在列表的头部执行头插法/头移法因此并没有遍历整个列表的需求故而无需使用功能如此完善的封装类。并且因为相同的原因我们可以知道引用在待定列表中的移除是非公平的即晚插入的引用反而会被先移除。 待定列表被作为引用加入其注册引用队列之前的临时存放点。我们已知的是如果引用在创建时注册了引用队列则当其所指对象被GC回收时其会被安排加入注册引用队列中该任务会由“引用处理器”线程来执行。“引用处理器”类是引用抽象类自定义的静态内部类同时也是Thread线程类的子类被专门设计用来作为执行“将引用加入引入队列”的任务。“引用处理器”线程在引用抽象类的静态块中创建整个系统中仅有一条是优先级为10最高的守护线程这令其能够获得更多的CPU资源来执行任务。但所指对象的回收显然是由GC线程负责的两者的执行速率未必一致如此当“引用处理器”线程无法及时将每个相关引用加入注册引用队列时将会造成GC线程等待或者其它问题该知识点会在下文详述。为了避免这一点自然就需要一块空间来暂存相关引用以充当两者间的缓冲区域待定列表起的就是这个作用。
四 Reference引用机制 所谓的Reference引用机制指的是从引用断开与其所指对象的连接到将引用从注册引用队列移除的完整执行流程是在引用抽象类中的静态块中实现的。在这个流程中有着GC线程、API线程及用户线程的三方参与引用在不同阶段会处于不同的状态具体的流程及讲解如下所示 首先引用初始会被统一保存在发现列表中。发现列表是一个由GC维护的引用列表关于其的资料很少源码中仅有几句描述是属于JVM层面而非API层面的列表目前唯一确定的是发现列表会保存所有引用个人猜测这应该是GC为了快速检索及操作引用而采用的设计。引用位于发现列表中时处于活跃状态由于活跃状态是引用的初始状态并且初始状态下引用必然持有发现列表中的后继引用发现列表与待定列表都使用discovered发现字段来持有后继引用但区别是如果引用为尾节点则为null因此可知引用再被创建时就被加入发现列表。 发现列表中的引用会收到GC的特殊处理或者说活跃状态的引用会收到GC的特殊处理。所谓的特殊处理是指当引用的所指对象被GC判断为可回收时判断条件会根据具体的引用抽象类子类的类型而有所差异GC并不会像强引用一样直接将之回收而是会先断开其与引用的连接不通过引用的clear()方法实现后再回收并安排引用加入到注册引用队列中。GC线程首先会判断引用是否注册了引用队列即判断queue队列字段持有的是否是“空”引用队列。如果是说明未注册引用队列直接将之从发现列表中移除此时引用将直接变为最终的怠惰状态意味着其已经完成了整个流程否则意味着引用注册了引用队列在将之从发现列表移除之后还需要以头插法的方式将之加入到待定列表中并转变为待定状态等待被“引用处理器”线程移除并加入注册引用队列中。因此可以知道的是待定队列中保存的引用都是注册了引用队列的。之前我们说过待定列表的存在是为了避免“引用处理器”线程无法及时将每个相关引用加入注册引用队列而造成的GC线程等待问题事实上也可能是长遍历问题即GC线程不等待“引用处理器”线程取走当前与所指对象断开连接的引用而直接向后遍历等重遍历时在再由空闲的“引用处理器”线程将断连引用取走。但这么做必然会使得断连引用在发现列表中保留从而在GC重遍历发现列表时需要遍历更长的长度并且该方法也无法保证重遍历时“引用处理器”线程是空闲的。 “引用处理器”线程会从待定列表的头部取出引用并将之加入注册引用队列中。关于“引用处理器”线程上文已经详述过此处就不再提及了。“引用处理器”线程所属的引用处理器类重写了run()方法会以死循环的方式不断地从待定列表的头部取出引用并加入注册引用队列中。当待定列表中没有引用时“引用处理器”线程会无限等待直至待定列表存在引用后被GC线程唤醒。可以发现的是待定列表虽然名为列表但实际是作为堆栈来使用的节点/引用的插入/移除都会在头部发生这一点在上文也有所提及。如此一来造成的结果就是此处会存在线程安全问题因为节点/引用的插入/移除分别由不同的线程执行为此引用抽象类在此使用了类锁即使用synchronized关键字并搭配静态变量的方式来保证线程安全。引用被从待定列表中移除后理论上会直接加入注册引用队列中但实际上此处还存在一个特殊判断即判断引用是否是Cleaner清洁工类型引用抽象类的孙类。如果不是则按正常流程将引用以头插法队列…头插法…加入注册引用队列中并将引用转变为入队状态而如果是则该引用不会被加入注册引用队列而是会在调用clean()方法来自于Cleaner清洁工类执行内部自定义操作后直接结束流程。该特殊操作是Reference引用机制的对外衍生目的是取代不可靠的Finalization终结机制但实际上两者的效果大同小异具体内容会在Cleaner清洁工类/Finalizer终结者类中详述。 引用加入注册引用队列中后其注册引用队列将变为“入队”引用队列以作为判断引用已入队的标志位。需要注意的是引用使用next下个字段来持有注册引用队列的后继引用如果引用为尾节点则自引用这与发现/待定列表是不同的。为何如此设计的原因暂且未知单单从API层面似乎看不出什么问题我想可能与JVM层面的实现有关。我一开始猜测是不是因为引用可以同时存在于待定列表及发现队列中后来发现并不能共存…后来我又猜测是因为next下个字段与queue队列字段组合共同表示引用状态的缘故但转念一想如果继续使用discovered发现字段来持有注册引用队列的后继引用则next下个字段完全可以替换为state状态字段来记录状态这不仅不会增多字段的总数并且状态的记录也比目前更加方便直观因此我又否定了这个猜想。如果有知道具体原因的童鞋还望不吝赐教鄙人不胜感激 加入注册引用队列的引用可作为其所指对象已被GC回收的判断依据开发者可以此为契机执行某些自定义操作。这似乎是非常理所当然的事情因为安排引用加入注册引用队列是所指对象被GC判定为可回收之后才会触发的行为。但如此就能判定所指对象一定已被GC回收吗个人认为是否定的。因为Reference引用机制中的GC线程所做的仅仅是断开所指对象与引用的连接真正的回收会由其它GC线程完成…那也就是说“引用加入注册引用队列”与“所指对象被具体回收”这两者实质上是异步行为没有任何实质证据证明引用加入注册引用队列时其所指对象一定已被GC回收。因此与其说“引用加入注册引用队列意味着其所指对象已被GC回收”倒不如说“引用加入注册引用队列意味着其所指对象会被GC回收”更加合适…当然…这都是我个人的猜想而已。相比通过get()方法来判断所指对象是否已/会被GC回收“引用入队”方案显然是存在延时的。上文的所有内容都在证明引用加入注册引用队列是程序性行为这在实时性上与直接判断get()方法返回值是否为null的行为是无法比拟的因为该判断在GC线程断开引用与所指对象的连接时就会成立…当然这一切都建立在get()方法未被子类重写或重写时没有添加额外限制的基础上。 开发者可以通过调用引用的isEnqueued()方法或从注册引用队列中取出引用的方式判断引用是否位于注册引用队列中引用会从注册引用队列的头部取出因此可知引用队列与待定列表一样本质都被作为堆栈使用…可能大佬都是这个样子的…名字什么的差不多就可以了。当引用被用户线程从注册引用队列中取出时意味着对于该引用而言整个流程已彻底宣告结束。此时的引用将变为怠惰状态表示其已经没有任何作用只能等待着被GC回收。在这里某些童鞋可能已经发现了如果开发者始终不将引用从注册引用队列中取出是否意味着引用永远都不会变为怠惰状态呢事实确实如此虽说怠惰是引用的最终状态但并不意味着引用一定会以怠惰的状态结束并且上文的流程详述中也存在该类情况在此我将对引用在Reference引用机制中的所有状态变化情况做一个总结具体如下
活动 —— 怠惰引用未注册引用队列活动 —— 待定引用注册了引用队列但本身是Cleaner清洁工类型活动 —— 待定 —— 入队引用注册了引用队列且本身不是Cleaner清洁工类型但直至注册引用队列被GC回收都未曾出队活动 —— 待定 —— 入队 —— 怠惰引用注册了引用队列且本身不是Cleaner清洁工类型并在注册引用队列被GC回收前出队。 状态 文中多次提及了状态但始终没有整体性介绍这个概念故而此处我将所有状态列举出来具体如下所示。在引用抽象类中状态是一个很神奇的东西一是因为其没有组合具体的字段来记录而是通过queue队列字段与next下个字段组合表示的二是在源码中也没有发现任何将之作为判断条件的地方…其似乎就是个单纯的概念专门用于帮助开发者更加清晰的了解整个Reference引用机制…可能我还是有没有学透的地方。 active活动活动状态是引用的初始状态该状态下的引用会受到GC的“特殊照顾”。当所指对象被判定为可回收后如果引用注册了引用队列GC线程会将之加入到待定队列中相当于将状态修改为了待定。而如果引用没有注册引用队列的话则会直接将其状态变为怠惰。当引用的状态为活动时queue队列字段及next下个字段的值如下 queue队列注册引用队列或默认的空引用队列如果未注册引用队列会赋予一个默认的空引用队列表示未注册 next下个null活动是唯一一个next下个字段为null的状态因此可以直接通过判断next下个字段是否为null来判断其是否为活动状态。 pending待定当引用被GC加入待定列表时即表示其状态变为了待定状态该状态下的引用正等待着被“引用处理器”线程加入到注册引用队列中。由于加入待定列表是将引用加入到注册引用队列的前置步骤因此可知只有注册了引用队列的引用才能够转变为这个状态。当引用的状态为待定时queue队列字段及next下个字段的值如下 queue队列注册引用队列待定状态下的引用必然注册了引用队列 next下个this即自引用。 enqueue入队当引用被“引用处理器”线程加入注册引用队列时即表示其状态变为了入队状态这个状态下的引用正等待着被用户线程从注册引用队列中取出。当入队状态下的引用被用户线程从注册引用队列移除时意味着其变为了怠惰状态同时也意味着一个引用可能永远都不会变为怠惰…如果其永远都没有出队的话。当引用的状态为入队时queue队列字段及next下个字段的值如下 queue队列“入队”引用队列一个与“空”引用队列相同的预定值表示当前引用已经加入的注册引用队列可用作引用是否入队的判断条件 next下个注册引用队列中的后继引用如果当前引用为尾节点则为this即自引用。 inactive怠惰引用转变为怠惰状态有两种方式一是因为没有注册引用队列而被GC线程设置二是其从注册引用队列中出队时被用户线程设置。一个状态已经被转变为怠惰的引用意味着其已经没有什么事情可以做了处于生命周期的尾声存在的唯一意义就是等待被GC回收。当引用的状态为怠惰时queue队列字段及next下个字段的值如下 queue队列空引用队列空引用队列即是引用未注册引用队列的默认值也是其从注册引用队列中出队时会被赋予的终结值因此空引用队列有着双重含义 next下个this即自引用。 五 相关系列 《Java ~ Reference【目录】》《Java ~ Reference【源码】》
