深入理解JVM学习笔记（二）
二、垃圾收集器
1.概述
在Java中，程序员不需要去关心内存动态分配和垃圾回收的问题，顾名思义，垃圾回收就是释放垃圾占用的空间，这一切都交给了JVM来处理。
在探讨Java垃圾回收机制之前，我们首先应该记住一个单词：Stop-the-World。Stop-the-world意味着 JVM由于要执行GC而停止了应用程序的执行，并且这种情形会在任何一种GC算法中发生。当Stop-the-world发生时，除了GC所需的线程以外，所有线程都处于等待状态直到GC任务完成。事实上，GC优化很多时候就是指减少Stop-the-world发生的时间，从而使系统具有高吞吐 、低停顿的特点。
2.判断对象死亡
2.1引用计数算法
引用计数算法是通过判断对象的引用数量来决定对象是否可以被回收。
给对象中添加一个引用计数器，每当有一个地方引用它时，计数器值就加1；当引用失效时，计数器值就减1；任何时刻计数器为0的对象就是不可能再被使用的，即表示该对象可视为”垃圾“被回收。
引用计数器算法实现简单，效率高；但是不能解决循环引用问题（A 对象引用B 对象，B 对象又引用A 对象，但是A,B 对象已不被任何其他对象引用）
2.2可达性分析算法
可达性分析算法是通过判断对象的引用链是否可达来决定对象是否可以被回收。
可达性分析算法是通过一些“GC Roots”对象作为起点，从这些节点开始往下搜索，搜索通过的路径成为引用链（Reference Chain），当一个对象没有被GC Roots 的引用链连接的时候，说明这个对象是不可用的。
如图所示，虽然object5，object6，object7之间相互有关联，但是他们到GC Root是不可达的，所以他们将会被判定为是可回收对象。
GC Roots 对象包括：
a) 虚拟机栈（栈帧中的本地变量表）中的引用的对象。
b) 方法区域中的类静态属性引用的对象。
c) 方法区域中常量引用的对象。
d) 本地方法栈中JNI（即一般说的Native方法）的引用的对象。
2.3 四种引用
Java中有四种引用，分别是强引用，软引用，弱引用，虚引用。四种引用强度依次减弱。
- 强引用指在程序代码中普遍存在的，只要强引用存在，垃圾收集器永远不会回收掉被引用的对象。
- 软引用用来描述一些还有用但是非必须的对象。对于软引用关联的对象，在系统发生内存溢出之前，将会把这些对象列进回收范围之中进行第二次回收。
- 被弱引用关联的对象只能生存到下一次垃圾收集发生之前。当垃圾收集器工作时，无论内存是否足够，都会回收掉被弱引用关联的对象。
- 虚引用也称为幽灵引用或者幻影引用。一个对象是否有虚引用的存在，完全不会对其生存时间构成影响，也无法通过虚引用来取得一个对象的实例。为一个对象设置虚引用关联的唯一目的就是能在这个对象被收集器回首时收到一个系统通知。
2.4回收方法区
永久代的垃圾收集主要回收两部分内容：废弃常量和无用的类。回收废弃常量与回收Java堆中的对象非常类似。以常量池中字面量的回收为例，假如一个字符串“abc”已经进入了常量池中，但是当前系统没有任何一个String对象是叫做“abc”的，换句话说是没有任何String对象引用常量池中的“abc”常量，也没有其他地方引用了这个字面量，如果在这时候发生内存回收，而且必要的话，这个“abc”常量就会被系统“请”出常量池。常量池中的其他类（接口）、方法、字段的符号引用也与此类似。
判定一个常量是否是“废弃常量”比较简单，而要判定一个类是否是“无用的类”的条件则相对苛刻许多。类需要同时满足下面3个条件才能算是“无用的类”：
- 该类所有的实例都已经被回收，也就是Java堆中不存在该类的任何实例。
- 加载该类的ClassLoader已经被回收。
- 该类对应的java.lang.Class 对象没有在任何地方被引用，无法在任何地方通过反射访问该类的方法。
虚拟机可以对满足上述3个条件的无用类进行回收，这里说的仅仅是“可以”，而不是和对象一样，不使用了就必然会回收。是否对类进行回收，HotSpot虚拟机提供了-Xnoclassgc参数进行控制，还可以使用-verbose:class及-XX:+TraceClassLoading、 -XX:+TraceClassUnLoading查看类的加载和卸载信息。
在大量使用反射、动态代理、CGLib等ByteCode框架的场景，以及动态生成JSP和OSGi这类频繁自定义ClassLoader的场景都需要虚拟机具备类卸载的功能，以保证永久代不会溢出。
3.垃圾收集算法
3.1标记－清除算法
算法分为“标记”和“清除”两个阶段：首先标记出所有需要回收的对象，在标记完成后统一回收所有被标记的对象。标记－清除算法是最基础的算法，因为后续算法都是在此基础上对其改进的。
缺点：一是效率问题，标记清除两个阶段效率都不高。另一个是空间问题，标记清楚之后会产生大量不连续的内存碎片，空间碎片太多可能会导致以后在程序运行过程中分配较大的对象是，无法找到足够大的内存空间而不得不在进行一次垃圾收集动作。
3.2复制算法
复制算法将可用内存按容量划分为大小相等的两块，每次只使用其中的一块。当这一块的内存用完了，就将还存活着的对象复制到另外一块上面，然后再把已使用过的内存空间一次清理掉。这样使得每次都是对整个半区进行内存回收，内存分配时也就不用考虑内存碎片等复杂情况，只要移动堆顶指针，按顺序分配内存即可，实现简单，运行高效。只是这个算法的代价是将内存缩小为原来的一半，太过浪费。
现在商用的虚拟机都采用这种算法来回收新生代，新生代中98%的的对象都是朝生夕死的，不需要按照1:1的比例来划分内存空间，而是将内存分为一块较大的Eden空间和两块较小的Survivor空间 (如下图所示)，每次使用Eden和其中一块Survivor。当回收时，将Eden和Survivor中还存活着的对象一次地复制到另外一块Survivor空间上，最后清理掉Eden和刚才用过的Survivor空间。HotSpot虚拟机默认Eden和Survivor的大小比例是 8:1，也就是每次新生代中可用内存空间为整个新生代容量的90% ( 80%+10% )，只有10% 的内存会被“浪费”。但是我们没办法保证每次回收都只有不多于10%的对象存活，当Survivor空间不足时，需要依赖其他内存（这里指老年代）进行分配担保。
3.3标记－整理算法
复制算法要进行过多的复制操作，效率较低，且如果不想浪费50%的空间，就需额外的空间进行分配担保，所以老年代一般不能直接选用这种算法。
有人就提出了标记—整理算法法，标记—整理算法和标记—清除算法一样，但是标记—整理算法不是把存活对象复制到另一块内存，而是把存活对象往内存的一端移动，然后直接回收边界以外的内存。
3.4分代收集算法
当前商业虚拟机垃圾收集都采用“分代收集”（Generational Collection）算法，根据对象存活周期不同划分为几块；一般将其分为新生代和老年代。新生代特点：每次垃圾收集时都有大批对象死去，只要少量存活。（采用复制算法）老年代特点：对象存活率高、没有额外空间对它进行分配担保，就采用“标记-清理”或“标记-整理”算法来进行回收。
(1)新生代（Young Generation）
新生代的目标就是尽可能快速的收集掉那些生命周期短的对象，一般情况下，所有新生成的对象首先都是放在新生代的。新生代内存按照 8:1:1 的比例分为一个Eden：From survivor：To survivor区，大部分对象在Eden区中生成。特别地，当To survivor区不足以存放eden区和From survivor区的存活对象时，就将存活对象直接存放到老年代。如果老年代也满了，就会触发一次FullGC，也就是新生代、老年代都进行回收。注意，新生代发生的GC也叫做MinorGC，MinorGC发生频率比较高，不一定等 Eden区满了才触发。
(2)老年代（Old Generation）
老年代存放的都是一些生命周期较长的对象，就像上面所叙述的那样，在新生代中经历了N次垃圾回收后仍然存活的对象就会被放到老年代中。此外，老年代的内存也比新生代大很多(大概比例是1:2)，当老年代满时会触发Major GC(Full GC)，老年代对象存活时间比较长，因此FullGC发生的频率比较低。
(3)永久代（Permanent Generation）
永久代主要用于存放静态文件，如Java类、方法等。永久代对垃圾回收没有显著影响，但是有些应用可能动态生成或者调用一些class，例如使用反射、动态代理、CGLib等bytecode框架时，在这种时候需要设置一个比较大的永久代空间来存放这些运行过程中新增的类。
垃圾回收有两种类型，Minor GC 和 Full GC。
Minor GC：对新生代进行回收，不会影响到年老代。因为新生代的 Java 对象大多死亡频繁，所以 Minor GC 非常频繁，一般在这里使用速度快、效率高的算法，使垃圾回收能尽快完成。
Full GC：也叫 Major GC，对整个堆进行回收，包括新生代和老年代。由于Full GC需要对整个堆进行回收，所以比Minor GC要慢，因此应该尽可能减少Full GC的次数，导致Full GC的原因包括：老年代被写满、永久代（Perm）被写满和System.gc()被显式调用等。
4.垃圾收集器
如果说垃圾收集算法是内存回收的方法论，那么垃圾收集器就是内存回收的具体实现。上面说过，各个平台虚拟机对内存的操作各不相同，因此本章所讲的收集器是基于JDK1.7Update14之后的HotSpot虚拟机。
一共有7种作用于不同分带的收集器，如果两个收集器之间有连线，则说明他们可以搭配使用。其中用于回收新生代的收集器包括Serial、PraNew、Parallel Scavenge，回收老年代的收集器包括Serial Old、Parallel Old、CMS，还有用于回收整个Java堆的G1收集器。
这个虚拟机包含的所有收集器如图：
4.1Serial收集器
新生代单线程收集器，基于复制算法，优点是简单高效。Serial收集器是最基本、发展历史最悠久的收集器，曾经（在JDK 1.3.1之前）是虚拟机新生代收集的唯一选择。这个收集器是一个单线程的收集器，但它的“单线程”的意义并不仅仅说明它只会使用一个CPU或一条收集线程去完成垃圾收集工作，更重要的是在它进行垃圾收集时，必须暂停其他所有的工作线程，直到它收集结束。适用于Client模式下的虚拟机
4.2ParNew收集器
新生代并行收集器，ParNew收集器其实就是Serial收集器的多线程版本，除了使用多条线程进行垃圾收集之外，其余行为包括Serial收集器可用的所有控制参数（例如：-XX：SurvivorRatio、-XX：PretenureSizeThreshold、-XX：HandlePromotionFailure等）、收集算法、Stop The World、对象分配规则、回收策略等都与Serial收集器完全一样，在实现上，这两种收集器也共用了相当多的代码。
除了Serial收集器，只有他能与CMS收集器配合工作，也是基于复制算法，适用于Server模式下的虚拟机
4.3Parallel Scavenge收集器
Parallel Scavenge收集器基于复制算法，是并行的多线程收集器。
Parallel Scavenge收集器的特点是它的关注点与其他收集器不同，Parallel Scavenge收集器的目标是达到一个可控制的吞吐量（Throughput）。所谓吞吐量就是CPU用于运行用户代码的时间与CPU总消耗时间的比值，即吞吐量=运行用户代码时间/（运行用户代码时间+垃圾收集时间）。由于与吞吐量关系密切，Parallel Scavenge收集器也经常称为“吞吐量优先”收集器。主要适合在后台运算而不需要太多交互的任务。
4.4Serial Old
老年代单线程收集器，Serial Old是Serial收集器的老年代版本，它同样是一个单线程收集器，使用“标记-整理”算法。这个收集器的主要意义也是在于给Client模式下的虚拟机使用。如果在Server模式下，那么它主要还有两大用途：一种用途是在JDK 1.5以及之前的版本中与Parallel Scavenge收集器搭配使用，另一种用途就是作为CMS收集器的后备预案，在并发收集发生ConcurrentMode Failure时使用。
4.5Parallel Old收集器
老年代并行收集器，吞吐量优先。Parallel Old是Parallel Scavenge收集器的老年代版本，使用多线程和“标记-整理”算法。这个收集器是在JDK 1.6中才开始提供的。
4.6CMS收集器
老年代并行收集器，以获取最短回收停顿时间为目标的收集器，具有高并发、低停顿的特点，追求最短GC回收停顿时间。
CMS（Concurrent Mark Sweep）收集器是一种以获取最短回收停顿时间为目标的收集器。目前很大一部分的Java应用集中在互联网站或者B/S系统的服务端上，这类应用尤其重视服务的响应速度，希望系统停顿时间最短，以给用户带来较好的体验。CMS收集器是基于“标记—清除”算法实现的，运作过程分为4个步骤，包括：
a)初始标记（CMS initial mark）
b)并发标记（CMS concurrent mark）
c)重新标记（CMS remark）
d)并发清除（CMS concurrent sweep）
初始标记、重新标记仍需要“Stop The World”。初始标记仅仅只是标记一下GC Roots能直接关联的对象，速度很快，并发标记阶段就是进行GC Roots Tracing的过程，而重新标记阶段是为了修正并发标记期间因用户程序继续进行而导致标记产生变动的那一部分对象的标记记录。
CMS收集器存在3个缺点：
1 对CPU资源敏感。一般并发执行的程序对CPU数量都是比较敏感的
2 无法处理浮动垃圾。在并发清理阶段用户线程还在执行，这时产生的垃圾无法清理。
3 由于标记-清除算法产生大量的空间碎片。
4.7G1收集器
G1是一款面向服务端应用的垃圾收集器。Java堆并行收集器，G1收集器是JDK1.7提供的一个新收集器，G1收集器不同于之前的收集器的一个重要特点是：G1回收的范围是整个Java堆(包括新生代，老年代)，而前六种收集器回收的范围仅限于新生代或老年代。G1具备如下特点：
- 并行与并发
- 分代收集：虽然G1不需要其他收集器配合就能独立管理整个GC堆，但分带概念在G1中仍然得到保留。
- 空间整合：G1从整体看是基于“标记-整理”算法实现，从局部看是基于“复制”算法，也就是说G1运行期间不会产生内存空间碎片。
- 可预测的停顿:G1除了追求低停顿外，还能建立可预测的停顿时间模型。
G1收集器的运作大致可划分为以下几个步骤：
a) 初始标记（Initial Marking）
b) 并发标记（Concurrent Marking）
c) 最终标记（Final Marking）
d) 筛选回收（Live Data Counting and Evacuation）
初始标记阶段仅仅只是标记一下GC Roots等直接关联的对象，并发标记阶段开始对堆中的对象进行可达性分析，找出存活的对象。最终标记阶段则是为了修正在并发标记阶段因用户程序继续运行而导致标记产生变动的那一部分标记记录。筛选回收阶段首先对各个Region的回收价值和成本进行排序，根据用户所期望的GC提顿时间来制定回收计划。
5.内存分配策略
1.对象优先在Eden分配
2.大对象直接进入老年代
所谓的大对象是需要大量连续内存空间的Java对象，最典型的大对象就是那种很长的字符串以及数组。
3.长期存活的对象直接进入老年代
本博客图片皆来源于网络，如有侵权，请与我联系。