一次OOM线上排查实录 吾圈机器人
一、故障突发：凌晨的告警电话
2026年5月12日凌晨2点17分，我被刺耳的手机铃声惊醒。屏幕上显示的是公司监控系统的紧急告警："服务A出现OOM（内存溢出），已自动重启3次"。作为负责该系统的后端开发工程师，我立刻意识到问题的严重性——服务A是公司核心业务的支撑系统，任何长时间的中断都可能导致重大损失。
我迅速打开笔记本电脑，远程登录到公司的监控平台。从监控数据来看，服务A的内存使用率在过去15分钟内急剧上升，从平时的40%左右飙升至98%，最终触发了OOM Killer。更令人担忧的是，服务在自动重启后，内存使用率又迅速攀升，形成了"重启-溢出-重启"的恶性循环。
二、初步分析：定位问题范围
在处理这类紧急故障时，保持冷静和系统性思维至关重要。我首先排除了一些常见的可能性：
流量突增：查看流量监控，发现当时的请求量与平时凌晨的水平基本一致，没有明显的峰值。这排除了因流量过大导致的内存压力。
最近发布：检查部署记录，发现服务A在过去48小时内没有任何代码发布。这说明问题可能不是由新代码引入的bug导致的。
依赖服务故障：查看相关依赖服务的监控，发现它们都运行正常，没有出现响应延迟或错误率上升的情况。
初步分析后，我将问题范围缩小到服务A本身的内存泄漏或资源耗尽。接下来，我需要获取更详细的运行时数据来定位具体原因。
三、深入排查：捕捉内存快照
为了获取服务A的内存使用情况，我决定在服务重启后立即生成内存快照。由于服务在OOM后会自动重启，我通过调整监控系统的告警策略，设置了一个内存使用率达到80%时的告警，以便在服务崩溃前及时介入。
凌晨2点45分，当内存使用率再次达到80%时，我远程登录到服务器，使用jmap命令生成了堆内存快照：
jmap -dump:format=b,file=heap_dump.hprof <pid>
同时，我还使用jstack命令获取了线程栈信息，以便分析是否有线程阻塞或死循环的情况。
将内存快照下载到本地后，我使用Eclipse Memory Analyzer（MAT）工具进行分析。MAT是一款强大的Java内存分析工具，能够帮助我们快速定位内存泄漏的根源。
四、定位根源：缓存池的"隐形"泄漏
在MAT中打开内存快照后，我首先查看了"Dominator Tree"（支配树）视图，它显示了占用内存最多的对象。结果令人惊讶：一个名为com.example.cache.LocalCache的对象占用了超过70%的堆内存。
进一步分析发现，这个LocalCache是我们自己实现的一个本地缓存池，用于存储频繁访问的业务数据。缓存池的设计采用了LRU（最近最少使用）淘汰策略，理论上应该能够自动清理不再使用的对象。
但仔细查看缓存池的内部结构后，我发现了问题所在：缓存池中的某些条目被外部代码意外地持有了强引用，导致LRU算法无法正确地将它们从缓存中移除。随着时间的推移，这些无法被回收的对象越来越多，最终导致了内存溢出。
通过查看线程栈信息，我找到了持有这些缓存条目的代码。在一个异步任务中，开发人员将缓存中的对象直接赋值给了一个静态变量，而这个静态变量在任务完成后没有被及时清理。由于静态变量持有对象的强引用，即使缓存池尝试回收这些对象，垃圾回收器也无法将它们从内存中移除。
五、紧急修复：临时缓解与长期解决方案
找到问题根源后，我立即采取了紧急修复措施：
临时缓解：在不重启服务的情况下，通过JMX调用缓存池的清理方法，手动清除了那些被静态变量持有的缓存条目。这使得服务的内存使用率迅速下降到正常水平。
代码修复：修改异步任务的代码，避免将缓存对象赋值给静态变量。改为使用局部变量，并在任务完成后显式地将其置为null，以便垃圾回收器能够及时回收这些对象。
监控增强：在缓存池中添加了详细的监控指标，包括缓存条目数量、命中率、淘汰率等。同时设置了缓存条目数量的告警阈值，以便在缓存池异常增长时及时发现问题。
除了紧急修复，我还提出了长期的解决方案：
缓存池重构：计划将自定义的LocalCache替换为成熟的第三方缓存库，如Caffeine或Guava Cache。这些库经过了广泛的测试和优化，能够更好地处理内存管理和对象回收。
代码审查加强：在团队内部加强对内存管理相关代码的审查，特别关注静态变量、异步任务和长生命周期对象的使用。
自动化测试：添加内存泄漏检测的自动化测试，在持续集成过程中运行，以便在代码合并前发现潜在的内存问题。
六、复盘总结：经验与教训
这次OOM故障排查让我收获了宝贵的经验教训：
监控的重要性：完善的监控系统是及时发现和定位问题的关键。除了常规的CPU、内存和磁盘监控，还应该添加业务相关的自定义指标，如缓存命中率、数据库连接池使用率等。
内存分析工具的熟练使用：掌握像MAT这样的内存分析工具能够大大提高排查效率。在平时就应该熟悉这些工具的使用方法，而不是在故障发生时才临时学习。
代码质量的重要性：即使是看似无害的代码，也可能在特定条件下导致严重的问题。在编写代码时，必须时刻关注内存管理和资源回收，特别是在使用静态变量、异步任务和缓存等场景时。
应急响应流程的完善：制定清晰的应急响应流程能够在故障发生时提高团队的协作效率。这次故障中，由于我们有明确的告警和排查流程，能够在短时间内定位并解决问题。
技术债务的清理：自定义的缓存池虽然在初期满足了需求，但随着系统的演进，其维护成本和潜在风险也越来越高。及时清理技术债务，采用成熟的解决方案，能够提高系统的稳定性和可维护性。
七、后续改进：构建更稳定的系统
为了避免类似问题再次发生，我在团队内部推动了一系列改进措施：
引入内存泄漏检测工具：在开发环境和测试环境中引入内存泄漏检测工具，如Plumbr或YourKit，以便在开发阶段发现潜在的内存问题。
定期内存审计：每月对核心服务进行一次内存审计，分析内存使用趋势，及时发现潜在的泄漏点。
培训与分享：组织内部技术分享会，介绍内存管理的最佳实践和故障排查经验，提高团队整体的技术水平。
架构优化：对服务A的架构进行优化，将一些非核心功能拆分到独立的服务中，降低单个服务的复杂度和内存压力。
通过这次OOM故障的排查和修复，我们不仅解决了眼前的问题，还完善了系统的监控和应急响应机制，提高了团队的技术能力。这让我深刻认识到，作为一名后端开发工程师，不仅要关注功能的实现，更要关注系统的稳定性和可维护性。只有这样，才能构建出真正可靠的软件系统。