JVM 垃圾回收器

GC 分类与性能指标

垃圾收集器概述:

• 垃圾收集器没有规范中进行过多的规定，可以由不同的厂商、不同版本的 JVM 来实现
• 由于 JDK 的版本处于高速迭代过程中，因此 Java 发展至今已经衍生了众多的 GC 版本
• 从不同角度分析垃圾收集器，可以将 GC 分为不同的类型

垃圾回收分类:

• 按线程数分，可以分为串行垃圾回收器和并行垃圾回收器。

•  按工作模式分，可以分为并发垃圾回收器和独占式垃圾回收器

• 按碎片处理方式分，可以分为压缩式垃圾回收器和非压缩式垃圾回收器
• 按工作的内存区间分，又可分为年轻代垃圾回收器和年老代垃圾回收器 

评估 GC 的性能指标:

• 吞吐量: 运行用户代码的时间占总运行时间的比例(总时间: 程序运行时间 + 内存回收的时间)
• 垃圾收集开销: 吞吐量的补数，垃圾收集所用的时间与总运行时间的比例
• 暂停时间: 执行垃圾收集时，程序的工作线程被暂停的时间
• 收集频率: 相对于应用程序的执行，收集操作发生的频率
• 内存占比: Java 堆区所占的内存大小
• 快速: 一个对象从诞生到被回收所经历的时间

吞吐量:

• 吞吐量就是 CPU 用于运行用户代码的时间与CPU总消耗时间的比值，即吞吐量=运行用户代码时间 / (运行用户代码时间 + 垃圾收集时间)
• 应用程序能容忍较高的暂停时间，因此，高吞吐量的应用程序有更长的时间基准，快速响应是不必考虑的
• 吞吐量优先，意味着单位时间内，STW的时间最短

暂停时间:

• 一个是按段内应用程序线程暂停，让GC线程执行的状态
• 暂停时间优先，意味着尽可能让单次 STW 的时间最短

吞吐量 VS 暂停时间:

• 高吞吐量较好因为这会让应用程序的最终用户感觉只有应用程序线程在 "生产性工作"，直觉上，吞吐量越高程序运行越快
• 低暂停时间(低延迟)较好因为最终用户的角度来看是GC还是其他原因导致一个应用被挂起始终是不好的。在交互式应用程序中，具有较低暂停时间非常重要
• 在设计 GC 算法时，我们必须确定目标:一个GC算法只可能针对两个目标之一或者进行折衷
• 现在标准: 在最大吞吐量优先的情况下，降低停顿时间

不同的垃圾回收器概述

7款经典的垃圾收集器:

• 串行回收器: Serial、Serrial Old
• 并行回收器: ParNew、Parallel Scavenge、Parallel Old
• 并发回收器: CMS、G1

收集器和垃圾分代之间的关系:

• 新生代收集器: Serial、ParNew、Parallel Scavenge
• 老年代收集器: Serial Old、Parallel Old、CMS
• 整堆收集器: G1

垃圾收集器的组合关系:

没有一种放之四海皆准、任何场景下都适合的完美收集器存在，更加没有万能的收集器，我们选择只是对具体应用最合适的收集器

查看默认的垃圾收集器:

• -XX:+PrintCommandLineFlags: 查看命令行相关参数(包含使用的垃圾收集器)
• 使用命令行指令: jinfo -flag 相关垃圾回收器参数的进程

Serial 回收器: 串行回收

• Serial 收集器是最基本、历史最悠久的垃圾收集器。JDK1.3 之前回收新生代唯一的选择
• Serial 收集器作为 HotSpot 中 Client 模式下的默认新生代垃圾收集器
• Serial 收集器采用复制算法、串行回收和 "Stop-the-World" 机制的方式执行内存回收
• Serial Old 收集器同样采用了串行回收和 ”Stop the World“ 机制，只不过内存回收算法使用的是标记-压缩算法。Serial Old 是运行在Client 模式下的默认老年代的垃圾回收。Serial Old 在 Server 模式下主要有两个用途，与新生代的 Parallel Scavenge 配合使用，作为老年代 CMS 收集器的后备垃圾收集方案
• 这个收集器是一个单线程的收集器，但它的单线程的意义并不仅仅说明它只会一个 CPU 或一条收集线程去完成垃圾收集工作，更重要的是在它进行垃圾收集时，必须暂停其他所有的工作线程，直至它收集结束(Stop The World)
• 使用 -XX:+UseSerialGC 参数可以指定年轻代和老年代都使用串行收集器

