技术

截止到目前，算上ZGC，Java一共有九种类型的GC，它们分别是： 1、Serial GC 串行/作用于新生代/复制算法/响应速度优先/适用于单CPU下的client模式 2、ParNew GC...

在互联网大厂中，对每天亿级流量的日志进行清洗、整理是非常常见的工作。在某个系统中，需要对用户的访问日志做脱敏处理，也就是清洗掉姓名、身份证号、手机号等个人隐私信息后在保存到数据库中或者交付给其他应用使

除了Tomcat、Jetty，另一个常见的可能出现OOM的地方就是微服务架构下的一次RPC调用过程中。笔者曾经经历过的一次OOM就是基于Thrift框架封装出来的一个RPC框架导致的宕机。

前面说了一般应用的OOM情况，但是OOM不知发生在应用层，有时候专门负责运行Java的Tomcat也会偶尔罢工一下，抛出OOM异常。因为Tomcat本身也是一个JVM进程。

某新手开发工程师接到了一个保存Elasticsearch日志的任务，以供后续分析之用。但写代码的时候，误将保存日志的代码段弄成了无限循环，程序启动后，没用多久就崩溃了。

接昨天的问题继续来说，在高并发场景中，对象过多容易导致OOM。由于高并发导致Young GC存活对象过多，因此会有太多对象进入老年代，导致老年代也被填满，频繁触发Full GC。

生产环境中，最常见的一种案例就是OOM，也叫「内存溢出」，它表示JVM已经无法支撑业务系统的运行。而很多工程师都没有类似处理线上系统故障的经验，尤其是这种突发的故障。

GC的概念并不难明白，而且它的原理也不复杂，但是很难用好。为什么？因为每个平台、架构、指标、运行环境都不一样，甚至（新手）工程师的编码习惯都不一样，随手的一段代码可能就给运维优化带来巨大压力。

一般新手工程师在部署生产环境时基本不会对JVM进行设置，基本跟上也都是使用JVM的默认设置，这是一个很大的隐患。例如，如果不设置-Xmx或者-Xms的话，可能初始的年轻代和老年代就几百M大小。

线上系统的JVM监测要么使用jstat、jmap、jhat等工具查看JVM状态，或者使用监控系统，如Zabbix、Prometheus、Open-FaIcon、Ganglia等。

工欲善其事，必先利其器。知道了GC工作原理，学会了看GC日志之后，再来了解一下分析GC的工具。它们分别是jstat、jmap、jhat。

上一次留了个小尾巴：怎么以通过代码模拟对象年龄在15岁之后才进入老年代呢？自己试着实现了一下。然后再结合之前了解的其他GC知识，来模拟更多的触发GC的实例。

了解了基本的G1垃圾回收机制以后，就可以结合实际日志分析一下它的日志内容了，以后再遇到问题自己也能看懂。

看了那么多G1 GC的传说，再来看看一些具体的GC案例以及怎么预防GC把工程师精心设计的系统给搞垮。

G1替代了ParNew+CMS这对搭档组合，既能实现年轻代的垃圾回收，也能实现老年代的垃圾回收。现在继续来说说它的混合回收问题。

在JDK8及其之前，一直用的都是ParNew+CMS的组合：ParNew负责年轻代的垃圾回收，而由CMS负责老年代的垃圾回收，但会产生Stop the World这个无法避免的问题。

上回说到了年轻代和老年代的两个垃圾回收器：ParNew和CMS，并且将CMS的GC过程也一并介绍了，现在来看个订单系统的案例。

上回说到了年轻代、老年代与数据计算的一个案例。接下来就先讲一讲年轻代和老年代的两个垃圾回收器：ParNew和CMS。

如果当前Survivor区中年龄相同的一批对象总大小 ≥ Survivor总数 × 50%，那么这批对象及比它们年龄更大的对象，就都直接进入老年代。但是也有可能在Minor GC之后。

既然程序运行会产生大量的废弃物，也就是「垃圾」，那总不能一直堆着不管吧。现在就来粗浅地谈谈Java里面什么时候会触发GC以及有哪些GC。