2. 消息队列的内存管理：System V与POSIX的较量

消息队列这东西，说白了就是内核里的一块共享缓冲区。你发消息，它存着；你收消息，它给你。但问题就出在这个“存”和“给”的过程里——内存到底归谁管？什么时候释放？进程挂了怎么办？

我早年做嵌入式网关的时候，就被消息队列的内存泄漏坑过一把。那会儿系统跑了三天，突然所有进程都报“无法分配内存”，一查，消息队列里积压了十几万条未读消息。嗯，从那以后，我对消息队列的内存管理就格外上心。

2.1 System V消息队列：msgsnd/msgrcv的缓冲区机制

System V消息队列，是Unix老祖宗传下来的东西。它的内存管理方式，说实话，有点“粗放”。

当你调用msgsnd()发送一条消息时，内核会从系统内存中分配一块空间，把消息内容拷贝进去。这块空间有多大？由msgctl()的IPC_SET命令控制，具体看msg_qbytes这个参数。

核心机制：消息数据存储在内核空间，用户进程通过系统调用读写。内核负责分配和释放缓冲区，但释放的时机取决于消息是否被取走。

来看一个典型的发送流程：

#include <sys/msg.h>

struct msgbuf {
    long mtype;       // 消息类型，必须 > 0
    char mtext[256];  // 消息正文
};

int main() {
    int msgid = msgget(IPC_PRIVATE, IPC_CREAT | 0666);
    struct msgbuf msg = {1, "Hello, World!"};
    
    // 发送消息——内核会拷贝数据到自己的缓冲区
    if (msgsnd(msgid, &msg, sizeof(msg.mtext), 0) == -1) {
        perror("msgsnd failed");
    }
    return 0;
}

这里有个细节：msgsnd()的第三个参数是消息正文的长度，不包括mtype。我见过不少新手在这里栽跟头，传了sizeof(struct msgbuf)，结果内核多拷贝了8字节的mtype，虽然不会报错，但接收端解析时就乱了套。

接收端呢？msgrcv()从内核缓冲区把消息拷贝到用户空间，然后内核释放这块缓冲区。流程看起来挺完美，对吧？

但问题来了——如果接收进程一直不调用msgrcv()，或者进程在接收前崩溃了，消息就永远留在内核里。这就是泄漏的根源。

注意：System V消息队列的生命周期不跟随进程。即使创建队列的进程退出了，队列依然存在，里面的消息也还在。只有显式调用msgctl(msgid, IPC_RMID, NULL)才能销毁队列。

2.2 POSIX消息队列：mq_send/mq_receive的内存分配

POSIX消息队列是后来标准化的，设计上比System V要“现代”一些。它引入了mq_open()、mq_send()、mq_receive()这套接口。

内存管理上，POSIX队列允许你指定最大消息数和每条消息的最大大小：

#include <mqueue.h>

struct mq_attr attr;
attr.mq_flags = 0;
attr.mq_maxmsg = 10;      // 最多10条消息
attr.mq_msgsize = 1024;   // 每条消息最大1KB
attr.mq_curmsgs = 0;

mqd_t mq = mq_open("/my_queue", O_CREAT | O_RDWR, 0644, &attr);

调用mq_send()时，内核会从预先分配好的内存池里取一块给你用。如果队列满了，mq_send()默认会阻塞，直到有空间腾出来。

我个人觉得，POSIX队列比System V好的地方在于：它提供了mq_notify()机制，可以注册一个信号或线程函数，当消息到达时自动通知接收方。这能有效减少“消息积压没人管”的情况。

经验之谈：我建议优先使用POSIX消息队列，除非你必须在老系统上兼容。POSIX的接口更清晰，而且mq_close()和mq_unlink()的语义比System V的msgctl()好理解得多。

2.3 消息队列内存泄漏的典型场景

好了，理论说完了，咱们来看看实际工作中最容易踩的坑。我总结了三个典型场景：

场景一：消息未消费，进程崩溃