优势:

简单而高效(与其他收集器的单线程比)，对于限定单个 CPU 的环境来说， Serial 收集器由于没有线程交互的开销，专心做垃圾收集自然可以获得最高的单线程收集效率

ParNew 回收器: 并行回收

• Serial 收集的多线程版本
• ParNew 收集器在年轻代中同样采用复制算法、"Stop-the-World" 机制
• ParNew 是很多JVM 运行在 Server 模式下新生代的默认垃圾收集器
• ParNew 收集器在多 CPU 环境下，由于充分利用多 CPU，可以更快速的完成垃圾收集，在单 CPU 的环境下，ParNew 收集器不比 Serial 收集器更高效
• 使用 "-XX:+UseParNewGC" 手动指定使用 ParNew 收集器执行内存回收任务
• "-XX:ParallelGCThreads" 限制线程数量，默认开启和 CPU 数量相同的线程数

Parallel 回收器: 吞吐量优先

• 同样采用复制算法、并行回收 和 "Stop the World" 机制
• 和 ParNew 收集器不同， Parallel Scavenge 收集器的目标是达到一个可控制的吞吐量(Throughput)，它也被称为吞吐量优先的垃圾收集器
• 自适应调剂策略也是 Parallel Scavenge 与 ParNew 的一个重要区别
• 高吞吐量则可以高效地利用 CPU 时间，尽快完成程序的运算任务，主要适合在后台运算而不需要太多交互的任务。因此常在服务器环境使用。例如，那些执行批量处理、订单处理、工资支付、科学计算的应用程序。
• jdk 1.6 时提供了用于执行老年代垃圾收集的 Paralled Old 收集器，用来替代老年代的 Serial Old 收集器
• Paralled Old 收集器采用了标记-压缩算法，但同样也是基于并行回收和 "Stop-the-world" 机制
• jdk8的默认收集器

参数设置:

• -XX:+UseParallelGC: 手动指定年轻代使用 Parallel 并行收集器执行内存回收任务
• -XX:+UseParallelOldGC: 手动指定老年代是并行收集器(与上面配置相互激活)
• -XX:+ParallelGCThreads: 设置年轻代并行收集器的线程数,默认情况下，当CPU 小于8个，ParallelGCThreads 的值等于 CPU 数量， 当CPU数量大于8个, ParallelGCThreads 的值等于 3 + [5 * CPU_Count] / 8
• -XX:MaxGCPauseMillis: 设置垃圾收集器最大停顿时间(即 STW 的时间)，单位是毫秒。为了尽可能地把停顿时间控制在 MaxGCPauseMills 以内，收集器在工作时会调整 Java 堆大小或者其他一些参数。参数使用需要谨慎
• -XX:GCTimeRatio: 垃圾收集时间占总时间的比例(=1/(N+1)) 用来衡量吞吐量的大小，取值范围是(0,100),默认值99。
• -XX:+UseAdaptiveSizePolicy: 设置 Parallel Scavenage 收集器的自动调节策略，这种模式下年轻代的大小、Eden和Survivor 的比例、晋升老年代的对象年龄参数会自动调整，已达到在堆大小、吞吐量和停顿时间之间的平衡点。

CMS 回收器: 低延迟

• CMS(Concurrent-Mark-Sweep)收集器，是HotSpot 虚拟机中第一款真正意义上的并发收集器，它第一次实现了让垃圾收集线程与用户线程同时工作。
• CMS 收集器的关注点是尽可能缩短垃圾收集时用户线程的停顿时间。停顿时间越短(低延迟) 就越适合与用户交互的程序，良好的响应速度能提升用户体验
• CMS 的垃圾收集算法采用标记-清除算法，并且也会 "Stop-the-world"
• 无法与新生代收集器 Parallel Scavenge 配合工作，只能选择ParNew 或者 Serial 收集器中i一个

工作原理:

