一次OOM故障引发的内存管理血案：我是如何在内存泄漏、栈溢出和锁竞争中杀出重围的

上个月的一个周五晚上，正准备下班，监控系统突然疯狂报警。线上服务内存占用持续飙升，已经触发了好几次Full GC，响应时间从平时的50ms涨到了3秒。更要命的是，有几台机器直接OOM挂掉了。

那一晚，我们团队熬到凌晨4点，期间遭遇了内存泄漏、栈溢出、GC风暴，还有诡异的死锁问题。今天就来复盘这次"内存管理大作战"，希望大家能从我们的血泪教训中学到点东西。

故障现场：内存暴涨的诡异曲线

先看看当时的监控数据，简直是一部恐怖片：

看到这个趋势，我第一反应是：完了，内存泄漏了。

内存泄漏：潜伏的定时炸弹

定位泄漏点

立即dump了堆内存，用MAT（Memory Analyzer Tool）分析：

jmap -dump:format=b,file=heap.hprof <pid>

分析结果让人大跌眼镜：

最可疑的是UserSession对象，数量只增不减。跟踪引用链发现，问题出在一个"智能"的缓存实现上：

// 有问题的代码
public class SessionCache {
    private static Map<String, UserSession> cache = new HashMap<>();
    
    public void addSession(String sessionId, UserSession session) {
        cache.put(sessionId, session);  // 只加不删！
    }
}

这位同事想做个缓存优化性能，结果忘了清理过期数据。每个用户登录都会创建session，永远不释放，妥妥的内存泄漏。

内存泄漏的常见场景

这些年遇到的内存泄漏，总结下来就这几类：

栈溢出：递归的噩梦

修复了内存泄漏，重启服务，以为可以安心了。结果没过10分钟，又有机器挂了，这次是StackOverflowError。

栈溢出的元凶

查看错误堆栈，发现是一个看似"优雅"的递归：

// 计算用户权限树
public Set<Permission> getUserPermissions(User user) {
    Set<Permission> permissions = new HashSet<>();
    
    // 获取直接权限
    permissions.addAll(user.getDirectPermissions());
    
    // 获取角色权限
    for (Role role : user.getRoles()) {
        permissions.addAll(getRolePermissions(role));
    }
    
    return permissions;
}

private Set<Permission> getRolePermissions(Role role) {
    Set<Permission> permissions = new HashSet<>();
    permissions.addAll(role.getPermissions());
    
    // 问题在这：角色可以继承角色，形成循环！
    for (Role parent : role.getParentRoles()) {
        permissions.addAll(getRolePermissions(parent));
    }
    
    return permissions;
}

原来是运营同学配置角色时，不小心搞出了循环继承：RoleA -> RoleB -> RoleC -> RoleA。

栈大小与递归深度

做了个实验，测试不同栈大小的递归深度：

但增加栈大小只是治标不治本，关键还是要避免无限递归。

栈溢出的防护措施

总结了几种防护手段：

垃圾回收：从GC优化到GC地狱

解决了内存泄漏和栈溢出，系统终于稳定了一会儿。但好景不长，Full GC开始频繁出现。

GC日志分析

开启详细GC日志后，发现了问题：

-XX:+PrintGCDetails -XX:+PrintGCTimeStamps -Xloggc:gc.log

GC情况统计：

GC调优实战

尝试了多种GC配置：

最终选择了G1，配合合理的参数：

-XX:+UseG1GC 
-XX:MaxGCPauseMillis=200 
-XX:G1HeapRegionSize=16M
-XX:InitiatingHeapOccupancyPercent=45

内存分配优化

发现大量临时对象导致Young GC频繁，做了针对性优化：

互斥锁：并发的双刃剑

就在我们以为终于搞定的时候，系统又出现了新问题：某些请求卡死，CPU使用率却很低。jstack一看，大量线程在等锁。

锁竞争分析

用JProfiler分析锁竞争情况：

最严重的是UserCache的全局锁：

public class UserCache {
    private Map<String, User> cache = new HashMap<>();
    private Object lock = new Object();
    
    public User getUser(String id) {
        synchronized(lock) {  // 读也加锁，太重了！
            return cache.get(id);
        }
    }
}

锁优化方案

针对不同场景采用不同的优化策略：

死锁检测与预防

还发现了一个隐藏的死锁：

// 线程1: 先锁A再锁B
synchronized(lockA) {
    synchronized(lockB) {
        // 处理逻辑
    }
}

// 线程2: 先锁B再锁A  
synchronized(lockB) {
    synchronized(lockA) {
        // 处理逻辑
    }
}

建立了死锁检测机制：

综合优化后的效果

经过一个通宵的奋战，系统终于稳定了：

血泪教训总结

1. 监控要全面

建立了完整的监控体系：

2. 预防胜于治疗

制定了代码规范：

• 所有缓存必须有过期机制
• 递归必须有深度检查
• 大对象使用对象池
• 锁的粒度要尽可能小

3. 压测很重要

这次故障暴露出我们压测的不足。后来建立了更完善的压测体系，模拟各种极端场景。

写在最后

这次故障虽然折腾了一个通宵，但收获很大。内存管理看似简单，实则处处是坑。Java的自动内存管理是把双刃剑，用好了事半功倍，用不好就是灾难。

最大的感悟是：性能优化要有数据支撑，不能靠猜。每个优化点都要测量效果，有时候你以为的优化反而是负优化。

另外，团队协作真的很重要。这次能快速定位并解决问题，多亏了团队里每个人的专长：有人擅长JVM调优，有人精通并发编程，有人熟悉监控工具。

如果你也遇到过类似的内存问题，欢迎分享经验。毕竟，在内存管理这条路上，谁还没踩过几个坑呢？

最后的最后，记住一句话：代码千万行，内存第一条。管理不规范，半夜两行泪。