这次 OOM 异常，难道是编程界的智商税吗？

引子：OOM 来袭的背后

最后说一句。 这次 OOM 的风波， 虽然过程有点惊心动魄，甚至让人哭笑不得，但好歹是有惊无险地过去了。监控大盘上那条平稳的直线终于回归正常，我心里总算踏实了。

年关将至， 代码却慢了半拍

那会儿正值年关将至，大家伙儿的心思早已飞到了九霄云外手里敲代码的速度明显慢了半拍——毕竟谁不想早点回家过年呢？后来啊就在这节骨眼上，负责运维的哥们儿风风火火冲到我的工位旁边， 平心而论... 脸色比锅底还黑。他急切地说 我手头负责的两个核心服务最近像中了邪一样，频繁被 OOM 干掉，要我赶紧查查到底是哪段代码逻辑出了岔子。

“重启一键解决”真的靠谱吗？

别迷信“重启解决一切”。遇到服务挂了重启固然是最快的恢复手段，却绝不是根本解决方案。每次重启之前，都应该顺手留个 Dump 或者至少把关键日志保存下来。事后复盘才能避免同一个坑 掉进去，否则只能自嘲自己是“傻逼”，扎心了...。

从监控大盘看异常信号

监控大盘别只看热闹。那根代表内存使用率的曲线长期高居 95% 以上，就像是一颗随时可能爆炸的定时炸弹。 没法说。 报警阈值设得太高，只在服务彻底挂掉时才报警，这等于把危机埋在地下等它自行暴露。

一句话。 建议：把内存使用率报警阈值调低——80% 发警告邮件，90% 直接告警并触发自动化处理。

深挖根源：从代码到容器

太魔幻了。 经过一番排查，我发现 JVM 的堆内存设置并没有感知容器限制。老版本 JDK 会把容器当成物理机来计算可用内存， 于是疯狂申请堆外内存，到头来被容器卡脖子触发 OOM。

这时候， 一个不起眼的日志打印组件在处理特定格式日志时会无休止地拼接字符串，却从不释放对象。它像勤勤恳恳的搬运工，只管往仓库里搬东西，却从不记账，也不把东西搬出去——仓库终究会爆满。