• 初始标记(Initial-Mark) 阶段: 在这个阶段中，程序中所有的工作线程都将会因为 "Stop-the-World" 机制而出现短暂的暂停，这个阶段的主要任务仅仅只是标记出 GC Roots 能直接关联到的对象。一旦标记完成之后就会恢复之前被暂停的所有应用线程。由于直接关联对象比较小，所以这里速度非常快
• 并发标记(Concurrent-Mark) 阶段: 从 GC Roots 的直接关联对象开始遍历整个对象图的过程，这个过程耗时较长但是不需要停顿用户线程，可以与垃圾收集线程一起并发运行
• 重新标记(Remark) 阶段: 由于在并发标记阶段中，程序的工作线程会和垃圾收集线程同时运行或者交叉运行，因此为了修正并发标记期间，因用户线程继续运作而导致标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间通常会比初始标记阶段稍长一些，但也远比并发标记极端的时间短
• 并发清除(Concurrent-Sweep) 阶段: 此阶段清理删除掉标记阶段判断已经死亡的对象，释放内存空间。由于不需要移动存活对象，所以这个阶段也可以与用户线程同时并发的

特点:

• 由于在垃圾收集阶段用户线程没有中断，所以在CMS 回收过程中，还应该确保应用程序用户线程有足够的内存可用。因此，CMS 当堆内存使用率达到一定阈值时，便开始进行回收，以确保应用程序在 CMS 工作过程中依然有足够的空间支持应用程序运行。要是 CMS 运行期间预留的内存无法满足程序需要，就会出现一次 "Concurrent Mode Failure" 失败，这时虚拟机将启动后备预案: 临时启用 Serial Old 收集器来重新进行老年代的垃圾收集，这样停顿时间就很长了
• CMS 收集的垃圾收集算法采用的是标记-清除算法，这就意味着每次执行完内存回收后，由于执行内存回收的无用对象所占用的内存空间极有可能是不连续的一些内存块，不可避免地将会产生一些内存碎片。只能采用选择空闲列表(Free List) 执行内存分配

为何不用标记-压缩算法:

要保证用户线程能继续执行

CMS 的优点:

• 并发收集
• 低延迟

CMS 的弊端:

• 会产生内存碎片: 导致并发消除后，用户线程可用的空间不足。在无法分配大对象的情况下，不得不提前触发 Full GC
• CMS 收集器对 CPU 资源非常敏感: 在并发阶段，它虽然不会导致用户停顿，但是会因为占用一部分线程而导致应用程序变慢，总吞吐量会降低
• CMS 收集器无法处理浮动垃圾: 由于是交叉运行的， 那么在并发标记阶段如果产生新的垃圾对象，CMS 将无法对这些垃圾对象进行标记，最终会导致这些新产生的垃圾对象没有被即时回收，从而只能在下一次执行GC时释放这些之前未被回收的内存空间

常用参数设置:

• -XX:+UseConcMarkSweepGC: 手动指定使用 CMS 收集器执行内存回收任务，同时自动开启 ParNew 垃圾收集器。即: ParNew(Yong 区) + CMS(Old 区) + Serial Old 的组合
• -XX:+cmsInitiatingOccupanyFraction: 设置堆内存使用率的阈值，一旦达到该阈值，便开始进行回收
• -XX:+UseCMSCompacAtFullCollection: 用于指定执行完 Full GC 后对内存进行压缩整理，以此避免内存碎片的产生。不过由于内存压缩整理过程无法并发执行，所带来的问题就是停顿时间变得更长
• -XX:CMSFullGCsBeforeCompaction: 设置在执行多次 Full GC 后对内存空间进行压缩整理
• -XX:ParallelCMSThreads: 设置 CMS 的线程数量，默认是 (ParallelGCThreads + 3) / 4

G1 回收器: 区域化分代式

为什么发布 G1:

• 业务越来越庞大、复杂、用户越来越多
• 不断扩大的内存和不断增加的处理器数量，进一步降低暂停时间(pause time)
• 设定的目标是延迟可控的情况下，获得尽可能高的吞吐量，所以才担任起 "全功能收集器"的重任与期望

为什么叫 Garbage First (G1):

• G1 是一个并行回收器，它把堆内存分割为很多不同的区域(region)。使用不同的Region 来标识 Eden、幸存者0区、幸存者1区、老年代等
• G1 GC 有计划地避免在整个 Java 堆中进行全区域的垃圾收集。G1 根据各个 Region 里面的垃圾堆积的价值大小( 回收所获得的空间大小以及回收所需时间的经验值)，在后台维护一个优先列表，每次根据允许的收集时间，优先回收价值最大的 Region
• 由于这种方式的侧重点在于回收垃圾最大量的区间(Region), 所以我们给 G1 一个名字: 垃圾优先 (Garbage First)

