十三、垃圾回收篇——垃圾回收器
十三、垃圾回收篇——垃圾回收器
一、GC 分类
1、串行 vs 并行
按线程数分,可以分为串行垃圾回收器和并行垃圾回收器。
2、并发式 vs 独占式
按照工作模式分,可以分为并发式垃圾回收器和独占式垃圾回收器。
- 并发式垃圾回收器与应用程序线程交替工作,以尽可能减少应用程序的停顿时间。
- 独占式垃圾回收器( Stop the world)一旦运行,就停止应用程序中的其他所有线程,直到垃圾回收过程完全结束。
3、压缩式 vs 非压缩式
按碎片处理方式,可分为压缩式垃圾回收器和非压缩式垃圾回收器。
- 压缩式垃圾回收器会在回收完成后,对存活对象进行压缩整理,消除回收后的碎片。
- 非压缩式的垃圾回收器不进行这步操作。
4、年轻代 vs 老年代
按工作的内存区间,又可分为年轻代垃圾回收器和老年代垃圾回收器。
二、GC 评估指标
- (重点)吞吐量:程序的运行时间(程序的运行时间+内存回收的时间)。
- 垃圾收集开销:吞吐量的补数,垃圾收集器所占时间与总时间的比例。
- (重点)暂停时间:执行垃圾收集时,程序的工作线程被暂停的时间。
- 收集频率:相对于应用程序的执行,收集操作发生的频率。
- (重点)内存占用: Java 堆区所占的内存大小。
- 快速: 一个对象从诞生到被回收所经历的时间。
红色的三项共同构成一个“不可能三角”。三者总体的表现会随着技术进步而越来越好。一款优秀的收集器通常最多同时满足其中的两项。这三项里,低延迟的重要性日益凸显(暂停时间 -> 响应时间 -> 追求低延迟)。
1、面试题
- 请问吞吐量的优化和响应优先的垃圾收集器是如何选择的呢?
- 吞吐量优先选择什么垃圾回收器?响应时间优先呢?
2、吞吐量
比如:虚拟机总共运行了 100 分钟,其中垃圾收集花掉 1 分钟,那吞吐量就是 99%。
3、暂停时间
比如:GC 期间 100 毫秒的暂停时间意味着在这 100 毫秒期间内没有应用程序线程是活动的。
4、吞吐量 vs 暂停时间
1、 高吞吐量较好,因为这会让应用程序的最终用户感觉只有应用程序线程在做"生产性"工作直觉上,吞吐量越高程序运行越快;
2、 低暂停时间(低延迟)较好,因为从最终用户的角度来看不管是 GC 还是其他原因导致一个应用被挂起始终是不好的这取决于应用程序的类型,有时候甚至短暂的 20 毫秒暂停都可能打断终端用户体验因此,具有低的较大暂停时间是非常重要的,特别是对于一个交互式应用程序;
3、 不幸的是"高吞吐量"和"低暂停时间"是一对相互竞争的目标(矛盾);
- 如果选择以吞吐量优先,那么必然需要降低内存回收的执行频率,但是这样会导致一次 GC 需要更长的暂停时间来执行内存回收。
- 如果选择以低延迟优先,那么为了降低每次执行内存回收时的暂停时间,也只能频繁地执行内存回收,但这又引起了年轻代内存的缩减和导致程序吞吐量的下降。
现在标准:在最大吞吐量优先的情况下,降低暂停时间。
三、垃圾回收器都有哪些?
线程分类:
- 串行回收器: Serial、 Serial Old
- 并行回收器: ParNew、 Parallel Scavenge、Parallel Old
- 并发回收器:CMS、G1
分代分类:
- 新生代收集器: Serial、 ParNew、Parallel Scavenge
- 老年代收集器: Serial Old、Parallel old、CMS
- 整堆收集器:G1
1、面试题
- GC 收集器有哪些?
- 几种垃圾回收器
- 垃圾回收器有哪些?都有哪些算法来实现?项目中用的垃圾回收器是什么?
- 垃圾回收器的基本原理是什么?垃圾回收器可以马上回收内存吗?有什么办法主动通知虚拟机进行垃圾回收?
- 你知道那些垃圾回收器
- 有哪些垃圾方法,垃圾收集器是什么。
- JVM 有哪三种垃圾回收器?
2、为什么这么多 GC?
- 因为 Java 的使用场景很多,移动端,服务器等。所以就需要针对不同的场景,提供不同的垃圾收集器,提高垃圾收集的性能。
- 虽然我们会对各个收集器进行比较,但并非为了挑选一个最好的收集器出来。没有一种放之四海皆准、任何场景下都适用的完美收集器存在,更加没有万能的收集器。所以我们选择的只是对具体应用最合适的收集器。
3、如何查看默认 GC?
- -XX:+PrintCommandLineFlags:查看命令行相关参数(包含使用的垃圾收集器)
- 使用命令行指令:jinfo - flag 相关垃圾回收器参数进程 ID
4、Serial GC:串行回收

