一、内存泄漏概述：内核世界的“隐形杀手”
大家好，我是你们的老朋友。今天咱们正式开讲《内核内存泄漏检测与修复实战》的第一章。
先问大家一个问题：你写用户态程序时，malloc 了没 free，顶多进程退出时系统帮你回收。但内核里呢？你分配了一个页面没释放，这个页面就永远“消失”了——除非你重启机器。这就是内核内存泄漏最可怕的地方。
1.1 什么是内核内存泄漏？
说白了，就是内核在运行过程中，动态分配的内存（比如通过 kmalloc、alloc_pages、vmalloc 等接口）没有被正确释放，导致这部分内存既不能被内核自身复用，也无法被用户态程序使用。
我举个例子：
/* 一个典型的内核泄漏场景 */
void leaky_function(void)
{
char *buf = kmalloc(1024, GFP_KERNEL);
if (!buf)
return;
/* 处理逻辑... 但忘了 kfree(buf); */
return; /* buf 泄漏了！ */
}你看，就这么简单的一行遗漏，1024 字节就永远“蒸发”了。嗯，这里要注意：内核不像用户态，没有 MMU 帮你做“写时复制”或者“自动回收”。你分配了，就得自己负责释放。
1.2 泄漏的常见危害
我在项目中遇到过好几次内存泄漏引发的“惨案”。最典型的有这么几类：
- 系统性能持续下降：可用内存越来越少，页面回收压力增大，系统响应变慢。
- OOM Killer 被触发：当内存耗尽时，内核会随机杀掉进程来释放内存。你想想看，一个关键业务进程被无辜干掉，后果有多严重。
- 系统完全死锁或崩溃：某些内核路径在分配内存时失败，又没有做错误处理，直接导致 NULL 指针解引用——内核 panic。
- 模块卸载失败：如果泄漏发生在内核模块中，卸载模块时可能因为引用计数不为零而无法卸载。
核心观点：内核内存泄漏不是“慢慢变慢”那么简单，它往往以最暴力的方式——系统崩溃——来通知你。
1.3 为什么内核泄漏比用户态更危险？
这个问题我经常被问到。其实答案很直接：
| 对比维度 | 用户态泄漏 | 内核态泄漏 |
|---|---|---|
| 影响范围 | 仅影响当前进程 | 影响整个系统 |
| 回收机制 | 进程退出时自动回收 | 只能重启系统 |
| 检测难度 | 有 Valgrind、ASan 等工具 | 工具少，且需内核支持 |
| 后果严重性 | 进程崩溃，可重启 | 系统崩溃，业务中断 |
| 调试手段 | gdb 直接调试 | kdump、printk，调试困难 |
我曾经接手过一个嵌入式项目，设备运行 72 小时后必死。查了整整两周，最后发现是一个网络驱动的 skb 没有释放。你想想看，如果这是用户态程序，大不了重启进程。但内核泄漏？只能断电重启设备——对于 7x24 小时运行的服务器来说，这就是灾难。
避坑指南：我曾经在调试一个存储驱动时，发现每次 IO 操作都会泄漏一个 4KB 的页面。刚开始没在意，觉得 4KB 不算什么。结果跑了 3 天，系统直接 OOM。所以记住：内核里没有“小泄漏”这个概念，积少成多，迟早出事。
1.4 课程整体知识体系
好，聊完了危害，咱们来看看这门课到底要讲什么。我把它分成四个阶段：
- 基础篇（第 1-8 章）：讲清楚内核内存管理的核心机制——伙伴系统、slab 分配器、vmalloc、页表等。不懂这些，后面检测和修复就是空中楼阁。
- 检测篇（第 9-18 章）：各种检测手段——kmemleak、slabinfo、tracepoint、kprobe、ftrace 等。我会手把手教你如何定位泄漏点。
- 修复篇（第 19-25 章）：常见泄漏模式的修复技巧，包括引用计数管理、错误路径处理、延迟释放等。
- 实战篇（第 26-30 章）：真实案例复盘。我会把我在项目中遇到的 5 个经典泄漏案例完整拆解给你看。
下面这张图，是我自己总结的知识体系框架，你可以先存下来：
我的建议：如果你刚接触内核内存管理，别急着跳去检测篇。先把基础篇啃透——尤其是伙伴系统和 slab 分配器。我见过太多人拿着 kmemleak 瞎跑，结果连报告都看不懂。地基不牢，后面全是空中楼阁。
好了，第一章就到这里。记住一句话：内核内存泄漏不是 bug，是定时炸弹。接下来的 29 章，我会带你一步步学会如何拆弹。
公众号:蓝海资料掘金营，微信deep3321