内存泄漏（如未关闭流、缓存无限增长）

一、引言：GC不是万能药

Java以其自动内存管理机制著称，开发者无需像C++那样手动malloc/free。但这也让许多人产生了一种错觉： "只要我不new，内存就不会爆" 。

现实却是残酷的。在某电商大促期间，一个运行稳定的服务突然在流量高峰时崩溃，日志中赫然写着：

text

编辑

1java.lang.OutOfMemoryError: Java heap space

经过紧急排查，发现罪魁祸首竟是一个用于记录用户操作日志的static Map，它随着时间推移不断膨胀，从未清理；另一个微服务则因为文件流未关闭，导致服务器文件句柄耗尽，无法再接受任何请求。

内存泄漏（Memory Leak） ，这个在C时代的老敌人，在Java时代依然阴魂不散。今天，我们就来揪出两个最隐蔽的"凶手"。

---

二、凶手一号：未关闭的流（Resource Leak）

2.1 什么是资源泄漏？

在Java中，IO流（如FileInputStream、BufferedReader）、数据库连接（Connection）、网络套接字（Socket）等资源，不仅仅占用JVM堆内存，更直接占用操作系统层面的资源（如文件描述符 File Descriptor）。

核心机制：

• 每个打开的流都会向OS申请一个文件句柄。
• 操作系统对单个进程能打开的文件句柄数有限制（Linux默认通常是1024或65535）。
• GC只负责回收堆上的对象，不会主动调用close()方法。虽然对象被回收后，其关联的Finalizer可能会在某个不确定的时刻关闭资源，但这完全不可控。

2.2 经典错误代码示例

看看这段你是否似曾相识的代码：

java

编辑

1public void readFile(String path) {
2    FileInputStream fis = null;
3    try {
4        fis = new FileInputStream(path);
5        // 业务逻辑处理...
6        byte[] data = new byte[fis.available()];
7        fis.read(data);
8        // 注意：这里没有关闭流！
9        // 如果发生异常，fis.close() 永远不会被执行
10    } catch (IOException e) {
11        e.printStackTrace();
12    }
13    // fis 依然处于打开状态，直到GC介入（可能很久以后）
14}

后果：

1. 短期：无明显症状，系统运行正常。
2. 中期：随着调用次数增加，文件句柄逐渐被占满。
3. 长期 ：抛出 java.io.IOException: Too many open files，整个服务瘫痪，甚至影响同一服务器上的其他应用。

2.3 最佳实践：Try-With-Resources

从Java 7开始，引入了try-with-resources语法糖，这是解决资源泄漏的银弹。

✅ 正确写法：

java

编辑

1public void readFileSafe(String path) {
2    // 自动关闭资源，无需手动调用 close()
3    try (FileInputStream fis = new FileInputStream(path);
4         BufferedInputStream bis = new BufferedInputStream(fis)) {
5        
6        byte[] data = new byte[bis.available()];
7        bis.read(data);
8        // 业务逻辑
9        
10    } catch (IOException e) {
11        // 即使这里发生异常，上面的资源也会自动关闭
12        e.printStackTrace();
13    }
14}

原理 ：编译器会自动生成finally块，并在其中调用资源的close()方法。即使try块中抛出异常，资源也能确保被释放。

⚠️ 注意事项：

• 只有实现了AutoCloseable或Closeable接口的类才能用在try-with-resources中。
• 对于老旧的第三方库，如果未实现该接口，仍需在finally块中手动关闭，并处理关闭时可能抛出的异常。

---

三、凶手二号：无限增长的缓存（Unbounded Cache）

3.1 缓存的双刃剑

缓存是提升系统性能的利器，但无限制的缓存就是定时炸弹。

很多开发者为了方便，喜欢用静态集合来存数据：

java

编辑

1public class UserCache {
2    // 灾难的开始：静态Map，生命周期与JVM相同
3    private static final Map<String, User> cache = new HashMap<>();
4
5    public void putUser(String id, User user) {
6        cache.put(id, user);
7    }
8    
9    public User getUser(String id) {
10        return cache.get(id);
11    }
12    
13    // 缺少 remove 方法，或者根本没人调用
14}

问题分析：

• static修饰的cache变量属于类级别，只要类加载器不卸载，这个Map就一直存在。
• 每次调用putUser，新的User对象就被放入Map。
• 即使业务上认为某个用户数据已经"过期"或"不再需要"，只要没从Map中remove，GC就认为它依然被引用（Reachable），绝不会回收。
• 结果：堆内存随时间线性增长，最终触发Full GC，甚至OOM。