(1)概述
Serial 收集器作为 HotSpot 中 client 模式下的默认新生代垃圾收集器。
Serial 收集器采用复制算法、串行回收和"stop-the-World"机制的方式执行内存回收。
Serial 收集器还提供用于执行老年代垃圾收集的 Serial old 收集器。Serial old 收集器同样也采用了串行回收和"stop the World"机制,只不过内存回收算法使用的是标记-压缩算法。
Serial old 是运行在 Client 模式下默认的老年代的垃圾回收器。
Serial old 在 Server 模式下主要有两个用途:
- 与新生代的 Parallel scavenge 配合使用。
- 作为老年代 CMS 收集器的后备垃圾收集方案
(2)优势
- 简单而高效(与其他收集器的单线程比),对于限定单个 CPU 的环境来说,Serial 收集器由于没有线程交互的开销,专心做垃圾收集自然可以获得最高的单线程收集效率。
运行在 Client 模式下的虚拟机是个不错的选择。 - 在用户的桌面应用场景中,可用内存一般不大(几十 MB 至一两百 NB),可以在较短时间内完成垃圾收集(几十 ms 至一百多 ms),只要不频繁发生,使用串行回收器是可以接受的。
(3)参数
在 HotSpot 虚拟机中,使用 -XX:+UseSerialGC 参数可以指定年轻代和老年代都使用串行收集器。
(4)小结
1、 这种垃圾收集器大家了解,现在已经不用串行的了而且在限定单核 cpu 才可以用现在都不是单核的了;
2、 对于交互较强的应用而言,这种垃圾收集器是不能接受的一般在 Javaweb 应用程序中是不会采用串行垃圾收集器的;
5、ParNew GC:并行回收

(1)概述
- Par 是 Parallel 的缩写,New:只能处理的是新生代。
- ParNew 收集器则是 Serial 收集器的多线程版本。
- ParNew 收集器除了采用并行回收的方式执行内存回收外,两款垃圾收集器之间几乎没有任何区别。ParNew 收集器在年轻代中同样也是采用复制算法、"stop-the-World"机制。
- ParNew 是很多 JVM 运行在 Server 模式下新生代的默认垃圾收集器。
(2)ParNew GC 比 Serial GC 更高效?
- ParNew 收集器运行在多 CPU 的环境下,由于可以充分利用多 CPU、多核心等物理硬件资源优势,可以更快速地完成垃圾收集,提升程序的吞吐量。
- 但是在单个 CPU 的环境下,ParNew 收集器不比 Serial 收集器更高效。虽然 Serial 收集器是基于串行回收,但是由于 CPU 不需要频繁地做任务切换,因此可以有效避免多线程交互过程中产生的一些额外开销。
- 除 Serial 外,目前只有 ParNew GC 能与 CMS 收集器配合工作。
(3)参数
- 在程序中,开发人员可以通过选项"-XX:+UseParNewGC"手动指定使用 ParNew 收集器执行内存回收任务。它表示年轻代使用并行收集器,不影响老年代。
- -XX:ParallelGCThreads 限制线程数量,默认开启和 CPU 数据相同的线程数。
6、Parallel GC:吞吐量优先

