5.2.1、在Java中如何判断对象已死？
引用计数算法
给对象中添加一个引用计数器，每当有一个地方引用它时，计数器值就加一1；当引用失效时，计数器值就减1；任何时刻计数器为0的对象就是不可能被使用的。
反例：对象之间相互循环引用
可达性分析法
这个算法的基本思路就是通过一系列的称为“GC Roots”的对象作为起点，从这些节点开始向下搜索，搜索所走过的路径称为引用链（Reference Chain），当一个对象到GC Roots没有任何引用链相连（用图论的话说，就是从GC Roots到这个对象不可达）时，则证明此对象是不可用的。
在Java语言中，可作为GC Roots的对象包括以下几种：
- 虚拟机栈（栈中的本地变量表）中引用的对象
- 方法区中类静态属性引用的对象
- 方法区中常量引用的对象
- 本地方法栈中JNI（即一般说的Native方法）引用的对象
引用强度
强引用就是指在程序代码中普遍存在的，类似“Object obj=new Object()”这类的引用，只要强引用还存在，垃圾收集器就永远不会回收掉被引用的对象
软引用是用来描述一些还有用但并非必须的对象。对于软引用关联着的对象，在系统将要发生内存溢出异常之前，将会把这些对象列进回收范围之中就行第二次回收。如果这次回收还没有足够的内存，才会抛出内存溢出异常。
弱引用也是用来描述非必须对象的，但是它的强度比弱引用更弱一些，被弱引用关联的对象只能生存到下一次垃圾收集发生之前。当垃圾收集器工作时，无论当前内存是否足够，都会回收掉只被弱引用关联的对象。
虚引用也称为幽灵引用或者幻影引用，它时最弱的一种引用关系。一个对象是否有虚引用的存在，完全不对其生存时间构成影响，也无法通过虚引用来取得一个对象实例。为一个对象设置虚引用关联的唯一目的就是能在这个对象被垃圾收集器回收时收到一个系统通知。
在Java中对象什么时候可以被回收？
当一个对象到GC Roots不可达时，在下一个垃圾回收周期中尝试回收该对象，如果该对象重写了finalize()方法，并在这个方法中成功自救(将自身赋予某个引用)，那么这个对象不会被回收。但如果这个对象没有重写finalize()方法或者已经执行过这个方法，也自救失败，该对象将会被回收。
5.2.2、垃圾收集算法
标记-清除算法
最基础的收集算法，如同它的名字一样，算法分为“标记”和“清除”两个阶段：首先标记处所有需要回收的对象，在标记完成后统一回收所有被标记的对象。
缺点：
- 效率问题，标记和清除两个过程的效率都不高。
- 空间问题，标记清除之后会产生大量不连续的内存碎片，空间碎片太多可能会导致以后在程序运行过程中需要分配大对象时，无法找到足够的连续内存而不得不提前出发另一次垃圾收集动作。
复制算法
为了解决效率问题，提出了“复制”算法，它将可用内存按容量划分为大小相等的两块，每次只使用其中一块。当这一块的内存用完了，就将还存活着的对象复制到另外一块上面，然后把已使用过的内存空间一次清理掉。这样使得每次都是对整个半区进行内存回收，内存分配时也就不用考虑内存碎片等复杂情况，只要制动堆顶指针，按顺序分配内存即可，实现简单，运行高效。
缺点：这种算法的代价是内存缩小为原来的一半，未免太高了一点。
标记-整理算法
复制收集算法在对象存活率高时就要进行较多的复制操作，效率会变低。更关键的是，如果不想浪费50%的空间，就需要有额外的空间进行分配担保，以应对被使用的内存中所有对象都100%存活的极端情况，所以在老年代一般不能直接选用这种算法。
根据老年代特点，有人提出了另外一种“标记-整理”算法，标记过程仍然与标记-清理算法一样，但后续步骤不是直接对可回收对象进行清理，而是让所有存活对象都向一端移动，然后直接清理掉端边界以外的内存。
分代收集算法
当前商业虚拟机的垃圾收集都采用“分代收集”算法，这种算法并没有什么新的思想，只是根据对象存活周期的不同将内存划分为几块。一般是把Java堆分为新生代和老年代，这样就可以根据各个年代的特点采用最适当的收集算法。在新生代中，每次垃圾收集时都发现有大批对象死去，只有少量存活，那就选用复制算法，只需要付出少量存活对象的复制成本就可以完成收集。而老年代中因为对象存活率高、没有额外空间对它进行分配担保，就必须使用“标记-清理”或者“标记-整理”算法来完成回收。
5.2.3、垃圾收集器
如果说收集算法是内存回收的方法论，那么垃圾收集器就是内存回收的具体实现。Java虚拟机规范中对垃圾收集器应该如何实现并没有任何规定，因此不同的厂商、不同版本的虚拟机所提供的垃圾收集器都可能会有很大的差别，并且一般都会提供参数供用户根据自己的应用特点和要求组合出各个年代所使用的的收集器。
HotSpot虚拟机的垃圾收集器
Serial 收集器
Serial 收集器是最基本、发展历史最悠久的收集器，曾经是虚拟机新生代收集的唯一选择。这个收集器是一个单线程的收集器，但它的“单线程”的意义并不仅仅说明它只会使用一个CPU或一条收集线程去完成垃圾收集工作，更重要的是在它进行垃圾收集时，必须暂停其他所有的工作线程，直到它完成收集结束。
ParNew 收集器
ParNew收集器其实就是Serial 收集器的多线程版本。
Parallel Scavenge 收集器
Parallel Scavenge 收集器的特点是它的关注点与其他收集器不同，CMS等收集器的关注点是尽可能地缩短垃圾收集时用户线程的停顿时间，而Parallel Scavenge收集器的目标则是达到一个可控制的吞吐量。所谓吞吐量就是CPU用于运行用户代码的时间与CPU总消耗时间的比值，即吞吐量=运行用户代码时间/（运行用户代码时间+垃圾收集时间）。
由于与吞吐量关系密切，Parallel Scavenge收集器也经常被称为“吞吐量优先”收集器。
Serial Old 收集器
Serial Old 收集器是Serial的老年代版本，它同样是一个单线程收集器，使用“标记-整理”算法。这个收集器的主要意义也是在于给Client模式下的虚拟机使用。
Parallel Old 收集器
Parallel Old 收集器是Parallel Scavenge收集器的老年代版本，使用多线程和“标记-整理”算法。
CMS 收集器
CMS收集器是一种以获得最短挥手停段时间为目标的收集器。目前很大一部分Java应用集中在互联网网站或者B/S系统服务端上，这类应用尤其重视服务的响应速度，希望系统停顿时间最短，以给用户带来较好的体验。CMS收集器就非常适合这类应用的需求。
CMS收集器是基于“标记-清除”算法实现的，它的运作过程相对于前面几种收集器来说更复杂一些，整个过程分为4个步骤，包括：
- 初始标记
- 并发标记
- 重新标记
- 并发清除
其中，初始标记、重新标记这两个步骤仍需要“Stop The World”。初始标记仅仅只是标记一下GC Roots能直接关联的对象，速度很快，并发标记阶段就是进行GC Roots Tracing的过程，而重新标记阶段则是为了修正并发标记期间因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间一般会比初始标记阶段稍长一些，但远比并发标记的时间短。
从总体上来说，CMS 收集器的内存回收过程是与用户线程一起并发执行的。
CMS主要优点：并发收集、低停顿。但这还远达不到完美的程度，它有以下3个明显的缺点：
- CMS收集器对CPU资源非常敏感。
- CMS收集器无法处理浮动垃圾，可能出现“Concurrent Model Failure”失败而导致另一次Full GC的产生。由于CMS并发清理阶段用户线程还在运行着，伴随程序运行自然就还会有新的垃圾不断产生，着一部分垃圾出现在标记过程之后，CMS无法在当次收集中处理掉它们，只好留待下一次GC时再清理掉。
- CMS是一款基于“标记-清除”的算法实现的收集器，这就意味着收集结束时会有大量空间碎片产生。空间碎片过多时，将会给大对象分配带来很大麻烦，往往会出现老年代还有很大空间剩余，但是无法找到足够大的连续空间来分配当前对象，不得不提前触发一次Full GC。
G1 收集器
G1是一款面向服务端应用的垃圾收集器。与其他GC收集器相比，G1具备如下特点：
- 并发与并行：G1能充分利用CPU、多核环境下的硬件优势，使用多个CPU（CPU或CPU核心）来缩短Stop-The-World停顿的时间，部分其他收集器原本需要停顿Java线程执行的GC动作，G1收集器仍然可以通过并发的方式让Java程序继续执行。
- 分代收集：与其他收集器一样，分代概念在G1中仍然得以保留。虽然G1可以不需要其他收集器配合就能独立福利整个GC堆，但它能够采用不同的方式去处理新建立的对象和已经存活了一段时间、熬过多次GC的就对象以获取更好的收集效果。
- 空间整合：与CMS的“标记-清理”算法不同，G1从整体上看是基于“标记-整理”算法实现的收集器，从局部上看是基于“复制”算法实现的。
- 可预测的停顿：这是G1相对于CMS的另一大优势，降低停顿时间是G1和CMS共同的关注点，但G1除了追求低停顿外，还能建立可预测的停顿时间模型，能让使用者明确指定在一个长度为M毫秒的时间片段内，消耗在垃圾收集上的时间不得超过N毫秒，这几乎已经是实时Java的垃圾收集器的特征了。
在G1之前的其他垃圾收集器进行垃圾收集的范围都是整个新生代或者老年代，而G1不再是这样。使用G1收集器时，Java堆内存布局就与其他垃圾收集器有很大差别，它将整个Java堆划分为多个大小相等的独立区域（Region），虽然还保留有新生代和老年代的概念，但新生代和老年代不再是物理隔离的了，他们都是一部分的Region的集合。
G1把内存“化整为零”的思路，理解起来似乎很容易，但其中的实现细节却远远没有想象中那么简单。
G1收集器的运作大致可划分为一下几个步骤：
- 初始标记
- 并发标记
- 最终标记
- 筛选回收
5.2.4、内存分配与回收策略
Java技术体系中所提倡的自动内存管理最终可以归结为自动化地解决两个问题：给对象内存以及回收分配给对象的内存，回收内存已经在上文介绍了很多内容，接下来简单介绍一下关于对象内存分配的内容
对象优先在Eden分配
大多数情况下，对象在Eden区中分配。当Eden区没有足够的空间进行分配时，虚拟机将发起一次Minor GC
大对象直接进入老年代
所谓的大对象是指，需要大量连续内存的Java对象，最典型的的大对象就那种很长的字符串以及数组。大对象对虚拟机的内存分配来说就是一个坏消息，经常出现大对象容易导致内存还有不少空间时就提前出发垃圾收集以获取足够的连续空间。
长期存活的对象将进入老年代
如果对象在Eden出生并经过第一次Minor GC后仍然存活，并且能被Survivor容纳的话，将被移动到Suvivor空间中，并且对象年龄设为1。对象在Survivor区中没“熬过”一次Minor GC，年龄就增加1岁，当它的年龄增加到一定程度（默认为15岁），就会被晋升到老年代中。
动态对象年龄判定
虚拟机并不总是永远要求对象年龄必须达到了MaxTenuringThreshold才能晋升老年代，如果在Survivor空间中相同年龄所有对象大小的综合大于Survivor空间的一般，年龄大于或等于改年龄的对象就可以直接进入老年代。
空间分配担保
在发生Mivor GC之前，虚拟机会先检查老年代的最大可用的连续空间是否大于新生代所有对象总空间，如果这个条件成立，nameMivor GC可以确保是安全的。如果这个条件不成立，则虚拟机会查看HandlePromotionFilure设置值是否允许担保失败。如果允许，那么会继续检查老年代最大可用的连续空间是否大于历次晋升到老年代对象的平均大小，如果大于，将尝试着进行一次Minor GC，尽管这次Minor GC是有风险的；如果小于，或者HandlePromotionFailure设置不允许毛线，那么这是也要改为进行一次Full GC