6、Binder内存管理：Binder内核缓冲区管理、binder_buffer结构、物理内存映射与引用计数
好，咱们今天聊点硬核的——Binder的内存管理。
说实话，我早年刚接触Android系统时，一直有个困惑：Binder传输数据为什么比Socket快那么多？后来我深入看了内核源码，才恍然大悟。说白了，Binder的秘密武器就是它那套独特的内存管理机制。你想想看，一次Binder调用，数据从进程A到进程B，竟然只需要拷贝一次，这背后就是内核缓冲区管理和物理内存映射在起作用。
我个人习惯把Binder的内存管理拆成三个层面来理解：缓冲区怎么分配、物理内存怎么映射、引用计数怎么维护。咱们一个一个来。
6.1 Binder内核缓冲区管理
先问个问题：当你在应用层调用transact()发送数据时，数据到底存哪儿了？
答案是——Binder驱动在内核空间维护了一个缓冲区池。每个进程在打开Binder设备时，驱动会为其分配一块内核内存，专门用来存放传输中的数据。这块内存就是所谓的binder_buffer。
我记得有一次排查线上问题，发现某个服务频繁OOM，最后定位到是Binder缓冲区泄漏了。嗯，这里要注意：Binder缓冲区是内核资源，如果用户态进程挂了但内核缓冲区没及时释放，就会造成内存泄漏。
binder_proc结构体中的buffers红黑树来管理所有已分配的缓冲区。每次分配时，驱动会从空闲列表中找一块大小合适的区域。
来看看关键的数据结构：
struct binder_buffer {
struct list_head entry; // 链表节点，用于连接空闲或已用缓冲区
struct rb_node rb_node; // 红黑树节点，按地址排序
unsigned int free:1; // 是否空闲
unsigned int allow_user_free:1;
unsigned int async_transaction:1;
struct binder_transaction *transaction; // 所属事务
struct binder_node *target_node;
size_t data_size; // 数据大小
size_t offsets_size; // 偏移数组大小
void *data; // 数据起始地址
};
这个结构体里，我最想强调的是free标志位和entry链表。驱动维护了两条链表：free_buffers（空闲缓冲区链表）和allocated_buffers（已分配缓冲区链表）。分配时从空闲链表中取，释放时再放回去。
分配策略其实挺有意思的——它用的是最佳适应算法。什么意思呢？就是找一块大小刚好大于等于请求大小的空闲块。这样做的好处是减少内存碎片，但代价是查找时间稍长。我在项目中遇到过一个问题：某个高频服务频繁创建小事务，导致空闲链表碎片化严重，分配效率下降。后来我们调整了缓冲区初始大小，情况就好多了。
6.2 物理内存映射：mmap的秘密
Binder最巧妙的设计，我觉得就是物理内存映射。它让数据只拷贝一次，就能在两个进程间共享。
具体怎么做的？
每个Binder进程在初始化时，会调用mmap()系统调用，在内核空间和用户空间之间建立映射。注意，这里映射的是同一块物理内存。
我画了一张图，帮你理解这个过程：
看到没？进程A和进程B各自有独立的用户空间虚拟地址，但它们通过mmap映射到了同一块物理内存。当进程A写入数据时，数据先拷贝到内核空间的binder_buffer，然后进程B直接读取这块物理内存——这就是传说中的一次拷贝。
对比一下传统的Socket通信：数据从进程A用户空间拷贝到内核，再从内核拷贝到进程B用户空间，两次拷贝。Binder省掉了一次，性能自然就上去了。
PAGE_SIZE的整数倍，否则驱动会报错。
6.3 引用计数：谁在用这块内存？
内存管理里，引用计数是个老生常谈的话题。Binder的引用计数主要用在两个地方：binder_node（Binder实体）和binder_ref（Binder引用）。
但咱们今天重点讲的是缓冲区层面的引用计数。每个binder_buffer被分配后，驱动会记录它被哪些事务引用了。具体来说，binder_transaction结构体里有一个buffer指针指向它使用的缓冲区。
引用计数的增减时机很关键：
- 增加引用：当驱动分配一个新的binder_buffer给事务时，引用计数+1
- 减少引用：当事务完成（发送或接收完毕），驱动释放缓冲区，引用计数-1
- 特殊情况：如果事务是异步的（oneway），引用计数管理会略有不同
我整理了一个表格，方便你对照：
| 操作 | 引用计数变化 | 说明 |
|---|---|---|
| binder_alloc_buf() | +1 | 分配缓冲区，事务开始引用 |
| binder_free_buf() | -1 | 释放缓冲区，引用归零 |
| 事务完成（同步） | -1 | 发送方等待回复后释放 |
| 事务完成（异步） | -1 | 发送方不等待，直接释放 |
| 进程异常退出 | 强制归零 | 驱动清理所有未释放缓冲区 |
这里有个容易踩的坑：异步事务的引用计数管理。我记得有一次，一个同事写的服务用了大量oneway调用，结果发现内核缓冲区一直不释放。原因就是异步事务完成后，驱动不会自动回收缓冲区，需要接收方主动调用freeBuffer()。嗯，这个细节在官方文档里写得很隐晦，我也是翻内核源码才确认的。
binder_release()中遍历所有已分配的缓冲区，强制释放。但如果你在内核模块里直接操作binder_buffer，一定要手动管理引用计数，否则会造成内核内存泄漏。我曾经见过一个第三方内核模块，因为忘记减引用计数，导致系统运行三天后panic——教训深刻。
6.4 实战：如何查看Binder缓冲区状态？
光说不练假把式。咱们来看看怎么在真机上查看Binder缓冲区的情况。
你可以通过/proc/binder/proc目录下的文件来查看每个进程的Binder状态。比如：
adb shell cat /proc/binder/proc/1234 # 1234是进程PID输出内容里，你会看到类似这样的信息：
proc 1234
context binder
thread 0: l 00 need_return 0 trn 0
buffer 0: 0x7f000000 size 4096 free 1
buffer 1: 0x7f001000 size 8192 free 0
...
free buffers: 1
allocated buffers: 1
每一行代表一个binder_buffer，free 1表示空闲，free 0表示已被占用。通过这个文件，你可以快速判断某个进程的Binder缓冲区是否泄漏。
free buffers的数量。如果空闲缓冲区越来越少，而且没有回升的趋势，那大概率是某个事务没有正确释放。这时候我会用strace跟踪Binder调用，找到那个"只借不还"的罪魁祸首。
6.5 小结
好了，Binder内存管理的核心脉络咱们捋了一遍。总结三个关键点：
- 缓冲区管理：binder_buffer通过红黑树和链表管理，分配策略是最佳适应算法
- 物理内存映射：mmap让内核和用户空间共享同一块物理内存，实现一次拷贝
- 引用计数：确保缓冲区在事务生命周期内不被误释放，异步事务要特别注意
说实话，Binder这套设计在十几年前是非常超前的。直到今天，很多现代IPC机制还在借鉴它的思路。你如果能把这块吃透，对理解整个Android系统架构都会有很大帮助。
下次咱们可以聊聊Binder的安全边界——怎么通过缓冲区溢出提权。那又是另一个精彩的故事了。
公众号:蓝海资料掘金营，微信deep3321