凌晨两点告警群炸了。核心交易系统响应时间从50ms飙到3秒CPU打到98%订单失败率肉眼可见地往上涨。值班同事第一反应是重启但重启后不到十分钟同样的症状再次出现。这一次我们没有重启而是决定把根因挖出来。第一步抓现场别急着重启jstat -gcutil pid 1000的输出触目惊心老年代使用率98%Full GC每30秒一次每次停顿2.5秒累计Full GC次数已经超过200次。jmap -histo:live pid导出堆直方图排在第一的是java.util.HashMap$Node实例数超过800万。什么Map会存这么多东西顺着代码排查发现一个本地缓存每次查询用户信息都往一个静态Map里塞键是用户ID值是用户对象永远不过期。上线三个月用户量从10万涨到200万这个Map就成了内存黑洞。第二步治标紧急止血定位到泄漏点先改代码把本地Map换成Caffeine设置最大容量10万条写入后30分钟过期。同时在运维侧临时把堆从4G扩到8G给修复争取时间。改完上线Full GC频率从30秒一次降到4小时一次系统暂时稳住了。但这不是终点。百万并发是三个月后的目标以当前的架构光靠加堆内存解决不了根本问题。第三步治本从GC到架构全面调优GC选型与参数。原来用的是Parallel GC暂停时间长。切换到G1堆16G设-XX:MaxGCPauseMillis200新生代用-Xmn4g同时开启-XX:ParallelRefProcEnabled加速引用处理。切换后Young GC停顿从100ms降到30msFull GC几乎消失。对象分配优化。交易链路中有大量DTO在循环里创建Young GC频率高。引入对象池复用核心对象同时用-XX:UseTLAB默认开启线程本地分配缓冲减少锁竞争。Young GC频率从每秒3次降到每5秒1次。线程池精细化。之前所有业务共用一个线程池核心线程50队列无界。改成按业务隔离订单线程池核心100、队列1000、拒绝策略CallerRuns查询线程池核心200、队列2000、拒绝策略DiscardOldest。同时加-XX:ActiveProcessorCount对齐容器CPU限制避免线程数按宿主机CPU算。数据库连接池。HikariCP最大连接数从50调到200配合-XX:UseContainerSupport让JVM感知容器内存。慢SQL加索引后平均查询从200ms降到20ms连接持有时间大幅缩短。第四步压测验证步步为营调优不是拍脑袋。用JMeter分阶段压测500并发→2000→10000→50000。每轮观察TPS、P99响应时间、GC日志、CPU和内存曲线。500并发时TPS 8000P99 80ms到10000并发TPS稳定在12000P99 150ms50000并发时出现瓶颈——网卡带宽打满。换万兆网卡调大TCP缓冲区最终在80000并发时TPS达到15000P99 200msFull GC一天不超过两次。百万并发不是单机扛住的是水平扩展无状态设计异步化共同实现的。但单机性能调优是基础——如果单机P99是3秒加一百台机器也只是把雪崩推迟几分钟。写在最后这次调优给我三个教训第一本地缓存必须有容量和过期策略否则就是定时炸弹第二GC调优不是调参数而是先找内存泄漏再谈参数第三百万并发是架构问题但架构问题往往先从单机性能暴露出症状。别迷信“加机器”先把单机吃透再谈分布式。从一次FullGC到稳住百万并发这条路没有捷径但有方法监控→定位→修复→压测→迭代。循环五轮系统自然脱胎换骨。
凌晨两点告警群炸了。核心交易系统响应时间从50ms飙到3秒CPU打到98%订单失败率肉眼可见地往上涨。值班同事第一反应是重启但重启后不到十分钟同样的症状再次出现。这一次我们没有重启而是决定把根因挖出来。第一步抓现场别急着重启jstat -gcutil pid 1000的输出触目惊心老年代使用率98%Full GC每30秒一次每次停顿2.5秒累计Full GC次数已经超过200次。jmap -histo:live pid导出堆直方图排在第一的是java.util.HashMap$Node实例数超过800万。什么Map会存这么多东西顺着代码排查发现一个本地缓存每次查询用户信息都往一个静态Map里塞键是用户ID值是用户对象永远不过期。上线三个月用户量从10万涨到200万这个Map就成了内存黑洞。第二步治标紧急止血定位到泄漏点先改代码把本地Map换成Caffeine设置最大容量10万条写入后30分钟过期。同时在运维侧临时把堆从4G扩到8G给修复争取时间。改完上线Full GC频率从30秒一次降到4小时一次系统暂时稳住了。但这不是终点。百万并发是三个月后的目标以当前的架构光靠加堆内存解决不了根本问题。第三步治本从GC到架构全面调优GC选型与参数。原来用的是Parallel GC暂停时间长。切换到G1堆16G设-XX:MaxGCPauseMillis200新生代用-Xmn4g同时开启-XX:ParallelRefProcEnabled加速引用处理。切换后Young GC停顿从100ms降到30msFull GC几乎消失。对象分配优化。交易链路中有大量DTO在循环里创建Young GC频率高。引入对象池复用核心对象同时用-XX:UseTLAB默认开启线程本地分配缓冲减少锁竞争。Young GC频率从每秒3次降到每5秒1次。线程池精细化。之前所有业务共用一个线程池核心线程50队列无界。改成按业务隔离订单线程池核心100、队列1000、拒绝策略CallerRuns查询线程池核心200、队列2000、拒绝策略DiscardOldest。同时加-XX:ActiveProcessorCount对齐容器CPU限制避免线程数按宿主机CPU算。数据库连接池。HikariCP最大连接数从50调到200配合-XX:UseContainerSupport让JVM感知容器内存。慢SQL加索引后平均查询从200ms降到20ms连接持有时间大幅缩短。第四步压测验证步步为营调优不是拍脑袋。用JMeter分阶段压测500并发→2000→10000→50000。每轮观察TPS、P99响应时间、GC日志、CPU和内存曲线。500并发时TPS 8000P99 80ms到10000并发TPS稳定在12000P99 150ms50000并发时出现瓶颈——网卡带宽打满。换万兆网卡调大TCP缓冲区最终在80000并发时TPS达到15000P99 200msFull GC一天不超过两次。百万并发不是单机扛住的是水平扩展无状态设计异步化共同实现的。但单机性能调优是基础——如果单机P99是3秒加一百台机器也只是把雪崩推迟几分钟。写在最后这次调优给我三个教训第一本地缓存必须有容量和过期策略否则就是定时炸弹第二GC调优不是调参数而是先找内存泄漏再谈参数第三百万并发是架构问题但架构问题往往先从单机性能暴露出症状。别迷信“加机器”先把单机吃透再谈分布式。从一次FullGC到稳住百万并发这条路没有捷径但有方法监控→定位→修复→压测→迭代。循环五轮系统自然脱胎换骨。
