半夜的 OOM，却没留下证据 有天凌晨一个服务 OOM 自杀重启，等我早上到公司，堆已经被 GC 一遍、镜像重建了，啥都看不到。这种"看过现场却没拍照"的故障最折磨人，只能凭日志猜是哪块吃内存，结果猜了一上午猜错方向。从那以后我定下规矩：任何 Java 服务 OOM 必须自动留证，不能让现场随重启蒸
凌晨告警：服务起不来了，日志只有一行 一个深夜，我们的风控服务在发布后反复重启失败。Pod 日志最后一行永远是这句话： java.lang.OutOfMemoryError: unable to create new native thread at java.base/java.lang.
现象：堆才用了一半，容器就被 OOMKilled 10 月 28 号晚上，网关服务的一个 Pod 被 K8s 杀了。 $ kubectl describe pod api-gateway-5f8b7c9d4-xt2n9 Last State: Terminated Reason:
凌晨三点的告警：Metaspace OOM 3 月 15 号凌晨 3 点 12 分，监控告警把值班同学叫起来了：报表服务的一台实例 Full GC 频繁，接口全部超时。我早上到公司看日志，第一行就是： java.lang.OutOfMemoryError: Metaspace at java
入职第三个月，我把线上服务搞 OOM 了 那是个导出报表的功能。测试环境数据量小，跑得飞快；上线之后运营点了一次"导出全部"，三分钟后服务就挂了。监控上堆内存是一条 45 度的斜线，直接顶到天花板然后掉底。 我登机器捞日志，看到了人生中第一个这个： Exception in thread "http