G1区域分代化概述:

• 是一款面向服务端应用的垃圾收集器，主要针对配备多核 CPU 及大容量内存的机器，以极高概率满足 GC 停顿时间的同时，还兼具吞吐量的性能特征
• Jdk1.7 移除 Experimental 的标识，是 jdk 9 的默认垃圾回收器。 取代了 CMS 回收器以及 Parallel + Parallel Old 组合
• jdk 需要 -XX:+UseG1GC 来指定

G1 回收器的特点:

• 并发与并行

并发性: G1在回收期间，可以有多个 GC 线程同时工作，有效利用多核计算能力。此时用户线程 STW 

并发性: G1 拥有与应用程序交替执行的能力，部分工作可以和应用程序同时执行，因此，一般来说，不会在整个回收阶段发生完全阻塞应用程序的情况

• 分代收集

从分代上看，G1依然属于分代型垃圾回收器，它会区分年轻代和年老代，年轻代依然有Eden区和Survivor 区。但是从堆的结构上看，它不要求整个 Eden 区、年轻代或者老年代都是连续的，也不再坚持固定大小和固定数量

将堆空间分为若干个区域(Region)，这些区域中包含了逻辑上的年轻代和老年代

和之前的各类回收器不同，它同时兼顾年轻代和老年代。对比其他回收器，或者工作在年轻代，或者工作在老年代

• 空间整合

G1 将内存划分为一个个 Region。内存的回收是以 region 作为基本单位的。 Region 之间是复制算法，但整体上可看作是标记-压缩(Mark-Compact) 算法，两种算法都可以避免内存碎片。这种特性有利于程序长时间运行，分配大对象时不会因为无法找到连续内存空间而提前触下一次 GC。尤其是当 Java 堆非常大的时候，G1 的优势更加明显

 可预测的停顿时间模型(即:软实时 soft real-time)

这时 G1 相对于 CMS 的另一大优势，G1 除了追求低停顿外，还能建立可预测的停顿时间模型，能让使用者明确指定在一个长度为 M 毫秒的时间片段内，消耗在垃圾收集的时间不超过 N 毫秒

• 由于 分区的原因，G1 可以只选取部分区域进行内存回收，这样缩小了回收的范围，因此对于全局停顿的情况的发生也能得到较好的控制
• G1 跟踪各个 Region 里面的垃圾堆积的价值大小，在后台维护一个优先列表，每次根据允许的收集时间，优先回收价值最大的 Region。保证了 G1 收集器在有限的时间内可以获取尽可能高的收集效率
• 相对于 CMS GC，G1 未必能做到 CMS 在最好情况下的延时停顿，但是最差情况要好很多

G1 回收器的缺点:

• 用户程序运行过程中，G1 无论是为了垃圾收集产生的内存占用(Footprint) 还是程序运行时的额外执行负载(Overload) 都要比 CMS 要高
• 小内存应用上 CMS 的表现大概率会优于 G1，而 G1 在大内存应用上则发挥其优势。 

G1 回收器的参数设置:

• -XX:+UseG1GC: 手动指定使用 G1 收集器执行内存回收任务
• -XX:G1HeapRegionSize: 设置每个Region 的大小。值是2的幂，返回是 1MB 到 32MB之间
• -XX:MaxGCPauseMillis: 设置期望达到的最大 GC 停顿时间指标( JVM 会尽力实现，但不保证达到)。默认值是 200 ms
• -XX:ParallelGCThread: 设置 STW 工作线程数的值。最多设置 8
• -XX:ConcGCThreads: 设置并发标记的线程数。将 n 设置为并行垃圾回收线程数(ParallelGCThreads) 的 1/4 左右
• -XX:InitiatingHeapOccupancyPercent: 设置触发并发 GC 周期的 Java 堆占用率阈值。超过此值，就触发GC。默认值是45

G1 回收器的使用场景:

• 面向服务端应用，针对具有大内存、多处理器的机器(在普通大小的堆里表现并不惊喜)
• 最主要的应用是需要低GC 延迟，并具有大堆的应用程序提供解决方案
• 用来替换 JDK 1.5 中的 CMS 收集器，超过 50% 的 Java 堆被活动数据占用，对象分配频率或年代提升频率变化很大，GC 停顿时间过长
• JVM 的 GC 线程处理速度慢时，系统会调用应用程序线程帮助加速垃圾回收过程

