40、JVM调优陷阱：新手工程师如何无意中制造了频繁Full GC的灾难

40.1、本文背景

本文将为大家详细解析一个较为特殊的JVM优化案例。这个案例的起因是，一位新晋工程师对JVM优化的理解和掌握还不够深入，误入歧途，从某个来源找到了一个非常特别的JVM参数，并错误地设置在了系统中。结果导致线上系统频繁发生Full GC的问题。

然而，我们后续的大量优化案例，实际上都来自于各种复杂而奇特的场景。正是这些不同寻常的场景，让我们有机会逐步积累和丰富自己的JVM优化实战经验。

因此，了解和处理过的场景越多，我们在面对JVM性能问题时，就能更加游刃有余，更加得心应手。

40.2、问题的产生

这个场景的发展过程大致如下：在一个团队中，一位新入行的工程师有一天突然产生了一个想法。他在网上看到了一个关于JVM参数的信息，误以为自己找到了一种独特的技术，于是在当天的系统上线过程中，他擅自设置了一个JVM参数。

你可能会好奇，他设置的是什么参数呢？
不用担心，只需要继续看下去，通过案例分析，你就能明白。现在，你只需要知道，他设置了一个不寻常的参数，然后，问题就出现了。

一般来说，中大型公司都会接入一些监控系统，比如Zabbix、OpenFalcon，或者是公司自研的监控系统。这些监控系统通常都设计得很好，可以让你的系统直接接入，然后在监控界面上可以看到每台机器的CPU、磁盘、内存、网络等负载情况。

更具体地说，你可以看到你的JVM的内存使用波动折线图，以及你的JVM GC发生的频率折线图。如果你自己上报某个业务指标，也可以在监控系统里看到。

而且，一般针对线上运行的机器和系统，我们都会设置一些警报。例如，你可以设置如果10分钟