1. 项目概述搞Java开发的尤其是做后端服务的早晚得跟JVM打交道。很多人背了一堆八股文什么堆啊栈啊垃圾回收算法啊面试对答如流可真到了线上服务出现频繁Full GC、接口超时、内存飙红的时候往往不知道从哪儿下手。这篇JVM从入门到精通的第七篇正好聊三个最实际的东西GC常用参数、方法区Method Area以及JVM调优的真实案例分析。先说点实在的。JVM调优这件事90%的人一上来就翻各种参数文档对着-CMS、G1、ZGC的配置抄来抄去结果一上线反而出了大问题。我见过不少服务因为有人随手加了个-XX:MaxGCPauseMillis200集群直接雪崩原因就是参数没读懂就乱用。所以这篇博文的思路很简单先把GC参数按用途拆清楚再讲清楚方法区在JDK8之后到底是怎么回事最后用几个我自己实际处理过的案例还原一把完整的排查和调整过程你照着这套思路走不敢说能成为调优大师但至少线上遇到问题不慌。适合谁看正在做Java后端、微服务、中间件相关开发的朋友或者准备面试、想从“会用JVM”进阶到“能解决JVM问题”的工程师。文章偏实战每个参数、每个案例都有对应的场景和思考过程不是单纯罗列参数名字。阅读大概需要15分钟建议手边备着一台Linux服务器和JDK环境边看边试效果最好。2. GC常用参数拆解每个参数都不是白设的2.1 堆大小参数-Xms、-Xmx、-Xmn和它们之间的三角关系先处理最基础的。-Xms是初始堆大小-Xmx是最大堆大小。很多人图省事把两个值直接配成一样的这种做法在生产环境确实省心——避免了堆动态扩容带来的性能抖动。JVM在运行时如果需要扩展堆是要向操作系统申请内存的这个过程有停顿虽然很短暂在高并发场景下会被放大。所以我看过的大多数线上配置都是写成一样的。但这里有个容易被忽略的点-Xmn指定新生代大小它和堆大小之间的搭配直接决定对象晋升老年代的节奏。《Java虚拟机规范》里建议新生代占整个堆的三分之一到四分之一实际调优中我更喜欢从GC日志反推而不盲目套比例。举个例子某服务配置了-Xmx4g -Xms4g -Xmn2g新生代占了一半。看上去给了年轻对象足够大的空间Minor GC次数应该少才对。但实际上如果业务对象大多数都是朝生夕死的短命对象这个配置没问题如果服务里有个长期存活的大缓存对象它每次都会被复制到老年代最后老年代涨得飞快Full GC频率反而上来了。所以说参数之间是联动的-Xmn不是越大越好。还有个参数-XX:NewRatio它定义老年代和新生代的比值。比如-XX:NewRatio2表示老年代是新生代的2倍。这个参数和-Xmn是互斥的一般用了-Xmn就不太需要管NewRatio了。我在本地测试环境会故意把NewRatio调大模拟老年代空间紧张的情况用来验证晋升相关的参数是否有问题。2.2 新生代细节参数SurvivorRatio和晋升阈值-XX:SurvivorRatio默认8表示Eden区和一个Survivor区的比例是8:1。也就是说如果有8GB的Eden那一个Survivor是1GB两个Survivor占2GB。这个参数直接影响Minor GC时有多少对象能留在新生代。这里有个常见的坑很多人把SurvivorRatio调小以为这样Survivor能装下更多存活对象结果忽略了另一个参数-XX:TargetSurvivorRatio默认50%。它表示Minor GC后Survivor区使用率达到50%就进入晋升评估。如果你的Survivor区根本装不下每次GC后的存活对象那多余的对象直接晋升老年代老年代压力增大而且这些对象很可能根本活不到老年代该有的寿命。调优时我一般会先观察GC日志里的各个区间的用量。如果你发现Survivor总是接近打满、而且老年代增长曲线陡峭那就得考虑是不是晋升阈值-XX:MaxTenuringThreshold默认15设得太高或太低。阈值太高对象在Survivor来回横跳复制开销大阈值太低对象过早晋升。这个没有统一答案只能靠日志里的Desired survivor size值来校准。说到这提一句-XX:NeverTenure和-XX:AlwaysTenure是调试用的参数前者让对象永远不晋升后者每次都晋升生产环境千万别碰这俩能把正常的GC节奏彻底打乱我就在测试机上试过一次直接体会了一把“堆内存明明够用但Young GC频繁得离谱”的情况。2.3 GC日志参数不懂看日志就等于瞎调GC日志是调优的眼睛。参数方面JDK8时代主流的是-XX:PrintGCDetails -XX:PrintGCDateStamps -XX:PrintHeapAtGC -Xloggc:/path/to/gc.log。JDK9之后统一成了-Xlog:gc*写法完全变了。很多老工程师到现在还习惯用JDK8的写法换到JDK11环境就直接报错这里提醒一句新项目直接用新语法最好兼容性和信息量都更优秀。拿一条典型的CMS日志举例2019-06-18T10:15:30.2010800: 44281.234: [GC2019-06-18T10:15:30.2010800: 44281.234: [ParNew: 6999936K-6999936K(6999936K), 0.0000258 secs]这种日志看上去让人头大。其实核心信息就三个GC发生时间、GC前后堆用量变化、耗时。ParNew: 6999936K-6999936K 代表新生代GC前后根本没变化因为这次GC把所有存活对象都晋升了新生代打满了但一个都没回收掉。这种情况在只做扩容、不调整存活对象分布的服务里经常出现根本原因是所有线程的TLAB都塞满了。日志参数里还有一个容易忽略的是-XX:PrintTenuringDistribution。加了它之后Minor GC日志会多出对象年龄分布表能直接看到每个年龄段的对象有多少。我在排查晋升异常时几乎必开这个参数它能非常直观地告诉你当前服务里对象到底活了多少次才进老年代。2.4 Full GC和CMS/G1专属参数CMS时代的经典参数组合是-XX:UseConcMarkSweepGC -XX:UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction70CMSInitiatingOccupancyFraction70表示老年代使用率达到70%就开始并发收集。这里有个反直觉的地方这个值不是越高越好。设成95理论上能拖延Full GC但CMS并发回收期间如果老年代不够装并发失败退化成Serial Old那一次STW可能长达十几秒比定时Full GC疼得多。我一般从75开始调如果老年代增长慢就往上加增长快就往下减。G1的参数则完全不同核心是-XX:MaxGCPauseMillis和-XX:G1HeapRegionSize。前者设目标停顿时间但不要把它当成硬性指标G1只是“尽量”达到这个时间实际还是通过调节Region大小、混合回收节奏来实现。我曾经遇到一个场景目标停顿200ms但G1的RSet维护开销巨大小对象分配频繁反而牺牲了吞吐量。后来用-XX:G1NewSizePercent和-XX:G1MaxNewSizePercent把新生代比例从默认的5%~60%缩小停顿目标才勉强达成。这里强烈建议在任何调优动作前后都保留GC日志和堆转储文件而且环境最好和线上一致。否则你调出来的是“测试环境的理想值”线上流量一打过来立刻现原形。3. 方法区深度解析JDK7到JDK8的巨变3.1 方法区里到底放了些什么方法区在JVM规范里是一个逻辑概念它存储的是每个类的结构信息包括运行时常量池、字段和方法数据、构造函数和普通方法的字节码内容还有类变量静态变量等。你可能听过“永久代PermGen”这个词这是JDK7及之前对方法区的一种实现方式。JDK8把方法区的实现改成了元空间Metaspace最大的区别在于永久代用的是JVM堆内的内存元空间用的是本地内存Native Memory。这个改动让“方法区内存不够”的问题从堆内转移到了系统内存层面。这里必须展开一个关键点静态变量到底放在哪。JDK7之前静态变量放在永久代JDK7开始挪到了Java堆中JDK8之后依然在堆中而类的元数据仍然在Metaspace。很多人面试被问“静态变量属于方法区吗”容易答错准确说法是静态变量本身是对象引用或值存储在堆中或作为Class对象的一部分而描述这个类的元数据在方法区Metaspace。字符串常量池在JDK7之后也移到了堆中这意味着字符串常量不再占用永久代空间但也带来了一个新的问题String.intern() 的对象不再GC可回收了如果滥用 intern堆容易爆。3.2 Metaspace相关参数与扩容机制JDK8之后两个核心参数是-XX:MetaspaceSize和-XX:MaxMetaspaceSize。前者是初始空间大小也可以理解为触发FGC的阈值水位线后者是元空间能使用的最大本地内存。默认情况下-XX:MaxMetaspaceSize是没有限制的意思是它可以无限使用物理内存直到系统内存不足。这看似省心实则在容器化时代是个隐患。我见过一个后台服务因为频繁热加载Class导致Metaspace涨到3GB明明堆内存只有1GB整个容器直接被OOMKiller杀掉排查半天才发现是Metaspace没设上限。建议生产环境一定设置-XX:MaxMetaspaceSize。设多大看你的应用类型。普通的Spring Boot应用几百个Bean、几十个Mapper代理类256MB到512MB通常足够如果用了CGLIB大量生成代理类、Groovy动态脚本、或者频繁重新部署WAR那么1GB起步比较安全。另外要注意-XX:MetaspaceSize如果设置得太小会引发一个比较隐蔽的现象FGC频率变高但老年代根本没满。因为Metaspace容量快要达到MetaspaceSize时JVM会触发FGC来清理类元数据这个FGC和堆的老年代使用率没有直接关系。我第一次遇到线上每10分钟一次FGC堆却很健康查了半天才发现是MetaspaceSize太小且不断扩容导致的。3.3 方法区溢出与泄漏的典型场景方法区溢出通常报java.lang.OutOfMemoryError: Metaspace。最常见的触发场景有三个动态生成大量类、反射加代理、以及应用反复加载同一个类的不同版本。动态生成类场景典型的是CGLIB代理。有人写代码时不小心在循环里通过Enhancer创建代理对象每循环一次就生成一个新类这些类一旦被加载进Metaspace不会因为你把代理对象置空就被回收因为ClassLoader还在引用着它们。我记得给某公司排查过一个诡异问题一个批量处理任务每跑一轮Metaspace就涨100MB用-XX:TraceClassLoading一看全是 com.sun.proxy.$Proxy 开头的类定位到循环里的CGLIB才解决。另一个典型场景是自定义ClassLoader造成类卸载失败。类能被回收的前提是这个ClassLoader不再被任何对象引用。某些框架为了热部署会创建新的ClassLoader加载新版本但如果旧ClassLoader被业务代码里某个ThreadLocal引用着那么它加载的所有类都不会被卸载Metaspace只增不减。排查这类问题最有效的方式是开-XX:TraceClassUnloading观察哪些类加载了但从未被卸载。方法区还有一个和堆交互的问题类元数据被清理时JVM需要扫描堆中的对象引用所以频繁的类加载和卸载会导致堆上的引用扫描开销变大表现就是CPU飙高。这种问题不是单纯调参数能解决的要从代码层面控制类生成数量。4. 实战一一次高并发服务的GC停顿调优4.1 案例背景与症状某内容服务的线上集群峰值QPS大概8000左右16核32G的机器JDK8默认G1回收器JDK8默认其实是Parallel ScavengeParallel Old这里设定为团队已经手动开启了G1。运维反馈高峰期接口P99延迟从200ms涨到800ms而且持续十几分钟不回落年轻代GC频繁老年代GC每10分钟一次每次停顿都在2秒以上。拿到这个信息我先做了三件事抓GC日志、抓线程栈、看堆内存分布。GC日志显示Young GC频率约每秒2次Mixed GC每10分钟一次但每次停顿高达2.6秒。线程栈显示大量线程阻塞在锁获取上堆分布里老年代用量稳定在12GBEden区GC后释放比例正常。初步判断问题可能不是单纯GC参数问题因为停顿时间远高于G1的正常水平。我让团队在低峰期做了压测复现果然压测到5000 QPS时停顿重现线程栈里锁竞争极其明显。4.2 排查过程与根因定位既然锁竞争突出就先把锁相关的热点代码拉出来。通过jstack多次采样发现大部分线程卡在一个全局缓存对象的初始化方法上具体是ConcurrentHashMap.computeIfAbsent里嵌套了一次耗时统计操作。这个操作本身不慢但高并发下所有请求都要经过它锁粒度太粗线程互相等待。这里有个调优陷阱GC停顿2.6秒你第一反应一定是调GC参数或者加内存但问题的根源其实是业务线程在锁上排队锁等待时间被算进了GC停顿统计里严格说GC日志里看到的停顿是指STW的耗时但应用感知的毛刺包含了线程竞争等待所以纯粹调GC参数是治标不治本。定位到代码问题后把全局缓存改成分段锁弱引用锁竞争大幅下降。同时配合调整G1参数把-XX:MaxGCPauseMillis从200改成100-XX:G1NewSizePercent从默认5改成10让年轻代更大一些更多对象在Eden就被回收避免过早进入老年代。最终P99从800ms回落到220msGC每次停顿降到80ms以内。4.3 调整后的参数配置参考调整后稳定运行的一套配置8核16G容器-Xms8g -Xmx8g -XX:UseG1GC -XX:MaxGCPauseMillis100 -XX:G1NewSizePercent10 -XX:G1MaxNewSizePercent30 -XX:MetaspaceSize256m -XX:MaxMetaspaceSize512m -XX:PrintGCDetails -XX:PrintGCDateStamps -Xloggc:/logs/gc-%t.log这里MetaspaceSize特意设成256m而不是默认值。因为默认的元空间初始阈值一般是20.75MB不同版本略有差异太小会频繁触发类元数据清理的FGC。主动设到256m等于把阈值抬高减少没必要的清理动作。MaxHeapFreeRatio和MinHeapFreeRatio我也建议显式配置尤其在容器环境避免堆内存反复横向伸缩。这套配置不是万能药但它代表了一种调优思路先确保业务代码没有明显的锁竞争、内存泄漏再谈参数。代码有问题的前提下任何参数都是补丁。5. 实战二方法区溢出的线上事故处理5.1 事故现象与初步处理另一个案例是某个规则引擎服务部署方式是每1小时从远程配置中心拉取一批新规则脚本。运行两周后服务开始频繁FGC每次FGC停顿3~4秒再过两天直接报java.lang.OutOfMemoryError: Metaspace进程崩溃重启恢复后重复循环。初步怀疑就是规则脚本导致类无限增长。通过jmap -clstats PID查看类加载器统计果然发现自定义的GroovyClassLoader加载了数万个Class对象每个规则脚本都会编译生成一个Class。很明显规则引擎在每次编译时都会创建新的ClassLoader但没有回收旧的。很多人处理这类问题时第一反应是增大MaxMetaspaceSize这是典型的治标。扩容只能推迟崩溃时间因为类还在持续生成哪怕你设成4GB最多多撑几天而已。5.2 根因分析和修复排查代码后发现每次规则编译时都直接new GroovyClassLoader()而不是复用同一个实例。GroovyClassLoader内部持有底层ClassLoader的引用旧的ClassLoader没有被任何地方持有但问题在于编译后的Class对象被规则缓存持有导致ClassLoader无法被GC回收ClassLoader不被回收它加载的所有类元数据就永远不会释放。修复方案有两个层面第一复用GroovyClassLoader。全局只创建一个实例所有规则脚本通过同一个ClassLoader加载。但这样又带来类冲突问题——如果两批规则里有同名类后加载的会覆盖先加载的所以Groovy官方推荐用GroovyClassLoader.defineClass配合Map缓存管理版本。第二移除规则缓存中对Class对象的强引用。改为只缓存规则实例实例内部引用的是同一个Class。同时给规则编译加一个清理任务定期删除超过生命周期且不再使用的Class版本。修复后Metaspace稳定在180MB左右FGC恢复正常频率。5.3 Metaspace内存泄漏的排查工具排查方法区内存问题我用的工具组合是jmap -clstats PID查看ClassLoader数量、每个ClassLoader加载的类数量用于判断是否存在大量ClassLoader。jcmd PID GC.class_stats查看每个类的元数据占用情况比clstats更细。-XX:TraceClassLoading和-XX:TraceClassUnloading控制台直接打印哪些类被加载、哪些被卸载。大量加载但几乎没有卸载基本就是泄漏。-XX:PrintClassHistogram内存直方图看Class对象的数量。用这套组合基本能定位90%的Metaspace问题。剩下一小部分属于JVM本身的bug需要升级JDK版本解决。这里特别提醒排查Metaspace泄漏时不要嵌上-XX:HeapDumpOnOutOfMemoryError就算了堆转储文件里看不到Metaspace的内容虽然在JDK8u之后做了改进但信息仍有限还是得靠类加载统计来定位。6. 调优方法论与GC参数速查表6.1 一套可复用的三步调优法我处理过几十个线上JVM问题后总结了一套三步走的方法分享出来第一步量化现状。不要靠感觉说“GC频繁”数据说话抓GC日志建议至少包含一个完整的业务高峰周期、抓堆转储、抓线程栈、看CPU和内存监控曲线。拿到这些数据后先回答三个问题Young GC频率是多少FGC频率是多少STW时间分布怎样第二步定位根因。根的层面一定不要只看GC参数。按优先级排查代码里的锁竞争、大对象分配、内存泄漏、外部资源未关闭、然后再回到GC参数本身是否合理。能用代码解决的优先改代码代码改不了再动参数。第三步小步调整、观察、复盘。一次只改一个参数改完上灰度观察至少一个完整业务周期。不要一口气改五六个参数出了问题你根本不知道是谁引起的。这套方法的背后逻辑是JVM调优本质是资源权衡的游戏你调整堆大小、回收器、停顿目标改变的只是CPU、内存、吞吐量之间的分配关系。如果应用本身存在解决不了的代码问题调优只是延缓崩溃。6.2 常见调优误区汇总误区一堆越大越好。堆大意味着GC间隔长但每次GC要扫描的存活对象也更多停顿可能更长。尤其CMS和G1堆过大会导致并发标记周期变长反而影响吞吐量。误区二参数抄来抄去。每套配置都跟业务强相关。一个处理大文件的服务和一个高并发短请求的服务最优参数天差地别。别人的配置只能当参考不能当标准。误区三调优完不验证。调优不是一劳永逸的。业务增长、流量峰值变化、依赖组件的升级都可能让原本合理的参数失衡。建议每次大版本上线后都重新评估一遍GC日志。误区四忽略JVM升级本身。很多JVM bug和性能问题在新版本中已经修复。JDK8和JDK17的G1表现差异巨大如果业务允许优先考虑升级运行时而不是在老版本上死磕参数。6.3 常用GC参数速查表整理一个常用参数速查表方便大家直接对照参数作用建议与注意事项-Xms / -Xmx初始/最大堆生产环境设相同值-Xmn新生代大小根据GC日志调整非固定比例-XX:NewRatio老年代/新生代比例与-Xmn互斥-XX:SurvivorRatioEden/Survivor比例默认8观察TargetSurvivorRatio调整-XX:MaxTenuringThreshold晋升年龄阈值配合PrintTenuringDistribution校准-XX:UseG1GC使用G1回收器JDK9之后默认-XX:MaxGCPauseMillisG1目标停顿不要设极端值建议100-200ms-XX:MetaspaceSize元空间触发FGC阈值建议主动设置避免默认值过小-XX:MaxMetaspaceSize元空间上限容器环境必设避免OOMKilled-XX:PrintGCDetails输出GC详细日志线上建议开启成本很低-XX:PrintGCDateStamps时间戳方便和时间监控对齐-XX:HeapDumpOnOutOfMemoryErrorOOM时自动dump必设方便事后分析遇到GC相关的OOM时这套表能帮你快速排除一半问题。另外再补充一个容易被忽略的-XX:PerfDataSamplingInterval是JVM统计数据的采样间隔默认50ms线上监控平台如果发现JVM统计信息不准确可以调大这个值减少采样开销。7. 写在最后的一点经验JVM调优这件事我踩过的坑比总结经验多得多。先说一个最简单的教训有些参数比如-XX:MaxDirectMemorySize默认等于堆大小NIO场景下如果堆开得很大堆外内存也可能很大加起来直接超了容器限制进程被系统杀掉。所以设置堆大小之前先算清楚整个进程的内存预算。另一个经验是线上JVM问题的定位优先看监控、看日志而不是急着改参数。很多时候你以为的JVM问题背后是代码层的锁、连接没关闭、缓存未失效。技术人最容易犯的错就是手里拿着锤子看什么都像钉子。GC参数只是工具箱里的一种工具不是万能钥匙。最后分享一个小技巧如果你在排查GC问题时找不到思路试着把GC日志里每次GC的耗时画成时序图观察耗时的变化趋势比盯着单次数据有价值得多。耗时逐渐变长大概率是堆内存碎片或者存活对象积压耗时突然跳变则更可能是系统资源被其他进程抢占或磁盘I/O卡顿。顺着这个方向排查往往能很快找到突破口。