设置 H的原因:

对于 堆中的大对象，默认直接会分配到老年代，但是如果一个短期存在的大对象，就会堆垃圾收集器造成负面影响。为了解决这个问题，G1 划分了一个 Humogous 区，它是用来专门存放大对象。如果一个 H区装不下一个大对象，那么 G1 会寻找连续的 H区来存储。为了能找到连续的 H区，有时候不得不启动 Full GC。G1 的大多数行为都把 H区作为老年代的一部分来看待

G1 回收器垃圾回收过程:

• 应用程序分配内存，当年轻代的 Eden 区用尽时开始年轻代回收过程; G1 的年轻代收集阶段是一个并行的独占式收集器。在年轻代回收期， G1 GC 暂停所有应用程序线程，启动多线程执行年轻代回收。然后从年轻代区间移动存活对象到 Survivor 区间或者老年区间，也有可能是两个区间都会涉及
• 当堆内存使用达到一定值(默认 45%)时，开始老年代并发标记过程
• 标记完成后马上开始混合回收过程。对于一个混合回收期，G1 GC 从老年区间移动存活对象到空闲区间，这些空闲区间也就成为了老年代的一部分。和年轻代不同，老年代的 G1 回收器和其他 GC 不同，G1 的老年代回收期不需要整个老年代回收，以此只需要扫描 / 回收一部分老年代的 Region 就可以了。同时，这个老年代 Region 是和年轻代一起被回收的

记忆集(Remebered Set)：

一个对象被不同区域引用的问题，一个 Region 不可能是孤立的， 一个 Region 中的对象可能被其他任意 Region 中对象引用，判断对象存活时，是否需要扫描整个 Java 堆才能保证准确？

解决方法:

• 无论 G1 还是其他分代收集器， JVM 都是使用了 Remembered Set 来避免全局扫描
• 每个 Region 都有一个对应的 Remembered Set
• 每次 Reference 类型数据写操作时，都会产生一个 Write Barrier 暂停中断操作
• 然后检查将要写入的引用指向的对象是否和该 Reference 类型数据在不同一个 Region(其他收集器: 检查老年代对象是否引用了新生代对象)
• 如果不同，通过 CardTable 把相关引用信息记录指向对象的所在 Region 对应的 Remembered Set中
• 当进行垃圾收集时，在GC 根节点的枚举范围加入 Remembered Set，就可以保证不进行全局扫描，也不会有遗漏

G1 回收过程: 年轻代 GC

• JVM 启动时，G1 先准备好 Eden 区，程序在运行过程中不断创建对象到 Eden 区，当 Eden 空间耗尽时， G1 会启动一次年轻代垃圾回收过程
• 年轻代垃圾回收只会回收 Eden 区 和 Survivor 区
• YGC 时，首先 G1 停止应用程序的执行(Stop-The-World)，G1 创建回收集(Collection Set)，回收集是指需要被回收的内存分段的集合，年轻代回收过程的回收集包括年轻代 Eden 区 和 Survivor 区所有的内存分段

回收过程:

• 第一阶段 - 扫描根: 根是指 static 变量指向的对象，正在执行的方法调用链条上的局部变量等。根引用连同 Rset 记录的外部引用作为扫描存活对象的入口
• 第二阶段 - 更新 Rset: 处理 dirty card queue (保存了对象引用信息，减少直接同步 Rset 的资源耗费)中的 card，更新 RSet。此阶段完成后，RSet 可以准确的反应老年代对所在内存分段中的对象引用
• 第三阶段 - 处理 Rset: 识别被老年代对象指向 Eden 中的对象，这些被指向的 Eden 中的对象被认为是存活的对象
• 第四阶段 - 复制对象: 此阶段，对象树被遍历，Eden 区内存段中存活的对象会被复制到 Survivor 区中的空的内存分段，Survivor 区中内存段中存活的对象如果年龄未达到阈值，年龄会加1，达到阈值会被复制到 Old 区中空的内存分段。如果 Survivor 空间不够， Eden 空间的部分数据会直接晋升到老年代空间
• 第五阶段 - 处理引用: 处理 Soft, Weak, Phantom, Final, JNI Weak 等引用。最终 Eden 空间的数据为空，GC 停止工作，而目标内存中的对象都是连续存储的，没有碎片，所以复制过程可以达到内存整理的效果，减少碎片