(1)概述
Java8 的默认垃圾收集器。
Parallel GC 同样也采用了复制算法、并行回收和"Stop the World"机制。
Parallel 收集器在 JDK1.6 时提供了用于执行老年代垃圾收集的 Parallel old 收集器,用来代替老年代的 Serial old 收集器。采用了标记-压缩算法,但同样也是基于并行回收和"stop-the-World"机制。
那么 Parallel 收集器的出现是否多此一举?
和 ParNew 收集器不同,Parallel Scavenge 收集器的目标则是达到一个可控制的吞吐量(Throughput),它也被称为吞吐量优先的垃圾收集器。
自适应调节策略也是 Parallel Scavenge 与 ParNew 一个重要区别。
高吞吐量则可以高效率地利用 CPU 时间,尽快完成程序的运算任务,主要适合在后台运算而不需要太多交互的任务。因此,常见在服务器环境中使用。例如,那些执行批量处理、订单处理、工资支付、科学计算的应用程序。
(2)参数
- -XX:+UseParallelGC ,手动指定年轻代使用 Parallel 并行收集器执行内存回收任务。
- -XX:+UseParallelOldGC,手动指定老年代都是使用并行回收收集器。
- 分别适用于新生代和老年代。默认 jdk8 是开启的。
- 上面两个参数,默认开启一个,另一个也会被开启。(互相激活)
- -XX:ParallelGCThreads 设置年轻代并行收集器的线程数。一般地,最好与 CPU 数量相等,以避免过多的线程数影响垃圾收集性能。
- 当 CPU 数量小于 8 个,ParallelGCThreads 的值等于 CPU 数量。
- 当 CPU 数量大于 8 个,ParallelGCThreads 的值等于 3+[5*CPU_Count]/8]。
- -XX:MaxGCPauseMillis 设置垃圾收集器最大停顿时间(即 STW 的时间)。单位是毫秒。
- 为了尽可能地把停顿时间控制在 MaxGCPauseMills 以内,收集器在工作时会调整 Java 堆大小或者其他一些参数。
- 对于用户来讲,停顿时间越短体验越好。但是在服务器端,我们注重高并发,整体的吞吐量。所以服务器端适合 Parallel,进行控制。
- 该参数使用需谨慎。
- -XX:GCTimeRatio 垃圾收集时间占总时间的比例(= 1/ (N + 1))。用于衡量吞吐量的大小。
- 取值范围(0,100)。默认值 99,也就是垃圾回收时间不超过 1%。
- 与前一个-XX:MaxGCPauseMillis 参数有一定矛盾性。暂停时间越长,Radio 参数就容易超过设定的比例。
- -XX:+UseAdaptiveSizePolicy 设置 Parallel Scavenge 收集器具有自适应调节策略
- 在这种模式下,年轻代的大小、Eden 和 Survivor 的比例、晋升老年代的对象年龄等参数会被自动调整,已达到在堆大小、吞吐量和停顿时间之间的平衡点。使用 ParallelGC 的情况下,不管是否开启了 UseAdaptiveSizePoLicy 参数,默认 Eden 与 Survivor 的比例都为:6:1:1
- 在手动调优比较困难的场合,可以直接使用这种自适应的方式,仅指定虚拟机的最大堆、目标的吞吐量(GCTimeRatio)和停顿时间(MaxGCPauseMills),让虚拟机自己完成调优工作。
- 对于面向外部的大流量、低延迟系统,不建议启用此参数,建议关闭该参数。
7、CMS:低延迟

