JVM调优实战——从Full GC到零停顿的优化之路问题来了系统开始咳嗽。不是宕机不是报错是每隔几小时就卡一下。前端响应从200ms跳到2000ms持续30秒后恢复。监控显示Full GC。症状分析1. 业务影响查询响应时间波动200ms → 2000ms → 200ms交易成功率下降99.9% → 99.5%用户投诉“系统一会儿快一会儿慢”2. 技术指标JVM堆内存8GYoung GC频率每分钟2-3次Full GC频率每3-4小时1次Full GC时长20-30秒3. 业务场景日均交易50万笔并发用户1000数据量人3000万历史记录100亿业务特点早9点、下午2点高峰月末结算峰值诊断过程第一步收集证据# 1. 查看GC原因jstat-gccausepid100010# 输出示例S0 S1 E O M CCS YGC YGCT FGC FGCT GCT LGCC GCC0.0096.8818.2372.4595.1292.3115632345.123451125.4561470.579Allocation Failure System.gc()关键信息LGCC上次GC原因Allocation Failure分配失败GCC当前GC原因System.gc()有人调了System.gc()FGC45次Full GCFGCT1125.456秒累计Full GC时间第二步分析堆内存# 2. 查看堆内存分布jmap-heappid# 输出关键信息Heap Configuration: MinHeapFreeRatio40MaxHeapFreeRatio70MaxHeapSize8589934592(8192.0MB)NewSize268435456(256.0MB)MaxNewSize2863661056(2731.0MB)OldSize5439488(5.1875MB)NewRatio2SurvivorRatio8Heap Usage: PS Young Generation Eden Space: capacity2147483648(2048.0MB)used1234567890(1177.6MB)free912919758(870.4MB)57.5% used From Space: capacity268435456(256.0MB)used0(0.0MB)free268435456(256.0MB)0.0% used To Space: capacity268435456(256.0MB)used0(0.0MB)free268435456(256.0MB)0.0% used PS Old Generation capacity6442450944(6144.0MB)used4567890123(4356.8MB)free1874560821(1787.2MB)70.9% used发现问题Old区使用率70.9%接近触发Full GC的阈值Young区Eden 57.5%Survivor区0%——对象直接进入Old区NewRatio2Young:Old1:2Young区偏小第三步查看GC日志# 3. 开启GC日志java-XX:PrintGCDetails-XX:PrintGCDateStamps-XX:PrintGCTimeStamps-Xloggc:gc.log...GC日志分析34567.890: [GC (Allocation Failure) [PSYoungGen: 1177M-256M(2048M)] 4356M-3456M(8192M), 0.456 secs] 45678.901: [Full GC (System.gc()) [PSYoungGen: 256M-0M(2048M)] [ParOldGen: 3200M-2987M(6144M)] 3456M-2987M(8192M), 23.456 secs]关键点Young GC后存活对象256M全部进入Old区Full GC由System.gc()触发不是内存不足Full GC耗时23.456秒停顿时间太长根本原因1. 代码问题有人调了System.gc()// 罪魁祸首某个第三方库publicclassBadLibrary{publicvoidcleanup(){// 错误手动触发Full GCSystem.gc();}}2. 配置问题Young区太小NewRatio2Young:Old1:2实际业务大量短期对象应该给更大Young区Survivor区使用率0%说明对象年龄增长过快3. 业务问题大对象直接进入Old区业务特点查询结果集大人列表报表数据缓存批量处理中间结果解决方案第一步禁止System.gc()# JVM参数-XX:DisableExplicitGC效果禁止代码中的System.gc()调用Full GC频率立即下降。第二步调整堆内存比例# 调整前-Xmx8g-Xms8g-XX:NewRatio2# 调整后-Xmx8g-Xms8g-XX:NewRatio1-XX:SurvivorRatio6参数解释NewRatio1Young区:Old区1:1各4GSurvivorRatio6Eden:Survivor6:1:1Eden 3G每个Survivor 0.5G第三步优化GC策略# 使用G1GC替代ParallelGC-XX:UseG1GC-XX:MaxGCPauseMillis200-XX:G1HeapRegionSize4m-XX:InitiatingHeapOccupancyPercent45G1GC优势可预测的停顿时间设置200ms目标并发标记减少STW时间自动区域划分避免内存碎片第四步监控大对象# 打印大对象分配堆栈-XX:PrintTenuringDistribution-XX:PrintAdaptiveSizePolicy-XX:HeapDumpOnOutOfMemoryError-XX:HeapDumpPath/tmp/heapdump.hprof验证效果调整前 vs 调整后指标调整前调整后Young GC频率2-3次/分钟3-4次/分钟Full GC频率每3-4小时1次0次2周内Full GC时长20-30秒0秒平均响应时间200ms波动150ms稳定99分位响应时间2000ms500msGC日志对比调整前[Full GC (System.gc()) 23.456s]调整后[GC pause (G1 Evacuation Pause) (young) 156ms] [GC pause (G1 Humongous Allocation) (young) 45ms]政务系统JVM调优要点1. 业务特点决定配置社保系统查询多结果集缓存 → 需要更大Old区批量处理临时对象多 → 需要更大Young区7×24小时不能重启 → 需要稳定GC策略2. 监控指标# 日常监控脚本#!/bin/bashPID$(jps|grepBootstrap|awk{print $1})echo JVM监控$(date)echo1. GC统计:jstat-gcutil$PID10005echo2. 堆内存:jmap-heap$PID|grep-A20Heap Usageecho3. 线程数:jstack$PID|grepjava.lang.Thread.State|wc-lecho4. 大对象:jmap-histo:live$PID|head-203. 参数模板# 社保系统JVM参数模板JDK8-Xmx8g-Xms8g-XX:UseG1GC-XX:MaxGCPauseMillis200-XX:G1HeapRegionSize4m-XX:InitiatingHeapOccupancyPercent45-XX:DisableExplicitGC-XX:PrintGCDetails-XX:PrintGCDateStamps-XX:PrintTenuringDistribution-Xloggc:/logs/gc.log-XX:UseGCLogFileRotation-XX:NumberOfGCLogFiles10-XX:GCLogFileSize10M-XX:HeapDumpOnOutOfMemoryError-XX:HeapDumpPath/tmp/heapdump.hprof4. 调优流程监控收集GC日志、堆内存、线程栈分析确定瓶颈Young/Old区、GC算法、代码问题调整修改参数小步快跑验证压测验证监控效果固化生产部署持续监控经验教训1. Full GC不一定是内存问题System.gc()调用JNI内存泄漏堆外内存溢出2. 不要迷信默认参数JDK默认参数针对通用场景政务系统有特殊性数据量大并发高稳定性要求高3. 调优是持续过程业务变化需要调整参数用户量增长数据量增加功能迭代4. 监控比调优更重要建立基线正常状态设置告警异常指标定期巡检主动发现技术细节1. 为什么G1GC适合政务系统可预测停顿设置最大停顿时间保证业务响应并发标记减少STW时间业务影响小区域划分避免内存碎片长期运行稳定2. 如何确定堆大小# 经验公式总内存操作系统预留(2G) 堆内存 堆外内存 其他进程# 社保系统示例16G服务器 - 操作系统2G - JVM堆8G - 堆外内存2GNetty、DirectBuffer - 数据库连接池1G - 其他3G缓冲3. Young区大小计算# 根据业务特点短期对象多Young区占比大60%-70% 长期对象多Old区占比大60%-70%# 社保系统查询结果缓存长期 临时计算短期# 采用平衡策略Young:Old 1:1总结1. 调优目标不是零GC而是业务无感知GC停顿时间 业务容忍时间社保200msGC频率 业务波动频率内存使用率 安全阈值80%2. 政务系统特殊性不能随便重启参数调整要谨慎数据不能丢GC不能导致数据不一致业务不能停停顿时间必须可控3. 从这次调优学到的先诊断后开药jstat、jmap、GC日志分析小步快跑每次只调整一个参数观察效果监控验证调整后必须验证数据说话持续优化业务变化参数也要变化full gc没有了这句话看似简单背后是分析、调整、无数次的监控验证。技术问题好解决难的是在业务不能停的前提下解决问题。
JVM调优实战——从Full GC到零停顿的优化之路
发布时间：2026/5/19 5:58:24
JVM调优实战——从Full GC到零停顿的优化之路问题来了系统开始咳嗽。不是宕机不是报错是每隔几小时就卡一下。前端响应从200ms跳到2000ms持续30秒后恢复。监控显示Full GC。症状分析1. 业务影响查询响应时间波动200ms → 2000ms → 200ms交易成功率下降99.9% → 99.5%用户投诉“系统一会儿快一会儿慢”2. 技术指标JVM堆内存8GYoung GC频率每分钟2-3次Full GC频率每3-4小时1次Full GC时长20-30秒3. 业务场景日均交易50万笔并发用户1000数据量人3000万历史记录100亿业务特点早9点、下午2点高峰月末结算峰值诊断过程第一步收集证据# 1. 查看GC原因jstat-gccausepid100010# 输出示例S0 S1 E O M CCS YGC YGCT FGC FGCT GCT LGCC GCC0.0096.8818.2372.4595.1292.3115632345.123451125.4561470.579Allocation Failure System.gc()关键信息LGCC上次GC原因Allocation Failure分配失败GCC当前GC原因System.gc()有人调了System.gc()FGC45次Full GCFGCT1125.456秒累计Full GC时间第二步分析堆内存# 2. 查看堆内存分布jmap-heappid# 输出关键信息Heap Configuration: MinHeapFreeRatio40MaxHeapFreeRatio70MaxHeapSize8589934592(8192.0MB)NewSize268435456(256.0MB)MaxNewSize2863661056(2731.0MB)OldSize5439488(5.1875MB)NewRatio2SurvivorRatio8Heap Usage: PS Young Generation Eden Space: capacity2147483648(2048.0MB)used1234567890(1177.6MB)free912919758(870.4MB)57.5% used From Space: capacity268435456(256.0MB)used0(0.0MB)free268435456(256.0MB)0.0% used To Space: capacity268435456(256.0MB)used0(0.0MB)free268435456(256.0MB)0.0% used PS Old Generation capacity6442450944(6144.0MB)used4567890123(4356.8MB)free1874560821(1787.2MB)70.9% used发现问题Old区使用率70.9%接近触发Full GC的阈值Young区Eden 57.5%Survivor区0%——对象直接进入Old区NewRatio2Young:Old1:2Young区偏小第三步查看GC日志# 3. 开启GC日志java-XX:PrintGCDetails-XX:PrintGCDateStamps-XX:PrintGCTimeStamps-Xloggc:gc.log...GC日志分析34567.890: [GC (Allocation Failure) [PSYoungGen: 1177M-256M(2048M)] 4356M-3456M(8192M), 0.456 secs] 45678.901: [Full GC (System.gc()) [PSYoungGen: 256M-0M(2048M)] [ParOldGen: 3200M-2987M(6144M)] 3456M-2987M(8192M), 23.456 secs]关键点Young GC后存活对象256M全部进入Old区Full GC由System.gc()触发不是内存不足Full GC耗时23.456秒停顿时间太长根本原因1. 代码问题有人调了System.gc()// 罪魁祸首某个第三方库publicclassBadLibrary{publicvoidcleanup(){// 错误手动触发Full GCSystem.gc();}}2. 配置问题Young区太小NewRatio2Young:Old1:2实际业务大量短期对象应该给更大Young区Survivor区使用率0%说明对象年龄增长过快3. 业务问题大对象直接进入Old区业务特点查询结果集大人列表报表数据缓存批量处理中间结果解决方案第一步禁止System.gc()# JVM参数-XX:DisableExplicitGC效果禁止代码中的System.gc()调用Full GC频率立即下降。第二步调整堆内存比例# 调整前-Xmx8g-Xms8g-XX:NewRatio2# 调整后-Xmx8g-Xms8g-XX:NewRatio1-XX:SurvivorRatio6参数解释NewRatio1Young区:Old区1:1各4GSurvivorRatio6Eden:Survivor6:1:1Eden 3G每个Survivor 0.5G第三步优化GC策略# 使用G1GC替代ParallelGC-XX:UseG1GC-XX:MaxGCPauseMillis200-XX:G1HeapRegionSize4m-XX:InitiatingHeapOccupancyPercent45G1GC优势可预测的停顿时间设置200ms目标并发标记减少STW时间自动区域划分避免内存碎片第四步监控大对象# 打印大对象分配堆栈-XX:PrintTenuringDistribution-XX:PrintAdaptiveSizePolicy-XX:HeapDumpOnOutOfMemoryError-XX:HeapDumpPath/tmp/heapdump.hprof验证效果调整前 vs 调整后指标调整前调整后Young GC频率2-3次/分钟3-4次/分钟Full GC频率每3-4小时1次0次2周内Full GC时长20-30秒0秒平均响应时间200ms波动150ms稳定99分位响应时间2000ms500msGC日志对比调整前[Full GC (System.gc()) 23.456s]调整后[GC pause (G1 Evacuation Pause) (young) 156ms] [GC pause (G1 Humongous Allocation) (young) 45ms]政务系统JVM调优要点1. 业务特点决定配置社保系统查询多结果集缓存 → 需要更大Old区批量处理临时对象多 → 需要更大Young区7×24小时不能重启 → 需要稳定GC策略2. 监控指标# 日常监控脚本#!/bin/bashPID$(jps|grepBootstrap|awk{print $1})echo JVM监控$(date)echo1. GC统计:jstat-gcutil$PID10005echo2. 堆内存:jmap-heap$PID|grep-A20Heap Usageecho3. 线程数:jstack$PID|grepjava.lang.Thread.State|wc-lecho4. 大对象:jmap-histo:live$PID|head-203. 参数模板# 社保系统JVM参数模板JDK8-Xmx8g-Xms8g-XX:UseG1GC-XX:MaxGCPauseMillis200-XX:G1HeapRegionSize4m-XX:InitiatingHeapOccupancyPercent45-XX:DisableExplicitGC-XX:PrintGCDetails-XX:PrintGCDateStamps-XX:PrintTenuringDistribution-Xloggc:/logs/gc.log-XX:UseGCLogFileRotation-XX:NumberOfGCLogFiles10-XX:GCLogFileSize10M-XX:HeapDumpOnOutOfMemoryError-XX:HeapDumpPath/tmp/heapdump.hprof4. 调优流程监控收集GC日志、堆内存、线程栈分析确定瓶颈Young/Old区、GC算法、代码问题调整修改参数小步快跑验证压测验证监控效果固化生产部署持续监控经验教训1. Full GC不一定是内存问题System.gc()调用JNI内存泄漏堆外内存溢出2. 不要迷信默认参数JDK默认参数针对通用场景政务系统有特殊性数据量大并发高稳定性要求高3. 调优是持续过程业务变化需要调整参数用户量增长数据量增加功能迭代4. 监控比调优更重要建立基线正常状态设置告警异常指标定期巡检主动发现技术细节1. 为什么G1GC适合政务系统可预测停顿设置最大停顿时间保证业务响应并发标记减少STW时间业务影响小区域划分避免内存碎片长期运行稳定2. 如何确定堆大小# 经验公式总内存操作系统预留(2G) 堆内存 堆外内存 其他进程# 社保系统示例16G服务器 - 操作系统2G - JVM堆8G - 堆外内存2GNetty、DirectBuffer - 数据库连接池1G - 其他3G缓冲3. Young区大小计算# 根据业务特点短期对象多Young区占比大60%-70% 长期对象多Old区占比大60%-70%# 社保系统查询结果缓存长期 临时计算短期# 采用平衡策略Young:Old 1:1总结1. 调优目标不是零GC而是业务无感知GC停顿时间 业务容忍时间社保200msGC频率 业务波动频率内存使用率 安全阈值80%2. 政务系统特殊性不能随便重启参数调整要谨慎数据不能丢GC不能导致数据不一致业务不能停停顿时间必须可控3. 从这次调优学到的先诊断后开药jstat、jmap、GC日志分析小步快跑每次只调整一个参数观察效果监控验证调整后必须验证数据说话持续优化业务变化参数也要变化full gc没有了这句话看似简单背后是分析、调整、无数次的监控验证。技术问题好解决难的是在业务不能停的前提下解决问题。
相关文章
基于STM32 HAL库的直流有刷电机PWM调速与PID闭环控制实战
1. 硬件系统搭建与CubeMX工程配置 直流有刷电机控制项目的第一步是搭建完整的硬件系统。我推荐使用STM32F103C8T6这款性价比极高的Cortex-M3内核微控制器，搭配TB6612电机驱动模块。这套组合在实际项目中非常稳定，我自己在多个机器人项目中都验证过它的可…
Unity场景视图操作全解：从鼠标滚轮到Shift+左键，这些隐藏快捷键让你建模效率翻倍
Unity场景视图操作全解：从鼠标滚轮到Shift左键，这些隐藏快捷键让你建模效率翻倍 在3D内容创作的世界里，熟练操作场景视图就像画家掌握画笔一样重要。Unity的场景视图（Scene View）是开发者与虚拟世界交互的主要窗口&…
Windows HEIC缩略图插件：为什么你的iPhone照片在Windows上无法预览？
Windows HEIC缩略图插件：为什么你的iPhone照片在Windows上无法预览？ 【免费下载链接】windows-heic-thumbnails Enable Windows Explorer to display thumbnails for HEIC/HEIF files 项目地址: https://gitcode.com/gh_mirrors/wi/windows-heic-thumb…
BSS138I现货供应
在当今快速发展的电子行业中，BSS138I MOSFET作为一款广受欢迎的小信号N沟道MOSFET，因其低导通电阻、高可靠性和紧凑的SOT-23封装而备受青睐。对于需要采购BSS138I的客户来说，选择一个可靠的供应商至关重要。本文将深入探讨为何深圳市粤科源兴…
基于ESP8266与TFT屏的桌面智能天气站DIY全攻略
1. 项目概述：打造一个桌面级的智能天气信息中心 几年前，当我第一次把玩ESP8266这块小芯片时，就被它“麻雀虽小，五脏俱全”的特性震撼了——一个比硬币大不了多少的模块，竟然内置了完整的Wi-Fi协议栈和可编程的微控制器…
.NET EFCore批量插入性能优化实战：30秒 → 0.5秒
那是一个周五下午，离下班就剩半小时，马上要发版，大家都收拾好东西准备溜了。产品经理火急火燎跑过来，拍着我桌子说：“快看看！那个Excel导入功能炸了，客户导5000条数据，页面转圈转了一…
XBee无线通信配置与Arduino应用实战：从基础到无线编程
1. XBee无线通信基础与网络配置在嵌入式开发和物联网项目中，无线通信是连接物理世界与数字世界的桥梁。XBee模块，特别是基于Zigbee协议的系列，因其开箱即用的易用性、稳定的通信性能和丰富的社区支持，成为了许多开发者构建无线传感…
当RRT*遇见CNN：一份给路径规划新手的‘开箱即用’指南与避坑心得
当RRT*遇见CNN：一份给路径规划新手的‘开箱即用’指南与避坑心得 刚接触路径规划时，很多人会被RRT算法的优雅所吸引——它像一位经验丰富的探险家，能在复杂环境中快速找到可行路径。但当你想让这位探险家变得更聪明，引入CNN&#…
算法工程师简历封神指南：项目细节 + 论文 / 竞赛成果缺一不可
引言：算法岗简历的“死亡三连”，你中了吗？ “熟悉CNN、Transformer、大模型微调，掌握PyTorch、TensorFlow”——当面试官第88次看到这句“算法词典式”技能描述时，已经开始默默划走简历。2026年算法岗卷到什么程度？智联招聘数据显示，硕士学历算法岗平均竞争比达300:1，…
5分钟快速上手：biliTickerBuy开源工具助你轻松抢购B站会员购热门票务
5分钟快速上手：biliTickerBuy开源工具助你轻松抢购B站会员购热门票务 【免费下载链接】biliTickerBuy b站会员购购票辅助工具 项目地址: https://gitcode.com/GitHub_Trending/bi/biliTickerBuy biliTickerBuy是一款专为B站会员购平台设计的开源辅助工具&…
一口气讲清楚 Monorepo、Turborepo、pnpm、Changesets 到底是什么？
你肯定遇到过这种情况：项目里同时有前端、后端、公共组件，放在一个仓库嫌乱，拆成多个仓库又改一个公共函数要在五个项目里各改一遍。于是出现了 Monorepo、Turborepo、pnpm、Changesets 这四个词。它们不是互相替代，而是分别解决工…
从ok-skills项目解析技能树：设计理念、技术实现与工程实践
1. 项目概述与核心价值最近在GitHub上看到一个挺有意思的项目，叫“ok-skills”。光看这个名字，可能有点摸不着头脑，但点进去一看，发现这是一个关于“技能树”或“知识图谱”的开源项目。简单来说，它试图用一种结构化的…
【实用小程序】超轻量级文件上传下载中心 (File Download Server)
站内源码及jar包下载 一、项目概述 文件下载中心一个基于 Java 内置 HTTP 服务器（com.sun.net.httpserver）构建的轻量级文件管理服务。它零第三方依赖，单 JAR 包即可运行，适合在内网环境或临时场景中快速搭建文件共享站点。 你的团队需要临时共享一批日志文件或交付物，…
py每日spider案例之某website之xin东方选课搜索接口(难度一般 扣取代码即可)
加密位置: 逆向接口参数: 逆向接口: const g = globalThis; g.window = g; g.self = g; g.location = {<
终极轻量级Android文本编辑器Markor：多格式笔记应用完全指南
终极轻量级Android文本编辑器Markor：多格式笔记应用完全指南 【免费下载链接】markor Text editor - Notes & ToDo (for Android) - Markdown, todo.txt, plaintext, math, .. 项目地址: https://gitcode.com/gh_mirrors/ma/markor 在移动设备上寻找一款…
MPC-BE：基于DirectShow架构的专业级开源媒体播放解决方案
MPC-BE：基于DirectShow架构的专业级开源媒体播放解决方案 【免费下载链接】MPC-BE MPC-BE – универсальный проигрыватель аудио и видеофайлов для операционной системы Windows. 项目地址:…
如何快速计算3D模型体积和重量：STL-Volume-Model-Calculator终极指南
如何快速计算3D模型体积和重量：STL-Volume-Model-Calculator终极指南 【免费下载链接】STL-Volume-Model-Calculator STL Volume Model Calculator Python 项目地址: https://gitcode.com/gh_mirrors/st/STL-Volume-Model-Calculator 你是否曾经为3D打印项目…
通过Taotoken CLI工具一键配置团队开发环境与模型密钥
通过Taotoken CLI工具一键配置团队开发环境与模型密钥 1. CLI工具安装与基本使用 Taotoken提供的CLI工具可通过npm全局安装或直接使用npx运行。对于需要频繁使用CLI的团队，推荐全局安装： npm install -g taotoken/taotoken对于临时使用或项目级配置&a…