发现：21 点 47 分，Pod 开始被 OOMKilled 2021 年 12 月 28 号晚上，年终大促的预热场。21:47 分监控群开始报： [P1] promotion-service 实例不可用 事件类型：ContainerOOMKilled 命名空间：prod Pod：pro
现象：堆才用了一半，容器就被 OOMKilled 10 月 28 号晚上，网关服务的一个 Pod 被 K8s 杀了。 $ kubectl describe pod api-gateway-5f8b7c9d4-xt2n9 Last State: Terminated Reason:
起因：压测时前 3 分钟的数据全不能看 9 月初给一个轨迹计算服务做压测，用 JMeter 压 10 分钟，发现吞吐曲线很怪：第 1 分钟 3200 QPS，第 3 分钟 7100 QPS，之后稳定在 8900 QPS 左右。同样的机器、同样的并发，吞吐差了 2.8 倍。 这其实就是 JIT 预热的
七个服务七套 JVM 参数，我整理了一份模板 4 月底盘了一遍生产上 7 个微服务的启动参数，发现全是复制粘贴来的，来源各不相同： user-service: -Xms512m -Xmx2g order-service: -Xms4g -Xmx4g -Xmn2g -XX:+UseG1GC
上线时那个 NoSuchMethodError：两个 jar 里有同一个类 8 月底发版，新功能上线后立刻报了一堆错： 2019-08-27 20:14:32.881 ERROR [http-nio-8080-exec-3] c.x.web.ExceptionHandler - Handler
MAT 里那个 12 万的 java.lang.ref.Finalizer 8 月初排查一个服务的老年代增长，dump 下来用 MAT 打开，Dominator Tree 里第三名是 java.lang.ref.Finalizer，12.4 万个实例，占了 210 MB。我当时看不懂这是个什么类，点
凌晨三点的告警：Metaspace OOM 3 月 15 号凌晨 3 点 12 分，监控告警把值班同学叫起来了：报表服务的一台实例 Full GC 频繁，接口全部超时。我早上到公司看日志，第一行就是： java.lang.OutOfMemoryError: Metaspace at java
入职第三个月，我把线上服务搞 OOM 了 那是个导出报表的功能。测试环境数据量小，跑得飞快；上线之后运营点了一次"导出全部"，三分钟后服务就挂了。监控上堆内存是一条 45 度的斜线，直接顶到天花板然后掉底。 我登机器捞日志，看到了人生中第一个这个： Exception in thread "http
凌晨两点的告警：Redis used_memory 撞到了 maxmemory 我们的 Redis 是 4.0.2，主从各 4G。某天凌晨收到告警，used_memory 冲到 3.9G，然后业务开始大面积报： redis.clients.jedis.exceptions.JedisDataExce
同事问我：既然有 volatile，为什么还要加锁 上周 code review，同事看到我写的一个状态标记用了 volatile，问我："这东西不是能保证线程安全吗，那 synchronized 还有什么用？" 我说不能这么理解，但当时没能讲清楚。下来自己看了几天 JMM 的资料，又写了几个例子验