1、概述
在 JDK 1.5 时期,HotSpot 推出了一款在强交互应用中几乎可认为有划时代意义的垃圾收集器:CMS (Concurrent-Mark-Sweep)收集器,这款收集器是 HotSpot 虚拟机中第一款真正意义上的并发收集器,它第一次实现了让垃圾收集线程与用户线程同时工作。
CMS 收集器的关注点是尽可能缩短垃圾收集时用户线程的停顿时间。停顿时间越短(低延迟)就越适合与用户交互的程序,良好的响应速度能提升用户体验。
目前很大一部分的 Java 应用集中在互联网站或者 B/S 系统的服务端上,这类应用尤其重视服务的响应速度,希望系统停顿时间最短,以给用户带来较好的体验。CMS 收集器就非常符合这类应用的需求。
CMS 的垃圾收集算法采用标记-清除算法,并且也会”Stop-the-world”
在 G1 出现之前,CMS 使用还是非常广泛的。一直到今天,仍然有很多系统使用 CMS GC
2、收集过程
1、 初始标记:(会发生 STW)暂停时间非常短,标记与 GCRoots 直接关联的对象;
2、 并发标记:(最耗时)从 GCRoots 的直接关联对象开始遍历整个对象图的过程,可以与垃圾收集线程一起并发运行;
3、 重新标记:(会发生 STW)修复并发标记环节,因为用户线程的执行,导致数据的不一致性问题;
4、 并发清除:(最耗时)此阶段清理删除掉标记阶段判断的已经死亡的对象,释放内存空间由于不需要移动存活对象,所以这个阶段也是可以与用户线程同时并发的;
3、为什么不使用 Mark-Compact 标记-压缩?
因为当并发清除的时候,用 Compact 整理内存的话,原来的用户线程使用的内存还怎么用呢?要保证用户线程能继续执行,前提的它运行的资源不受影响。Mark-Compact 更适合“Stop the World”这种场景下使用
4、优缺点
优点:
- 并发收集
- 低延迟
弊端:
- 会产生内存碎片,导致并发清除后,用户线程可用的空间不足。在无法分配大对象的情况下,不得不提前触发 Full GC。
- CMS 收集器对 CPU 资源非常敏感。在并发阶段,它虽然不会导致用户停顿,但是会因为古用了一部分线程而导致应用程序变慢,总吞吐量会降低。
- CMS 收集器无法处理浮动垃圾。可能出现“Concurrent Mode Failure”失败而导致另一次 Full GC 的产生。在并发标记阶段由于程序的工作线程和垃圾收集线程是同时运行或者交叉运行的,那么在并发标记阶段如果产生新的垃圾对象,CMS 将无法对这些垃圾对象进行标记,最终会导致这些新产生的垃圾对象没有被及时回收,从而只能在下一次执行 GC 时释放这些之前未被回收的内存空间。
5、参数
-XX:+UseConcMarkSweepGC 手动指定使用 CMS 收集器执行内存回收任务。
开启该参数后会自动将-XX:+UseParNewGC 打开。即:ParNew(Young 区用)+CMS(Old 区用)+Serial old 的组合。
-XX:CMSlnitiatingOccupanyFraction,设置堆内存使用率的阈值,一旦达到该阈值,便开始进行回收。
JDK5 及以前版本的默认值为 68,即当老年代的空间使用率达到 68%时,会执行一次 CMS 回收。JDK6 及以上版本默认值为 92%。
如果内存增长缓慢,则可以设置一个稍大的值,大的阈值可以有效降低 CMS 的触发频率,减少老年代回收的次数可以较为明显地改善应用程序性能。反之,如果应用程序内存使用率增长很快,则应该降低这个阈值,以避免频繁触发老年代串行收集器。因此通过该选项便可以有效降低 Full GC 的执行次数。
-XX:+UseCMSCompactAtFullCollection,用于指定在执行完 Full GC 后对内存空间进行压缩整理,以此避免内存碎片的产生。不过由于内存压缩整理过程无法并发执行,所带来的问题就是停顿时间变得更长了。
-XX:CMSFullGCsBeforeCompaction,设置在执行多少次 Full GC 后对内存空间进行压缩整理。
6、小结
Serial GC、Parallel GC、CMS GC 这三个 GC 有什么不同呢?请记住以下口令:
- 如果你想要最小化地使用内存和并行开销,请选 Serial GC;
- 如果你想要最大化应用程序的吞吐量,请选 Parallel GC;
- 如果你想要最小化 GC 的中断或停顿时间,请选 CMS GC。
8、G1 GC:区域化分代式

