1、内存泄漏的根源：深入理解Java/Python/Go等语言的内存分配机制，以及常见的内存泄漏模式

大家好，我是你们这堂课的主讲人。

做稳定性保障这么多年，我见过太多线上事故是因为内存泄漏导致的。说白了，内存泄漏就像房间里有个漏水的水龙头——一开始你根本察觉不到，等发现时地板已经泡烂了。今天我们就来彻底扒一扒，内存泄漏到底是怎么产生的。

1.1 语言的内存分配机制：它们到底怎么管内存？

不同语言管内存的方式不一样。但核心问题只有一个：谁负责回收，什么时候回收。

Java：GC 帮你擦屁股，但擦不干净

Java 用的是自动垃圾回收（GC）。对象在堆上分配，GC 负责清理不可达的对象。听起来很美好对吧？

但问题来了——GC 只回收“不可达”的对象。如果一个对象你不再用了，但还有引用指向它，GC 就认为它“活着”。这就是泄漏的根源。

核心要点：Java 的内存泄漏，本质上是“无意识的对象保留”。你忘了把引用置 null，或者集合里塞了对象忘了移除，GC 就永远不碰它。

我在项目中遇到过这样一个案例：一个定时任务每次执行都往 HashMap 里塞数据，但从不清理。跑了三天，堆直接爆了。你想想看，GC 再努力也救不了这种代码。

Python：引用计数 + 标记清除，但循环引用是坑

Python 的内存管理靠两招：引用计数和标记清除。引用计数很直观——没人引用就回收。但循环引用是个老难题。

# 循环引用示例
class Node:
    def __init__(self):
        self.next = None

a = Node()
b = Node()
a.next = b
b.next = a  # 互相引用，引用计数永远不为0

嗯，这里要注意。Python 的标记清除算法能处理循环引用，但前提是对象没有实现 __del__ 方法。一旦有了 __del__，GC 就不知道先销毁谁了——直接跳过。我曾经排查过一个线上服务，内存只增不减，最后发现就是 __del__ 导致的循环引用泄漏。

Go：逃逸分析和 GC，但 goroutine 泄漏更隐蔽

Go 的内存分配很有意思。它会在栈和堆之间做选择——逃逸分析决定对象放哪。如果变量在函数返回后还被引用，就“逃逸”到堆上。

Go 的 GC 是并发三色标记，性能不错。但 Go 的内存泄漏往往不是堆对象的问题，而是 goroutine 泄漏。

避坑指南：goroutine 泄漏比对象泄漏更难发现。一个 goroutine 阻塞在 channel 上没人读，它持有的所有对象就都泄漏了。我曾经排查过一个 Go 服务，内存涨到 8GB 还没崩，但响应时间已经慢到不可接受。最后发现是 10 万个 goroutine 卡在 channel 上。

1.2 常见的内存泄漏模式：你大概率踩过这些坑

模式这东西，说白了就是“前人踩过的坑”。我整理了三类最常见的，你看看自己中过几个。

模式一：集合类泄漏

这是 Java 里最经典的泄漏模式。往 HashMap、ArrayList 里塞对象，用完了不删。

// 集合泄漏示例
public class Cache {
    private static Map<String, Object> map = new HashMap<>();
    
    public void add(String key, Object value) {
        map.put(key, value);  // 只增不减
    }
}

为什么容易犯？因为很多人觉得“反正 GC 会管”。但 GC 管不了——map 本身是强引用，里面的对象永远可达。

我的建议：用 WeakHashMap 或者 LinkedHashMap 做 LRU 缓存。如果非要用 HashMap，务必在不再需要时调用 remove()。我习惯在代码里加个定时清理的机制，哪怕只是日志里打印一下集合大小。

模式二：缓存泄漏

缓存泄漏和集合泄漏有点像，但更隐蔽。因为缓存往往有“过期时间”的概念，但很多人只设了过期，没设最大容量。

举个例子。你用 ConcurrentHashMap 做本地缓存，key 是用户 ID，value 是用户信息。用户量一上来，缓存无限膨胀。你设了 1 小时过期，但 1 小时内涌入 1000 万用户——内存直接爆了。

为什么会这样？因为缓存过期是惰性删除的。只有访问到过期 key 时才会清理。如果 key 一直不被访问，它就永远躺在内存里。

核心要点：缓存必须同时设“过期时间”和“最大容量”。用 Caffeine 或 Guava Cache，它们有淘汰策略。别自己手写 HashMap 做缓存——我见过太多人在这上面翻车。

模式三：回调泄漏

回调泄漏在事件驱动架构里特别常见。你注册了一个监听器或回调，但忘了注销。

// 回调泄漏示例（伪代码）
button.setOnClickListener(new OnClickListener() {
    @Override
    public void onClick(View v) {
        // 处理点击事件
    }
});

这段代码有什么问题？OnClickListener 是匿名内部类，它隐式持有外部类的引用。如果外部类被销毁了，但按钮还活着，外部类就泄漏了。

在 Android 开发里，这种泄漏能把 Activity 撑爆。我排查过一个案例：一个 Fragment 被销毁了，但它的回调还注册在全局 EventBus 上。结果 Fragment 的引用一直被持有，内存泄漏了 200 多个 Fragment 实例。

避坑指南：用弱引用注册回调，或者在生命周期结束时显式注销。我曾经在代码里加了个 unregisterAll() 方法，每次页面销毁时调用。虽然有点笨，但管用。

1.3 总结：内存泄漏的根因就一句话

不管什么语言，什么模式，内存泄漏的根因就一句话：对象不再需要了，但还被引用着。

Java 的集合、Python 的循环引用、Go 的 goroutine——本质都一样。只是表现形式不同罢了。

我个人习惯在写代码时多问自己一句：“这个对象什么时候不再需要？谁还在引用它？” 想清楚这两个问题，90% 的内存泄漏都能避免。

下一章我们会讲如何用工具定位这些泄漏。到时候我会分享一些实战案例，保证让你大开眼界。

← 上一章 📖 返回目录 下一章 →