标签：常量 范围 queue jdk 循环 关联 image 推荐阅读 虚拟机
首先说为什么要判断是否存活，当垃圾收集器在对堆进行回收前，第一就是要确定对象哪些是还在被引用的或者后面还需要被引用的，即存活，哪些是已经“死去”（即不可能再被任何途径使用）
在对象中添加一个引用计数器，每当有一个地方引用它时，计数器值就加1，引用失效时就减1.任何时刻计数器为0的对象就是不可能再被使用的。这个方法效率挺高，大部分情况下也是很不错的算法。
但是在JVM中会很难解决对象之间相互循环引用的问题，就如果两个对象之间相互调用，这时候就会发生类似死锁的情况，即这个地方相互调用会使得引用计数法始终认为有对象在引用当前对象，就一直计数值大于或等于1，也就无法通知GC收集器回收它们。但是实际的情况是这两个对象后面已经不再调用，所以这个方法虽然简单高效，但不是我们的首选。虚拟机也不是通过这个算法来判断对象是否存活的。
使用一系列的GC Roots的对象（包括：虚拟机栈中引用的对象，方法区中类静态属性引用的对象，方法区中常量引用的对象，本地方法栈中JNI引用的对象）作为起点，从节点开始向下搜索，当没有被GCRoots链接到的对象就可以回收，如下图的对象4和5就判断为可回收对象。
在JDK1.2之后，Java对引用这个概念进行了扩充，也就是对象不仅仅只有引用和没有引用两个概念，而是扩展到了4个：
强引用：类似于“Object obj=new Object（）”只要强引用在，垃圾收集器永远不会回收掉被引用的对象。
软引用：是用来描述一些还有用但是并非必需的对象，对于软引用对象，在内存溢出异常之前，会把这些对象列进回收范围之中进行第二次回收。
弱引用，比软引用更弱一点，被弱引用关联的对象只能生存到下一次垃圾收集发生之前。当垃圾收集发生时无论内存是否足够，都会只回收弱引用的对象。
虚引用，最弱的引用关系，对象是否有虚引用对其生存时间是没有影响的。唯一目的就是能在这个对象被收集器回收时收到一个系统通知。
对象要想真正宣告“死亡”需要至少两次的标记过程，当对象在可达性分析时候发现没有被GC Roots链到那么对象就会进行第一次标记并且进行第一次筛选，筛选的条件就是判断该对象有没有必要执行finalize()方法，需要执行的话就会把对象放入F-Queue的对列中去执行该对象中的finalize()方法。如果finalize()方法让对象重新被GC Roots链到那么对象就重新活下来，否则就会进行第二次标记，等待垃圾回收的到来
虚拟机栈中引用的对象；
方法区中类静态属性引用的对象；
方法区中常量引用的对象；
深入解析HashMap和ConcurrentHashMap源码以及底层原理
设计模式(二):几种工厂模式详解
进程同步的五种机制以及优缺点(翻译)
redis五种数据类型的实现方式，常用命令，应用场景
redis和memcahed的共同点，区别以及应用场景
详解TCP的三次握手与四次挥手及面试题（很全面）
Arrays 工具类详解（超详细）
算法必须掌握几种方法
QPS、TPS、并发用户数、吞吐量
设计模式之单例模式
标签：常量 范围 queue jdk 循环 关联 image 推荐阅读 虚拟机
原文地址：https://blog.51cto.com/14977428/2545018
