给 AI 服务调 JVM，我原来的经验全部失效了 我做 JVM 调优大概六年，给订单、支付、库存这些服务调过不下三十次，形成了一套肌肉记忆：Young 区给 1/3，MaxGCPauseMillis 设 100，开字符串去重，老年代增长超过 50 MB/min 就要警惕。 2025 年下半年开始接
凌晨两点的告警：Old 区 12 分钟涨满 2 月 18 号凌晨 2 点 07 分，值班电话响了。监控看板上，我们的智能问答服务实例 qa-svc-7d9f 的老年代曲线是一条近乎垂直的直线：从 1.2 GB 到 5.8 GB 用了 12 分钟，然后 Full GC，STW 4.7 秒，接着又是一条
流式对话服务 OOM，堆转储里有 47 万个 ByteBuffer 十一月中旬的一个周一早上，告警炸了：智能客服服务的三个实例在 20 分钟内相继 OOM 重启。这个服务上线两个月一直很稳，堆 8 GB，平时使用率 40% 左右。 这篇是完整的排查过程。结论不复杂——流式响应没有正确关闭，但排查过程
分代 ZGC 在我们的网关上跑了一年 去年十月，我们把 API 网关从 G1 换成了分代 ZGC，到这个月正好一年。这篇是完整的数据总结，包括参数、遇到的四个问题、以及我现在的看法。 先说结论：换成 ZGC 是我们这一年最值的一次技术决策，但它不是银弹，而且代价被大多数人低估了。 背景：为什么要换
把 AI 服务压到 3000 QPS 之后，GC 曲线完全变了 我们有个文档问答服务，跑在 JDK 21 + G1 上，原来堆 4G，Young 区 1.2G，日均 800 万次调用，GC 表现平平无奇：Young GC 每 8 秒一次，单次 25ms 左右，Full GC 一周见不到一次。 八月份
27 万个虚拟线程，把 4 核 8G 的容器拖死了 12 月 6 号凌晨，告警电话把我叫醒。AI 批处理服务的响应时间从正常的 300 毫秒涨到 30 秒以上，CPU 100%，但业务吞吐几乎归零。 # 监控截图里的数据 jvm_threads_live
我们一个网关服务，平时 P99 延迟 40ms 很稳，但每天凌晨批量任务后总有几次 200ms+ 的卡顿尖刺。G1 的 Mixed GC 停顿在堆大时是元凶。JDK 21 上 ZGC 已经成熟，我决定赌一把把它换上。 切换决策：先看停顿从哪来 先用 JFR 抓了一周 GC 数据。G1 在 16G 堆
我们的一个内部工具服务，部署在 Serverless 上，每次冷启动要 8 秒。函数计费按运行时长，8 秒里一半在"加载类、初始化 Spring 上下文"，用户已经走了。老板问能不能压到 2 秒内，于是有了这次冷启动专项优化。 先量化，再动手 不量就优化是瞎猜。我用 -Xlog:class+load
一个服务在 K8s 里跑得好好的，突然被重启，看 Pod 事件只有一行 OOMKilled。我第一反应是"堆不够了"，加了 -Xmx 之后反而重启更频繁。后来才明白，我搞混了两种 OOM。 两个 OOM 不是一回事 JVM 的堆 OOM（java.lang.OutOfMemoryError: Jav
内存曲线像极了漏水的水龙头 订单服务上线两周，Old 区内存从 1.2G 缓慢爬到 3.8G，Full GC 后也只回一点，没真正回落。不是突崩，是慢性失血。这种"缓增长"最容易被忽视，因为单次看都正常，直到某天 Old 区满了频繁 Full GC，接口全抖。我用多次 dump 对比把它揪出来，过程