1、为什么需要 G1?
- 为了适应现在不断扩大的内存和不断增加的处理器数量,进一步降低暂停时间(pause time),同时兼顾良好的吞吐量。
- 官方给 G1 设定的目标是在延迟可控的情况下获得尽可能高的吞吐量,所以才担当起“全功能收集器”的重任与期望。
2、为什么叫 G1(Garbage First)?
- 因为 G1 是一个并行回收器,它把堆内存分割为很多不相关的区域(Region)(物理上不连续的)。使用不同的 Region 来表示 Eden、幸存者 0 区,幸存者 1 区,老年代等。
- G1 GC 有计划地避免在整个 Java 堆中进行全区域的垃圾收集。G1 跟踪各个 Region 里面的垃圾堆积的价值大小(回收所获得的空间大小以及回收所需时间的经验值),在后台维护一个优先列表,每次根据允许的收集时间,优先回收价值最大的 Region。
- 由于这种方式的侧重点在于回收垃圾最大量的区间(Region),所以我们给 G1 一个名字:垃圾优先(Garbage First) 。
3、概述
- G1 是一款面向服务端应用的垃圾收集器,兼顾吞吐量和停顿时间的 GC 实现。
- 在 JDK1.7 版本正式启用,是 JDK9 以后的默认 GC 选项,取代了 CMS 回收器。
4、特点
与其他 GC 收集器相比,G1 使用了全新的分区算法,其特点如下所示:
(1)并行与并发
- 并行性:G1 在回收期间,可以有多个 GC 线程同时工作,有效利用多核计算能力。此时用户线程 STW
- 并发性:G1 拥有与应用程序交替执行的能力,部分工作可以和应用程序同时执行,因此,一般来说,不会在整个回收阶段发生完全阻塞应用程序的情况
(2)分代收集
- 从分代上看,G1 依然属于分代型垃圾回收器,它会区分年轻代和老年代,年轻代依然有 Eden 区和 Survivor 区。但从堆的结构上看,它不要求整个 Eden 区、年轻代或者老年代都是连续的,也不再坚持固定大小和固定数量。
- 将堆空间分为若干个区域( Region) ,这些区域中包含了逻辑上的年轻代和老年代。
- 和之前的各类回收器不同,它同时兼顾年轻代和老年代。对比其他回收器,或者工作在年轻代,或者工作在老年代
(3)空间整合
- CMS:“标记-清除”算法、内存碎片、若干次 GC 后进行一次碎片整理
- G1 将内存划分为一个个的 region。内存的回收是以 region 作为基本单位的。Region 之间是复制算法,但整体上实际可看作是标记-压缩(Mark-Compact)算法,两种算法都可以避免内存碎片。这种特性有利于程序长时间运行,分配大对象时不会因为无法找到连续内存空间而提前触发下一次 Gc。尤其是当 Java 堆非常大的时候,G1 的优势更加明显。
(4)可预测的停顿时间模型(即:软实时 soft real-time)
这是 G1 相对于 CMS 的另一大优势,G1 除了追求低停顿外,还能建立可预测的停顿时间模型,能让使用者明确指定在一个长度为 M 毫秒的时间片段内,消耗在垃圾收集上的时间不得超过 N 毫秒。
- 由于分区的原因,G1 可以只选取部分区域进行内存回收,这样缩小了回收的范围
- G1 跟踪各个 Region 里面的垃圾堆积的价值大小(回收所获得的空间大小以及回收所需时间的经验值),在后台维护一个优先列表,每次根据允许的收集时间,优先回收价值最大的 Region。保证了 G1 收集器在有限的时间内可以获取尽可能高的收集效率。
- 相比于 CMS GC,G1 未必能做到 CMS 在最好情况下的延时停顿,但是最差情况要好很多。
5、缺点
- 相较于 CMS,G1 还不具备全方位、压倒性优势。比如在用户程序运行过程中,G1 无论是为了垃圾收集产生的内存占用(Footprint)还是程序运行时的额外执行负载(Overload)都要比 CMS 要高。
- 从经验上来说,在小内存应用上 CMS 的表现大概率会优于 G1,而 G1 在大内存应用上则发挥其优势。平衡点在 6-8GB 之间。
6、参数
- -XX:+UseG1GC,手动指定使用 G1 收集器执行内存回收任务。
- -XX:G1HeapRegionSize,设置每个 Region 的大小。值是 2 的幂,范围是 1MB 到 32MB 之间,目标是根据最小的 Java 堆大小划分出约 2048 个区域。默认是堆内存的 1/2000。
- -XX:MaxGCPauseMillis,设置期望达到的最大 GC 停顿时间指标(JVM 会尽力实现,但不保证达到)。默认值是 200ms
- -XX:ParallelGCThread,设置 STW 时 GC 线程数的值。最多设置为 8
- -XX:ConcGCThreads,设置并发标记的线程数。将 n 设置为并行垃圾回收线程数(ParallelGCThreads)的 1/4 左右。
- -XX:InitiatingHeapOccupancyPercent,设置触发并发 GC 周期的 Java 堆占用率阈值。超过此值,就触发 GC。默认值是 45。
7、操作步骤
第一步:开启 G1 垃圾收集器
第二步:设置堆的最大内存
第三步:设置最大的停顿时间
G1 中提供了三种垃圾回收模式: YoungGC、Mixed GC 和 Full GC,在不同的条件下被触发。
8、适用场景
- 面向服务端应用,针对具有大内存、多处理器的机器。(在普通大小的堆里表现并不惊喜)
- 在下面的情况时,使用 G1 可能比 CMS 好:
1、 超过 50%的 Java 堆被活动数据占用;
2、 对象分配频率或年代提升频率变化很大;;
3、 GC 停顿时间过长(长于 0.5 至 1 秒);
- HotSpot 垃圾收集器里,除了 G1 以外,其他的垃圾收集器使用内置的 JVM 线程执行 GC 的多线程操作,而 G1 GC 可以采用应用线程承担后台运行的 GC 工作,即当 JVM 的 GC 线程处理速度慢时,系统会调用应用程序线程帮助加速垃圾回收过程。
9、分区 Region
- 使用 G1 收集器时,它将整个 Java 堆划分成约 2048 个大小相同的独立 Region 块,每个 Region 块大小根据堆空间的实际大小而定,整体被控制在 1MB 到 32NB 之间,且为 2 的 N 次幂,即 1MB,2MB,4MB,8MB,16MB,32MB。可以通过-XX:61HeapRegionSize 设定。所有的 Region 大小相同,且在 VM 生命周期内不会被改变。
- G1 垃圾收集器还增加了一种新的内存区域,叫做 Humongous 内存区域,如图中的 H 块。主要用于存储大对象,如果超过 1.5 个 region,就放到 H。
设置 H 的原因:
对于堆中的大对象,默认直接会被分配到老年代,但是如果它是一个短期存在的大对象,就会对垃圾收集器造成负面影响。为了解决这个问题,G1 划分了一个 Humongous 区,它用来专门存放大对象。如果一个 H 区装不下一个大对象,那么 G1 会寻找连续的 H 区来存储。为了能找到连续的 H 区,有时候不得不启动 Full GC。G1 的大多数行为都把 H 区作为老年代的一部分来看待。
10、垃圾回收过程
过程 1:年轻代 GC
过程 2:并发标记过程
过程 3:混合回收
过程 4:FullGC
11、G1 优化建议
年轻代大小:
- 避免使用-Xmn 或-XX:NewRatio 等相关选项显式设置年轻代大小。
- 固定年轻代的大小会覆盖。
暂停时间目标暂停时间目标不要太过严苛:
- G1 GC 的吞吐量目标是 90%的应用程序时间和 10%的垃圾回收时间。
- 评估 G1 GC 的吞吐量时,暂停时间目标不要太严苛。目标太过严苛表示你愿意承受更多的垃圾回收开销,而这些会直接影响到吞吐量。
四、各 GC 使用场景
垃圾收集器 | 分类 | 作用位置 | 算法 | 特点 | 适用场景 |
Serial | 串行运行 | 新生代 | 复制算法 | 响应速度优先 | 适用于单CPU环境下的client模式 |
ParNew | 并行运行 | 新生代 | 复制算法 | 响应速度优先 | 多CPU环境Server模式下与CMS配合使用 |
Parallel | 并行运行 | 新生代 | 复制算法 | 吞吐量优先 | 适用于后台运算而不需要太多交互的场景 |
Serial Old | 串行运行 | 老年代 | 标记-压缩算法 | 响应速度优先 | 适用于单CPU环境下的Client模式 |
Parallel Old | 并行运行 | 老年代 | 标记-压缩算法 | 吞吐量优先 | 适用于后台运算而不需要太多交互的场景 |
CMS | 并发运行 | 老年代 | 标记-清除算法 | 响应速度优先 | 适用于互联网或B/S业务 |
G1 | 并发、并行运行 | 新生代 + 老年代 | 标记-压缩算法、复制算法 | 响应速度优先 | 面向服务端应用 |
五、如何选择?
- 优先调整堆的大小让 JVM 自适应完成。如果内存小于 100M,使用串行收集器
- 如果是单核、单机程序,并且没有停顿时间的要求,串行收集器
- 如果是多 CPU、需要高吞吐量、允许停顿时间超过 1 秒,选择并行收集器
- 如果是多 CPU、追求低停顿时间,需快速响应(比如延迟不能超过 1 秒,如互联网应用),使用并发收集器
- 官方推荐 G1,性能高。现在互联网的项目,基本都是使用 G1。
六、GC 日志分析
1、日志参数
- -verbose:gc,输出 gc 日志信息,默认输出到标准输出
- -XX:+PrintGC,输出 GC 日志。类似: -verbose:gc
- -XX:+PrintGCDetails,在发生垃圾回收时打印内存回收详细的日志,并在进程退出时输出当前内存各区域分配情况
- -XX:+PrintGCTimeStamps,输出 GC 发生时的时间戳
- -XX:+PrintGCDateStamps,输出 GC 发生时的时间戳(以日期的形式,如 2013-05-04T21:53:59.234+0800)
- -XX:+PrintHeapAtGC,每一次 GC 前和 GC 后,都打印堆信息
- -Xloggc:
<file>
表示把 GC 日志写入到一个文件中去,而不是打印到标准输出中
2、日志分析网站
https://gceasy.io/