凌晨两点的告警:Old 区 12 分钟涨满 2 月 18 号凌晨 2 点 07 分,值班电话响了。监控看板上,我们的智能问答服务实例 qa-svc-7d9f 的老年代曲线是一条近乎垂直的直线:从 1.2 GB 到 5.8 GB 用了 12 分钟,然后 Full GC,STW 4.7 秒,接着又是一条
我们一个网关服务,平时 P99 延迟 40ms 很稳,但每天凌晨批量任务后总有几次 200ms+ 的卡顿尖刺。G1 的 Mixed GC 停顿在堆大时是元凶。JDK 21 上 ZGC 已经成熟,我决定赌一把把它换上。 切换决策:先看停顿从哪来 先用 JFR 抓了一周 GC 数据。G1 在 16G 堆
现象:容器 4 核,GC 却开了 24 个线程 八月初一个 Pod 频繁被 K8s 驱逐,OOMKilled 日志看着是内存超了,但监控显示内存没到 limit。我进容器一查 CPU 使用率 400%——而这 Pod 只申请了 4 核。根因是 GC 线程数按宿主机 24 核算的,Parallel G
背景:为下半年的 JDK 21 LTS 提前做验证 四月我们开始评估下半年升级到 JDK 21 LTS 的可行性。GC 是这次升级最敏感的部分——ZGC 在 JDK 21 里终于要兑现「亚毫秒停顿」的承诺,Shenandoah 也迭代到第三代。我拉了 JDK 21 的早期 EA build(当时到
GC 选型的争论:Shenandoah 还是 ZGC 我们一个时延敏感的交易网关,之前用 G1,业务高峰 P99 偶尔冲到 400 ms,排查发现是 G1 的 Mixed GC 有 100~200 ms 的停顿。组里就"换哪个低延迟 GC"吵开了:有人挺 Shenandoah,有人挺 ZGC。我干脆
实习生问我:这堆 GC 日志到底看什么 4 月底,团队来了个实习生。有次他看到我电脑上的 gc.log,问了一句:"这一行行的数字,你是怎么看出问题的?" 2021-04-28T09:14:22.118+0800: 341882.221: [GC (Allocation Failure) [PSY
风控服务被 Full GC 拖出的长尾 2021 年 1 月底,风控服务的 P99 突然变差。这个服务是同步调用链路上的一环,上游给的超时是 800 ms,一旦它慢了,整个下单流程都会受影响。 当时的配置:JDK 8u272,8 G 堆,CMS + ParNew。 $ jstat -gcutil 1
面试官问"你们生产用哪个收集器",我答不上来 11 月中旬的一次面试,面试官问:"你们生产 JVM 用的什么垃圾收集器?为什么选它?" 我当时的回答是"默认的,没配过"。面试官点了点头没追问,但我知道这题挂了。回去之后把 GC 这块从头看了一遍,顺便把我们线上的 GC 日志翻出来分析了下,发现确实该
MAT 里那个 12 万的 java.lang.ref.Finalizer 8 月初排查一个服务的老年代增长,dump 下来用 MAT 打开,Dominator Tree 里第三名是 java.lang.ref.Finalizer,12.4 万个实例,占了 210 MB。我当时看不懂这是个什么类,点
深入理解 JVM 垃圾回收机制 Java 虚拟机(JVM)的垃圾回收(GC)是内存管理的核心机制。了解 GC 的工作原理对于编写高性能 Java 应用至关重要。 常见的垃圾收集器 Serial GC 单线程,适用于客户端模式 使用 -XX:+UseSerialGC 参数启用 Parallel GC