G1 回收过程: 并发标记过程

• 初始标记阶段: 标记从根节点直接可达的对象。这个阶段是 STW 的，并且会触发一次年轻代 GC
• 根区域扫描(Root Region Scanning): G1 GC 扫描 Survivor 区直接可达的老年代区域对象，并标记被引用的对象。这一过程必须在 YGC 之前完成
• 并发标记(Cocurrent Marking): 在整个堆中进行并发标记(和应用程序并发执行)，此过程可能被 YGC 中断。在并发标记阶段，若发现区域对象中的所有对象都是垃圾，那这个区域会被立即回收。同时，并发标记过程中，会计算每个区域的对象活性(区域中存活对象的比例)
• 再次标记(Remark): 由于应用程序持续进行，需要修正上一次标记结果。是STW的，G1 采用了比 CMS 更快的初始快照算法: snapshot-at-the-begining(SATB)
• 独占清理(cleanup, STW): 计算各个区域的存活对象和 GC 回收比例，并进行排序，识别可以混合回收的区域。这个阶段并不会实际上去做垃圾收集
• 并发清理阶段: 识别并清理完全空闲的区域

G1 回收过程: 混合回收

当越来越多的对象晋升到老年代 old region 时，为了避免堆内存被耗尽，虚拟机会触发一个混合的垃圾收集器，即 Mixed GC, 该算法并不是一个 Old GC，除了回收整个 Young Region，还会回收一部分的 Old Region。可以选择哪些 Old Region 进行收集，从而可以对垃圾回收的耗时时间进行控制。

• 并发标记结束后，老年代中百分之百为垃圾的内存分段被回收了，部分为垃圾的内存分段被计算出来。默认情况下，这些老年代的内存分段会分8次(可以通过-XX:G1MixedGCCountTarget 设置)被回收
• 混合回收的回收集(Collection Set)包括八分之以的老年代内存分段，Eden区内存分段，Survivor 区内存分段。混合回收的算法和年轻代回收的算法完全一样，只是回收集多了老年代的内存分段。
• 由于老年代的内存分段默认分 8 次回收，G1 会优先回收垃圾多的内存分段。默认占内存分段比例越高的，越会被回收。并且有一个阈值会决定内存分段是否被回收，-XX:G1MixedGCLiveThresholdPercent， 默认为 65%。意思是垃圾内存分段比例要达到 65% 才会被回收。如果垃圾占比太低，意味着存活的对象占比高，在复制的时候会花费更多的时间
• 混合回收并不一定要进行 8 次。有一个阈值 -XX:G1HeapWastePercent, 默认值为 10%，意思是允许堆内存中有 10% 的空间被浪费，意味着如果发现可以回收的垃圾占堆内存的比例低于 10%，不再进行混合回收。因为 GC 会花费很多的时间但回收到内存却很少

G1 回收可选的过程: Full GC

G1 的初衷是要避免 Full GC 的出现。但是如果上述方式不能正常工作，G1 会停止应用程序执行(Stop-The-World)， 使用单线程的内存回收算法进行垃圾回收，性能会非常差，应用程序停顿时间会很长

原因:

• Evacation 的时候没有足够的 to- space 来存放晋升的对象
• 并发处理过程完成之前空间耗尽

G1 回收期优化建议:

• 年轻代大小: 避免使用-Xmn 或者 -XX:newRatio 等相关选项显示设置年轻代大小，固定年轻代的大小会覆盖暂停时间目标
• 暂停时间目标不要太苛刻: G1 GC 吞吐量目标是 90% 的应用程序时间和 10% 的垃圾回收时间， 目标太过苛刻表示你愿意承受更多的垃圾回收开销，而这些会直接影响到吞吐量

垃圾回收器总结

GC 日志分析

内存分配与垃圾回收的参数列表:

参数	说明
-XX:+PrintGC	输出GC 日志。类似: -verbose:gc
-XX:+PrintGCDetails	输出 GC 的详细日志
-XX:+PrintGCTimeStamps	输出 GC 的时间戳 (以基准时间的形式)
-XX:+PrintGCDataStamps	输出 GC 的时间戳 (以日期的形式)
-XX:+PrintHeapAtGC	在进行 GC 的前后打印出堆的信息
-Xloggc:../log/gc.log	日志文件的输出路径

日志分析工具:

GCEasy,GCViewer