这是最常见的泄漏方式。进程A发了一堆消息给进程B，结果B在处理到一半时崩溃了。B没来得及调msgrcv()或mq_receive()，消息就全留在内核里。

更糟糕的是，如果A是个高频率的发送者，比如每秒发1000条，而B重启需要5秒，那这5秒内就有5000条消息堆积。如果队列容量有限，msgsnd()或mq_send()就会阻塞，进而导致A也卡住，形成连锁反应。

我曾经在一个监控系统里遇到过这种情况：采集进程往队列里写数据，分析进程读。分析进程因为一个bug频繁崩溃，每次重启期间队列就爆满。最后采集进程全部阻塞，整个监控链路瘫痪。排查了半天才发现是消息队列的内存泄漏。

场景二：消息类型不匹配

System V消息队列有个“特性”：msgrcv()可以按消息类型接收。如果你指定了类型mtype=1，那类型为2、3的消息就永远取不出来。

看这个例子：

// 发送方：发了三种类型的消息
struct msgbuf msg1 = {1, "type1"};
struct msgbuf msg2 = {2, "type2"};
struct msgbuf msg3 = {3, "type3"};

msgsnd(msgid, &msg1, sizeof(msg1.mtext), 0);
msgsnd(msgid, &msg2, sizeof(msg2.mtext), 0);
msgsnd(msgid, &msg3, sizeof(msg3.mtext), 0);

// 接收方：只收类型1
struct msgbuf rcv;
msgrcv(msgid, &rcv, sizeof(rcv.mtext), 1, 0);  // 只取mtype=1的消息

结果呢？类型2和3的消息永远留在队列里，直到队列被销毁。这就是“选择性接收”带来的泄漏风险。

避坑指南：如果你用System V消息队列，一定要确保接收方能处理所有消息类型。或者，定期用msgctl(msgid, IPC_STAT, &buf)检查msg_qnum，看看有没有积压。

场景三：队列未清理，进程退出

很多开发者以为进程退出时，消息队列会自动销毁。错！

对于System V队列，即使创建它的进程退出了，队列依然存在。下次另一个进程用同样的key调用msgget()，拿到的是同一个队列，里面可能还躺着上次没处理完的消息。

POSIX队列稍微好一点：如果队列是用mq_open()创建的，并且所有打开它的进程都调用了mq_close()，那内核会释放相关资源。但注意，mq_unlink()必须显式调用才能删除队列名称，否则队列名还在，新进程还能打开它。

我的习惯：在进程启动时，先尝试msgctl(msgid, IPC_RMID, NULL)清理旧队列，再重新创建。POSIX队列则在mq_open()之前先mq_unlink()。虽然粗暴，但能保证每次启动都是干净的。

2.4 内存泄漏的检测与预防

说了这么多问题，总得给点解决方案。我整理了一个表格，方便你对照：

问题场景 检测方法 预防措施
消息未消费 用ipcs -q查看队列中消息数 设置超时机制，监控队列深度
类型不匹配 检查msgrcv()的mtype参数 统一消息类型，或用mtype=0接收所有消息
进程崩溃 使用mq_getattr()查看mq_curmsgs 实现看门狗，崩溃后自动清理队列
队列未清理 检查/proc/sysvipc/msg（Linux） 进程退出前显式销毁队列

另外，我推荐一个实用技巧：在开发阶段，给消息队列加一个“心跳”机制。发送方定期发一条特殊类型的消息，接收方如果长时间没收到心跳，就认为对方挂了，主动清理队列。

总结一下：消息队列的内存泄漏，本质上是“内核空间的消息缓冲区没人释放”。System V和POSIX的机制不同，但核心问题一样——你得确保每条消息最终都被取走，或者队列被正确销毁。别指望内核帮你擦屁股，它只管分配，不管回收。

嗯，这一章就到这里。下一章咱们聊聊共享内存——那玩意儿的内存管理更刺激，一不小心就是野指针和段错误。到时候我给你们讲讲我当年是怎么把共享内存玩崩的。

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