继JVM内存模型以及调优（一）我们了解JVM中各个区域的作用，之后我们再接着深入的了解JVM的堆区。
堆区中主要存储运行时实例对象和数组数据，所以也就成了垃圾回收器的主要活动区域了，那么随着程序一直在跑，那么堆区中的对象肯定是越来越多，这时我们就需要进行将已经不需要的对象进行清理，那我们如何知道哪些对象是已经不需要的了呢？ 还有如何进行垃圾对象清理呢？不要急，我们一步一步来...
Java中的引用类型
Java中的引用（不展开细讲了，本章只讲和垃圾回收相关的内容）分为以下四类：
- 强引用： 发生GC的时候不会被回收。
- 软引用： 有用但不是必须的对象，在发生内存溢出之前会被回收。
- 弱引用： 有用但不是必须要的对象，在下一次GC时会被回收。
- 虚引用： 无法通过虚引用获得对象，用PhantomReference 实现虚引用，虚引用的用途是在GC时返回一个通知。
如何判断对象是否可以被回收？什么时候被回收？
垃圾收集器在做垃圾回收的时候，首先需要判定的就是哪些内存是需要被回收的，哪些对象是存活的，是不可以被回收的；哪些对象已经死亡了，需要被回收。
一般有两种方法来判断： 引用计数器法：为每个对象创建一个引用计数，有对象引用时计数器 +1，引用被释放时计数 -1，当计数器为 0 时就可以被回收。但是他有一个缺点是不能解决循环引用的问题。
可达性分析算法：从 GC Roots 开始向下搜索，搜索所走过的路径称为引用链。当一个对象到 GC Roots 没有任何引用链相连时，则证明此对象是可以被回收的。
当对象对当前使用这个对象的应用程序变得不可触及的时候，这个对象就可以被回收了。
垃圾回收不会发生在永久代，如果永久代满了或者是超过了临界值，会触发完全垃圾回收(Full GC)。查看垃圾收集器的输出信息，就会发现永久代也是被回收的。这就是为什么正确的永久代大小对避免Full GC是非常重要的原因。
垃圾回收算法
基于上面的引用和对于对象是否可以被回收的判断，我们已经知道了如何判断一个对象是否会被垃圾回收器进行回收，那么垃圾回收器如何进行垃圾回收呢？有以下几种方式，下面分别讲一下优缺点
1.标记-清除算法：标记无用对象，然后进行清除回收。缺点：效率不高，无法清除垃圾碎片。
该算法分为两个阶段，标记和清除。标记阶段标记所有需要回收的对象，清除阶段回收被标记的对象所占用的空间。该算法最大的问题就是内存碎片严重化，后续可能发生对象不能找到利用空间的问题。
2.复制算法：按照容量划分二个大小相等的内存区域，当一块用完的时候将活着的对象复制到另一块上，然后再把已使用的内存空间一次清理掉。缺点：内存使用率不高，只有原来的一半。
- 按内存容量将内存划分为等大小的两块。每次只使用其中一块，当这一块内存满后将尚存活的对象复制到另一块上去，把已使用的内存清掉。
3.标记-整理算法：标记无用对象，让所有存活的对象都向一端移动，然后直接清除掉端边界以外的内存。
- 标记后不是清理对象，而是将存活对象移向内存的一端。然后清除端边界外的对象。
4.分代算法：根据对象存活周期的不同将内存划分为几块，一般是新生代和老年代，新生代基本采用复制算法，老年代采用标记整理算法。
内存模型实例图： 
大多数的商业虚拟机，都采用分代回收的理论来设计垃圾收集器，这个理论建立在两个分代假说上：
弱分代假说：绝大多数对象都是朝生夕死的。
强分代假说：熬过越多次的垃圾回收的对象，就越难消亡
既然绝大多数对象都熬不过几次垃圾回收，而熬过多次回收的对象又很难消亡，那么可以根据年龄把它们划分到不同的区域，例如新生代区域和老年代区域，然后分而治之。
新生代（Young generation）
绝大多数新创建的对象都会被分配到这里，这个区域触发的垃圾回收称之为：Minor GC 。
空间结构：
默认情况下，新生代（Young generation）、老年代（Old generation）所占空间比例为 1 : 2 。
它被分成三个空间：
· 1个伊甸园空间（Eden）
· 2个幸存者空间（Fron Survivor、To Survivor）
默认情况下，新生代空间的分配：Eden : Fron : To = 8 : 1 : 1
为什么要这样的布局？是因为新生代里的对象绝大多数是朝生夕死的，非常适合使用标记-复制算法，后面的回收算法章节会详细说。
新生代GC收集的执行顺序如下：
1、绝大多数新创建的对象会存放在伊甸园空间（Eden）。
2、在伊甸园空间执行第 1 次GC（Minor GC）之后，存活的对象被移动到其中一个幸存者空间（Survivor）。
3、此后每次 Minor GC，都会将 Eden 和 使用中的Survivor 区域中存活的对象，一次性复制到另一块空闲中的Survivor区，然后直接清理 Eden 和 使用过的那块Survivor 空间。
4、从以上空间分配我们知道，Survivor区内存占比很小，当空闲中的Survivor空间不够存放活下来的对象时，这些对象会通过分配担保机制直接进入老年代。
5、在以上步骤中重复N次（N = MaxTenuringThreshold（年龄阀值设定，默认15））依然存活的对象，就会被移动到老年代。
从上面的步骤可以发现，两个幸存者空间，必须有一个是保持空的。
我们需要重点记住的是，新创建的对象，是保存在伊甸园空间的（Eden）。那些经历多次GC依然存活的对象会经由幸存者空间（Survivor）转存到老年代空间（Old generation） 。
也有例外出现，对于一些大的对象（指需要占用大量连续内存空间的对象）则直接进入到老年代。
Java提供了 -XX:PretenureSizeThreshold 来指定对象大于这个值，直接分配到老年代。
老年代（Old generation）
对象在新生代周期中存活了下来的，会被拷贝到这里。通常情况下这个区域分配的空间要比新生代多。正是由于对象经历的GC次数越多越难回收，加上相对大的空间，发生在老年代的GC次数要比新生代少得多。这个区域触发的垃圾回收称之为：Major GC 或者 Full GC
老年代空间的构成其实很简单，它不像新生代空间那样划分为几个区域，它只有一个区域，里面存储的对象并不像新生代空间里绝大部分都是朝闻道，夕死矣。这里的对象几乎都是从Survivor 空间中熬过来的，它们绝不会轻易狗带。因此，Major GC 或 Full GC 发生的次数不会有 Minor GC 那么频繁。
为什么老年代的回收耗时，比新生代更长呢？ 有两点原因：
1、老年代内存占比更大，所以理论上回收的时间也更长
2、老年代使用的是标记-整理算法，清理完成内存后，还得把存活的对象重新排序整理成连续的空间，成本更高（算法的细节，后续章节会详细说。）
方法区（Method area）
这个区域主要回收废弃的常量和类型，例如常量池里不会再被使用的各种符号引用等等。类型信息的回收相对来说就比较严苛了，必须符合以下3个条件才会被回收：
1、所有实例被回收
2、加载该类的ClassLoader 被回收
3、Class 对象无法通过任何途径访问（包括反射）
可以使用 -Xnoclassgc 禁用方法区的回收。
跨代引用的问题
举个栗子，新生代中的对象很有可能会被老年代里的对象所引用，当新生代触发GC的时候，只搜索新生代的区域明显是不够的，还得搜索老年代的对象是否引用了新生代中非 GC Roots 引用链上的对象，来确保正确性。但这样做会带来很大的性能开销。为了解决这个问题，Java定义了一种名为记忆集的抽象的数据结构，用于记录存在跨区域引用的对象指针集合。
大多数的虚拟机，都采用一种名为卡表（Card Table） 的方式去实现记忆集，卡表由一个数组构成，每一个元素都对应着一块特定大小的内存区域，这块内存区域被称之为卡页（Card Page），每一个卡页，可能会包含N个存在跨区域引用的对象，只要存在跨区域引用的对象，这个卡页就会被标识为1。当GC发生的时候，就不需要扫描整个区域了，只需要把这些被标识为1的卡页加入对应区域的 GC Roots 里一起扫描即可。
Q & A
为什么老年代不使用和新生代一样的标记-复制算法呢？
新生代里绝大多数对象都是朝生夕死的，使用的标记-复制算法，空间占比可以8 : 1 : 1，但是老年代里对象存活率很高，这个占比明显不合适。如果占比得设置得大 (例如50%)，又会浪费很多内存空间，而且由于对象很多都是存活的，复制移动也是一笔开销。所以标记-复制这个算法，不适合老年代这种对象存活率很高的区域。
标记和根搜索算法是什么样的关系？
Java使用的是根搜索（可达性分析）算法来确定对象是否存活的，而不是引用计数法这种事先在对象里记录引用数的做法。
标记其实不用遍历整个内存空间（除非内存空间里的对象全部存活），而是通过根搜索算法顺着引用链遍历标记存活的对象。所以标记的过程，就是根搜索算法查找存活对象的过程。
标记-整理算法，每次整理都消耗大量时间，能不能优化一下？
可以的，每次回收后，都进行整理，确实会消耗太多的资源。可以通过设置一个阈值或者临界点，当内存碎片化程度还在这个阈值范围内的时候，仅采用标记-清除算法。只有超过这个阈值，才进行整理。
什么是内存碎片？它会带来什么问题？
从上面 标记-清除 算法，我们看到回收完成后，会产生很多不连续的内存空间，这就是内存碎片。
Java虚拟机对于大对象（例如很长的字符串、byte数组等等），都必须存储在连续的内存空间里，当一个大对象需要进入某个内存空间时，由于内存碎片过多，虽然剩余内存是远大于这个对象所需空间的，但就是找不到一块连续的内存空间来存储它，这会导致提前触发一次Full GC。
常用的垃圾回收器
每一个回收器都存在Stop The World的问题，只不过各个回收器在Stop The World时间优化程度、算法的不同，可根据自身需求选择适合的回收器。
目前应用范围最广的，应该还是JDK8，它默认使用的是Parallel Scavenge + Parallelo Old收集器组合
Serial（-XX:+UseSerialGC）
Serial 是Java虚拟机初代收集器，在JDK1.3之前是Java虚拟机新生代收集器的唯一选择，这是一个单线程工作的收集器。在进行垃圾回收的时候，需要暂停所有的用户线程，直到回收结束。
虽然历史久远，但它依然是HotSpot虚拟机运行在客户端模式下，或者4核4GB以下服务端的默认新生代收集器，这种核心数和内存空间较小的场景下，它单线程的优势就体现出来了，没有线程交互的开销，加上内存空间不大，单次回收耗时几十毫秒，这点停顿时间，完全是可以接受的。
Serial 负责收集新生代区域，它采用标记-复制算法。
Serial Old（-XX:+UseSerialOldGC）
SerialOld 是 Serial 收集器的老年代版本，和 Serial 一样，它也是单线程的收集器。目前主要应用在客户端模式（Client VM）下的HotSpot虚拟机使用。
如果在服务端模式（Server VM）下，它也有两种用途：一个是在JDK5以及之前，和Parallel Scavenge收集器搭配使用，另外一个就是作为CMS收集器在出现并发模式故障（Concurrent Mode Failure） 时作为后备收集器。
SerialOld 负责收集老年代区域，它采用标记-整理算法。
ParNew（-XX:+UseParNewGC）
随着计算机的核心数和内存容量都在飞速发展，多核心和大内存容量的场景下，Serial 收集器单线程的性能明显比较落后了，ParNew 就是 在Serial 收集器的基础之上，实现了它的多线程版本。它可以多条线程同时进行垃圾收集，这也是它和 Serial 收集器的最大的区别，其他的功能性、配置、策略等等的和 Serial 基本一致。
ParNew有一个比较重要的知识点，在JDK9之后，Java官方取消了ParNew和除了CMS收集器之外的所有老年代收集器的搭配，而且还取消了 - XX:+UseParNewGC 这个参数。所以JDK9之后，ParNew只能和CMS搭配使用了。
ParNew 负责收集新生代区域，它采用标记-复制算法。
ParNew 是JDK7之前 Server VM 模式下的首选的新生代收集器。但是在单CPU的情况下，它的效率不会比 Serial收集器高的，所以要注意使用场景。
Parallel Scavenge（-XX:+UseParallelGC）
Parallel Scavenge 从外观上看，和 ParNew 很相似，都是新生代的收集器，支持多线程并行回收，也同样是使用标记-复制来作为回收算法。但 Parallel Scavenge 的关注点不一样，它的目标是实现一个可控制吞吐量的垃圾收集器。
吞吐量的计算公式：运行用户代码时间 / (运行用户代码时间 + 运行垃圾收集时间)
假设运行用户代码时间是 99 分钟，运行垃圾收集时间是 1 分钟，结合计算公式 ：吞吐量 = 99 / (99 + 1) = 0.99，也就是 99% 的吞吐量。
Parallel Scavenge 收集器提供了一些参数，给用户按自身需求控制吞吐量：
-XX:MaxGCPauseMillis
控制垃圾收集停顿的最大时间，单位是毫秒，可以设置一个大于0的数值。
不要想着把这个数值设置得很小来提升垃圾收集的速度，这里缩短的停顿时间是以牺牲新生代空间大小换来的，空间小，回收自然就快，停顿时间自然也短，但是空间小，吞吐量自然也会小。所以得综合考虑。
-XX:GCTimeRatio设置垃圾收集时间占比的计算因子，参数范围是0 - 100的整数。它的公式是 1 / (1+GCTimeRatio)
举个栗子：当设置成15，那就是 1 / (1+15) = 0.0625，就是允许最大垃圾收集时间占总时间的6.25%，当设置成99的时候，就是 1 / (1+99) = 0.01，也就是允许最大垃圾收集时间占总时间的1%，依次类推。
-XX:+UseAdaptiveSizePolicy动态调整开关，这个参数和 Parallel Scavenge 收集器无关，但是搭配起来使用是一个很好的选择。
当这个参数被激活，就不需要人工指定新生代的大小、Eden和Survivor区的比例、对象直接进入老年代的大小等等细节参数了，JVM会根据当前运行的情况动态调整，给出最合适的停顿时间和吞吐量。搭配以上两个参数，和把基本的内存数据设置好即可，例如堆的最大占用空间等等。
Parallel Old（-XX:+UseParallelOldGC）
就像 Serial Old 是 Serial 的老年代版本一样，Parallel Old 是 Parallel Scavenge 的老年代版本。
Parallel Old 也支持多线程并行回收的能力，使用标记-整理来作为回收算法。这个收集器是JDK6的时候推出的，和 Parallel Scavenge 搭配，在多CPU核心和大内存的场景下，吞吐性能优秀。
在注重吞吐量和多CPU核心的情况下，都可以优先考虑 Parallel Scavenge + Parallelo Old 收集器，这也是JDK8默认的垃圾收集器组合。
CMS （-XX:+UseConcMarkSweepGC）
CMS（Concurrent Mark Sweep） 是JDK1.4后期推出的GC收集器，它是一款并发低停顿的收集器，对于响应速度有较高要求，对停顿时间忍受度低的应用，非常适合使用CMS作为垃圾收集器。
CMS 负责收集老年代区域，它采用标记-清除算法。
它的运行过程相对于前几个来说会复杂一些，可以分为四个步骤：
1、初始标记（CMS initial mark）
这个阶段需要 Stop Tow World（暂停暂停所有用户线程），但这个阶段的速度很快，因为只标记和根节点（GC Roots）直接关联的对象。
2、并发标记（CMS Concurrent mark）
这个阶段不需要 Stop Tow World，在初始标记完成后，并发标记从GC Roots直接关联的对象开始，遍历整个引用链，这个阶段耗时较长，但用户线程可以和GC线程一起并发执行。
3、重新标记（CMS remark）
这个阶段需要 Stop Tow World，因为并发标记阶段，用户线程和标间线程同时在运行，相当于一边扫地一边丢垃圾，重新标记就是修正用户线程继续运行，导致的变动的那一部分对象。这一阶段的耗时比初始标记长一些，但远没有达到并发标记阶段那么长的时间。这个阶段可以多线程并行标记。
4、并发清理（Concurrent sweep）
这个阶段不需要 Stop Tow World，执行到这里，说明标记阶段已经完成，此时遍历整个老年代的内存空间，清理掉可回收的对象，由于不需要移动整理存活的对象，这个阶段可以允许用户线程和回收线程并发执行。在清理完成后，会重置CMS收集器的数据结构，等待下一次垃圾回收。
以上4个步骤可以看出，CMS之所以能实现低延迟，是因为它把垃圾搜集分成了几个明确的步骤，在一些耗时较长的阶段实现了用户线程和GC线程并发执行的能力。用两次短暂的 Stop Tow World 来代替了其他收集器一整段长时间的 Stop Tow World。
CMS确实是非常优秀的垃圾收集器，但它也是有缺点的：
1、内存碎片。 由于使用了 标记-清理 算法，回收结束后会产生大量不连续的内存空间，也就是内存碎片。
2、GC进行时会降低吞吐量。 由于使用了并发处理，很多情况下都是GC线程和应用线程并发执行的，GC线程肯定会占用一部分计算资源，这个期间会降低一部分吞吐量（尽管这样，也比之前几个收集器好很多）。
3、浮动垃圾。 CMS有两个阶段是可以用户线程和GC线程并发执行的，用户线程的继续执行自然会伴随垃圾的不断产生，这些就是浮动垃圾。这些垃圾只能等下次触发GC的时候才能清除了，也因为这些浮动垃圾的存在，CMS收集器需要留一手，JDK5的时候，在老年代内存空间使用了68%的时候就会触发一次GC，到了JDK6，觉得JDK5的这个设置太保守了，所以调整到了92%。
可以通过-XX:CMSInitiatingOccupancyFraction 调整这个阈值
Garbage First（G1）
G1 是 Garbage First 收集器的简称，它在JDK7的时候立项，JDK8 Update 40的时候才全部完工。这个收集器在JDK9 的时候成为了服务端模式下的默认垃圾收集器。
G1 收集器的设计理念是：实现一个停顿时间可控的低延迟垃圾收集器
G1 依然遵循分代回收的设计理论，但它对堆（Java Heap）内存进行了重新布局，不再是简单的按照新生代、老年代分成两个固定大小的区域了，而是把堆区划分成很多个大小相同的区域（Region），新、老年代也不再固定在某个区域了，每一个Region都可以根据运行情况的需要，扮演Eden、Survivor、老年代区域、或者Humongous区域。
大对象会被存储到Humongous区域，G1大多数情况下会把这个区域当作老年代来看待。如果对象占用空间超过Region的容量，就会存放到N个连续的 Humongous Region 中。
G1 收集器的内存空间结构
收集器的运行过程可以大致分成四个步骤：
初始标记（Initial Marking）- Stop Tow World
只标记 GC Roots 能直接关联的对象，还有一些额外的细节操作例如修改TAMS指针的值，保证后续阶段用户程序并发运行的时候，新对象分配在正确的位置。这个阶段需要暂停用户线程，但耗时很短。
并发标记（Concurrent Marking）- No Stop Tow World
从根节点（GC Root）开始，顺着引用链遍历整个堆，找出存活的对象。这个步骤耗时较长，但用户线程可以和GC线程并发执行。
最终标记（Final Marking）- Stop Tow World
处理并发标记阶段，用户线程继续运行产生的引用变动，这个阶段需要暂停用户线程，支持并行处理。
筛选回收（Live Data Counting and Evacuation）- Stop Tow World
根据以上三个阶段标记完成的数据，计算出各个Region的回收价值和成本，再根据用户期望的停顿时间来决定要回收多少个Region。回收使用的是复制算法，把需要回收的这些Region里存活的对象，复制到空闲的Region中，然后清理掉旧Region全部空间。因为需要移动存活的对象，所以不可避免的要暂停用户线程，这个步骤支持多条线程并行回收。
Q & A
设置停顿时间的参数是什么？
-XX:MaxGCPauseMillis 默认值是 200 毫秒
G1收集器是怎么保证停顿时间可控的？
首先G1把内存区域分成了若干个相同大小的 Region 区，在执行回收的时候，根据标记阶段统计到的数据，计算出各个 Region 区的回收价值和成本，有了这些数据之后，就可以计算出回收哪几个Region价值最高，且符合用户预期的停顿时间。