3.2 常见场景

1. 监听器未注销 ：注册了事件监听器，对象销毁时忘记removeListener。
2. ThreadLocal滥用 ：线程池复用线程时，未清理ThreadLocal变量，导致上下文对象泄漏。
3. 内部类持有外部类引用：非静态内部类隐式持有外部类实例，若内部类对象被长生命周期对象持有，外部类也无法回收。

3.3 解决方案

方案A：使用弱引用（WeakHashMap）

如果缓存的数据允许在内存紧张时被回收，可以使用WeakHashMap。

java

编辑

1// 当key没有其他强引用时，Entry会被GC回收
2private static final Map<String, User> cache = new WeakHashMap<>();

注意：WeakHashMap只在Key无强引用时生效，如果Value很大且被其他地方引用，依然可能泄漏。

方案B：引入成熟的缓存框架（推荐）

不要重复造轮子！使用Guava Cache 或Caffeine，它们提供了完善的过期策略和大小限制。

Caffeine示例：

java

编辑

1import com.github.benmanes.caffeine.cache.Cache;
2import com.github.benmanes.caffeine.cache.Caffeine;
3import java.util.concurrent.TimeUnit;
4
5public class SafeUserCache {
6    private static final Cache<String, User> cache = Caffeine.newBuilder()
7            .maximumSize(10_000) // 最大条目数，超过后基于LRU淘汰
8            .expireAfterWrite(10, TimeUnit.MINUTES) // 写入后10分钟过期
9            .recordStats()
10            .build();
11
12    public void putUser(String id, User user) {
13        cache.put(id, user);
14    }
15
16    public User getUser(String id) {
17        return cache.getIfPresent(id);
18    }
19}

优势：

• 自动淘汰：基于LRU（最近最少使用）或LFU（最不经常使用）策略自动移除旧数据。
• 时间过期：支持按写入时间、访问时间过期。
• 统计监控：内置命中率、加载时间等指标，便于监控。

---

四、如何排查内存泄漏？

当系统出现内存告警时，按以下步骤操作：

4.1 监控与报警

• 使用Prometheus + Grafana监控JVM堆内存使用率、GC频率。
• 关注Full GC频率：如果Full GC越来越频繁，且回收后内存下降不明显，极大概率是内存泄漏。

4.2 获取堆转储（Heap Dump）

在OOM发生时，或通过命令手动生成快照：

bash

编辑

1# 查找Java进程PID
2jps -l
3# 生成堆转储文件
4jmap -dump:format=b,file=heap.hprof <PID>

或在启动参数中添加：

bash

编辑

1-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/data/logs/

4.3 分析工具：MAT (Memory Analyzer Tool)

1. 打开.hprof文件。
2. 查看Leak Suspects Report（泄漏疑点报告），MAT会自动分析出可能的泄漏点。
3. 重点检查Dominator Tree，找出占用内存最大的对象。
4. 追踪GC Roots引用链，看是谁持有了这些大对象不放。

典型特征：

• 大量的char[]或byte[]数组 -> 可能是未关闭的流缓冲区或大字符串缓存。
• 巨大的HashMap$Node数组 -> 可能是静态Map无限增长。

---

五、总结与最佳实践清单

内存泄漏往往是由疏忽造成的，而非高深莫测的技术难题。为了避免踩坑，请牢记以下清单：

表格

场景	错误做法	✅ 正确做法
IO流/数据库连接	忘记关闭，或仅在try块关闭	使用 try-with-resources
静态集合缓存	static Map/List 只增不减	使用 Caffeine/Guava Cache 设置上限和过期时间
监听器/回调	注册后忘记注销	在对象销毁生命周期（如destroy()）中显式移除
ThreadLocal	线程池复用线程未清理	使用try-finally块，在finally中调用 remove()
内部类	非静态内部类持有大对象	改为 静态内部类，或使用弱引用

最后的话 ：

GC是Java给我们的礼物，但不是免死金牌。优秀的代码不仅在于功能实现，更在于对资源的敬畏。每一次close()的调用，每一个缓存边界的设定，都是系统稳定运行的基石。

希望这篇文章能帮你避开内存泄漏的坑，让你的系统在流量洪峰中依然稳如泰山！