不想为了监控拖垮生产 之前用 VisualVM 连生产抓采样，JMX 一开 CPU 就飘，GC 行为都变了，抓到的数据还不可信。后来发现 JDK 11 起的 JFR（Java Flight Recorder）开销极低，而且 JDK 14 起的 Event Streaming 能实时订阅事件，不用等
毫无征兆的线程池打满 新上线的网关用 JDK 21 虚拟线程处理请求。压测到 8000 并发时，吞吐量突然从 1.2 万 req/s 跌到谷底，响应从 30ms 飙到 8 秒，CPU 却只有 40%——典型的"线程都在等，CPU 没事干"。jstack 一看，200 个平台线程（carrier）全卡
现象：容器 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（当时到
半夜的 OOM，却没留下证据 有天凌晨一个服务 OOM 自杀重启，等我早上到公司，堆已经被 GC 一遍、镜像重建了，啥都看不到。这种"看过现场却没拍照"的故障最折磨人，只能凭日志猜是哪块吃内存，结果猜了一上午猜错方向。从那以后我定下规矩：任何 Java 服务 OOM 必须自动留证，不能让现场随重启蒸
GC 选型的争论：Shenandoah 还是 ZGC 我们一个时延敏感的交易网关，之前用 G1，业务高峰 P99 偶尔冲到 400 ms，排查发现是 G1 的 Mixed GC 有 100~200 ms 的停顿。组里就"换哪个低延迟 GC"吵开了：有人挺 Shenandoah，有人挺 ZGC。我干脆
冷启动 3 秒，Serverless 上却要等 30 秒 我们的一个图片处理函数被搬上了函数计算（FaaS），按调用计费、闲置回收。问题来了：JVM 冷启动要 3 秒，加上函数平台拉镜像、建实例，一次冷启动用户要等 30 秒以上，体验很差。同事问能不能"像 Go 那样秒起"。我试了 GraalVM
凌晨告警：服务起不来了，日志只有一行 一个深夜，我们的风控服务在发布后反复重启失败。Pod 日志最后一行永远是这句话： java.lang.OutOfMemoryError: unable to create new native thread at java.base/java.lang.
压测时 CPU 打满，top 却看不出热点 上个月我们对订单导出服务做容量评估，用 JMeter 打 800 并发。奇怪的是：应用进程 CPU 占用 760%（8 核几乎跑满），但业务代码里我自认为的"重计算"那段——一个金额汇总循环——在抽样栈里占比不到 8%。同事在群里问："你那个汇总到底慢在哪
RSS 涨到 5.8 GB，但堆才用了 1.2 GB，也没 OOM 4 月底值班，监控告警：订单服务一个实例的容器内存（RSS）从 2 GB 缓慢涨到 5.8 GB，持续了四天还在涨，但没有抛 OutOfMemoryError。K8s 的内存 limit 是 6 GB，再涨就要被 OOMKilled
