Linux下基于pthread的线程间消息队列实现与实战

最近在调一个多线程后台服务，生产者和消费者之间的数据交换一开始是用“共享结构体+锁”的方式硬扛，结果线程数一上来，代码越来越别扭：锁竞争、偶发崩溃、调度混乱全来了。折腾了一周之后，我决定把线程间数据交换统一收敛成线程间消息队列模型，问题顿时清爽了很多。今天把这段能在生产环境稳定跑的 Linux 线程间消息队列代码整理出来，算是《Linux实用功能代码集》的第三篇。

这篇会用 C 语言 + pthread 实现一个基础但完整的线程间消息队列，包含阻塞发送、阻塞接收、非阻塞发送、超时接收这几个最常用的接口，再配合一个多生产者多消费者的完整例子。看完之后你可以直接把这套代码抄到自己的项目里，也能理解为什么条件变量必须配互斥锁、为什么等待要写在 while 里而不是 if 里。适合正在做 Linux C/C++ 开发、嵌入式开发，或者准备系统编程面试的朋友。

1. 先搞清楚线程间消息队列到底解决什么问题

1.1 为什么“共享变量+锁”的方案越写越难受

很多人刚开始做多线程数据交换，第一反应是搞一个全局结构体，然后所有线程都拿同一把锁去保护它。这种做法在功能上没错，但实际工程里会迅速暴露出问题。

首先是耦合太紧。生产者线程要往结构体里写字段，消费者线程要读字段，两边的代码都必须清楚知道结构体内部长什么样。一旦业务逻辑变多，比如你要从网络线程往解析线程丢一段数据，解析线程又要给业务线程回传结果，结构体里字段会越来越多，锁的粒度也越搞越细，最后连加锁顺序都能成为死锁源头。

其次是高吞吐场景下锁竞争严重。一把大锁把所有线程的访问串行化，线程一多，大家都在抢锁，真正的业务处理时间反而被锁等待挤占。用一个简单比喻：消息队列相当于给每个线程发了一个专用信箱，生产线程只负责把信投进信箱，消费线程只负责从信箱取信，两边不需要知道对方的具体运作方式。而“共享变量+锁”是所有人挤在一张桌子上抢同一份文件，乱是必然的。

还有一个问题是轮询检测。有些开发者为了避免锁，让消费者循环检查一个标志位有没有被置位，发现置位了再处理数据。这在实时性和 CPU 开销上都很吃亏：轮询间隔短了 CPU 空转，间隔长了消息延迟变高。线程间消息队列通过条件变量的阻塞唤醒机制，让消费者在队列为空时安稳睡觉，有消息时被立刻叫醒，二者兼得。

1.2 一个线程间消息队列需要同时解决的核心问题

设计线程间消息队列，本质上要同时处理三件事。

第一是并发安全。队列本身是共享资源，所有操作必须用互斥锁保护，这个没什么好说的。

第二是阻塞与唤醒。消费者发现队列为空时不应该忙等，而是挂起；生产者放入消息后要能把消费者唤醒。反过来，队列满的时候生产者也要能挂起，等消费者取走消息腾出空间后再继续。这就是条件变量的典型应用场景。

第三是容量与背压。队列必须有上限，不能任凭生产者无限狂塞。固定容量队列一旦满了，生产者要么阻塞等待，要么选择丢弃或返回失败，这就形成了一种“背压”机制。很多人忽视这一点，结果生产速度一快，消息对象在内存里越堆越多，最后 OOM 了才来排查，非常痛苦。

数据结构上，我选择了环形数组而不是链表。原因有三个：数组的内存是预分配的，不需要每条消息额外 malloc 节点，避免了频繁堆分配；环形数组的头部和尾部索引移动就是简单的取模运算，实现起来不容易出错；实际运行中，数组的连续内存对缓存更友好，吞吐表现通常优于链表。链表队列适合消息大小差异离谱、需要频繁插入删除的场景，但作为通用线程间消息队列，环形数组是我的默认首选。

2. 一版可直接抄作业的 C 代码实现

2.1 数据结构和接口设计

先定义队列对象。这里我把互斥锁、两个条件变量和环形数组索引全部封装在一个结构体里，使用方不需要关心内部实现。

c复制#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <errno.h>
#include <pthread.h>

typedef struct {
    void **buf;           // 消息指针数组
    int capacity;         // 队列容量
    int head;             // 队头，读取位置
    int tail;             // 队尾，写入位置
    int count;            // 当前消息数
    pthread_mutex_t mutex;
    pthread_cond_t not_full;   // 队列未满
    pthread_cond_t not_empty;  // 队列非空
} msg_queue_t;

接口我保留了五个最常用的：

c复制int   msgq_init(msg_queue_t *q, int capacity);
void  msgq_destroy(msg_queue_t *q);
int   msgq_send(msg_queue_t *q, void *msg);          // 阻塞发送
int   msgq_send_noblock(msg_queue_t *q, void *msg);  // 非阻塞发送，满返回 -1
void *msgq_recv(msg_queue_t *q);                     // 阻塞接收
void *msgq_recv_noblock(msg_queue_t *q);             // 非阻塞接收，空返回 NULL
int   msgq_recv_timeout(msg_queue_t *q, void **msg, int timeout_ms); // 超时接收

注意消息的存储方式是存放 void * 指针，而不是拷贝整块数据。这样设计的好处是队列本身只负责搬移指针，非常轻量；缺点是需要调用双方约定好消息对象的内存生命周期。后面第三章我会专门展开讲这个约定，现在先看实现。

2.2 核心函数实现：发送、接收、超时接收

初始化时给环形数组分配空间，互斥锁和条件变量分别初始化。

c复制int msgq_init(msg_queue_t *q, int capacity) {
    memset(q, 0, sizeof(*q));
    q->buf = (void **)malloc(sizeof(void *) * capacity);
    if (!q->buf)
        return -1;
    q->capacity = capacity;
    pthread_mutex_init(&q->mutex, NULL);
    pthread_cond_init(&q->not_full, NULL);
    pthread_cond_init(&q->not_empty, NULL);
    return 0;
}

void msgq_destroy(msg_queue_t *q) {
    pthread_mutex_destroy(&q->mutex);
    pthread_cond_destroy(&q->not_full);
    pthread_cond_destroy(&q->not_empty);
    free(q->buf);
    memset(q, 0, sizeof(*q));
}

阻塞发送的核心逻辑：先加锁，然后 while 循环判断队列是否已满。如果满了就调用 pthread_cond_wait 挂起，等待消费者取走消息后发 signal。队列有空位后写入数组，更新 tail 和 count。这里有个容易被忽略的关键点：写完消息之后，要记得 pthread_cond_signal(&q->not_empty)，唤醒正在等待的消费者。

c复制int msgq_send(msg_queue_t *q, void *msg) {
    pthread_mutex_lock(&q->mutex);
    while (q->count == q->capacity) {
        pthread_cond_wait(&q->not_full, &q->mutex);
    }
    q->buf[q->tail] = msg;
    q->tail = (q->tail + 1) % q->capacity;
    q->count++;
    pthread_cond_signal(&q->not_empty);
    pthread_mutex_unlock(&q->mutex);
    return 0;
}

阻塞接收的逻辑是发送的镜像。队列为空时消费者在 pthread_cond_wait(&q->not_empty, &q->mutex) 上挂起，取到消息后需要 pthread_cond_signal(&q->not_full) 唤醒可能正在等待空位的生产者。很多人实现到这就以为完事了，结果生产者在队列满时永久卡死，就是因为漏了这最后一行。

c复制void *msgq_recv(msg_queue_t *q) {
    pthread_mutex_lock(&q->mutex);
    while (q->count == 0) {
        pthread_cond_wait(&q->not_empty, &q->mutex);
    }
    void *msg = q->buf[q->head];
    q->head = (q->head + 1) % q->capacity;
    q->count--;
    pthread_cond_signal(&q->not_full);
    pthread_mutex_unlock(&q->mutex);
    return msg;
}

非阻塞版本就是把 while 等待换成直接判断，满了或空了就立即返回。适合用在事件循环、实时性要求高的路径上。

c复制int msgq_send_noblock(msg_queue_t *q, void *msg) {
    pthread_mutex_lock(&q->mutex);
    if (q->count == q->capacity) {
        pthread_mutex_unlock(&q->mutex);
        return -1;
    }
    q->buf[q->tail] = msg;
    q->tail = (q->tail + 1) % q->capacity;
    q->count++;
    pthread_cond_signal(&q->not_empty);
    pthread_mutex_unlock(&q->mutex);
    return 0;
}

void *msgq_recv_noblock(msg_queue_t *q) {
    pthread_mutex_lock(&q->mutex);
    if (q->count == 0) {
        pthread_mutex_unlock(&q->mutex);
        return NULL;
    }
    void *msg = q->buf[q->head];
    q->head = (q->head + 1) % q->capacity;
    q->count--;
    pthread_cond_signal(&q->not_full);
    pthread_mutex_unlock(&q->mutex);
    return msg;
}

超时接收是实际项目里最常用的接口。很多业务不能允许线程无限期等待，比如客户端在等待响应时要求 200ms 内必须有个结果。pthread_cond_timedwait 的第二个参数是绝对时间，不是相对时间，所以要先 clock_gettime 拿当前时间，再手动把超时毫秒数加进去。

c复制int msgq_recv_timeout(msg_queue_t *q, void **msg, int timeout_ms) {
    struct timespec ts;
    clock_gettime(CLOCK_REALTIME, &ts);
    ts.tv_sec += timeout_ms / 1000;
    ts.tv_nsec += (timeout_ms % 1000) * 1000000L;
    if (ts.tv_nsec >= 1000000000L) {
        ts.tv_sec++;
        ts.tv_nsec -= 1000000000L;
    }

    pthread_mutex_lock(&q->mutex);
    while (q->count == 0) {
        int rc = pthread_cond_timedwait(&q->not_empty, &q->mutex, &ts);
        if (rc == ETIMEDOUT) {
            pthread_mutex_unlock(&q->mutex);
            return -1;
        }
    }
    *msg = q->buf[q->head];
    q->head = (q->head + 1) % q->capacity;
    q->count--;
    pthread_cond_signal(&q->not_full);
    pthread_mutex_unlock(&q->mutex);
    return 0;
}

这里有一个容易被忽略的细节：pthread_cond_timedwait 除了返回 0 和 ETIMEDOUT，还可能在被信号打断时返回 EINTR。上面的代码没有专门处理 EINTR，一旦发生会继续走 while 循环再次调用 timedwait，而旧的 ts 是一个绝对时间点，如果此时已经过了那个时间点，就会立刻超时返回。对于大多业务这不是大问题，但如果你面对的是信号密集型程序，最好把 clock_gettime 挪到 while 循环里，每次被 EINTR 打断后重新计算剩余超时时间。

2.3 完整示例：三生产者两消费者跑通全流程

我写了一个可以直接编译运行的 demo。消息结构体里带一个 type 字段，0 表示普通数据，1 表示退出信号。两个消费者收到 type == 1 的消息就退出，这样不会出现队列销毁时还有线程阻塞在等待上的问题。

c复制#define PRODUCER_NUM 3
#define CONSUMER_NUM 2
#define MSG_NUM 100

typedef struct {
    long type;   /* 0: 数据, 1: 退出 */
    int id;
    int value;
} msg_t;

static msg_queue_t g_queue;

void *producer_worker(void *arg) {
    int idx = *(int *)arg;
    int start = (idx * MSG_NUM) / PRODUCER_NUM;
    int end = ((idx + 1) * MSG_NUM) / PRODUCER_NUM;

    for (int i = start; i < end; i++) {
        msg_t *m = (msg_t *)malloc(sizeof(msg_t));
        m->type = 0;
        m->id = i;
        m->value = i * 10;
        msgq_send(&g_queue, m);
        usleep(1000);
    }
    return NULL;
}

void *consumer_worker(void *arg) {
    int cnt = 0;
    while (1) {
        msg_t *m = (msg_t *)msgq_recv(&g_queue);
        if (m->type == 1) {
            free(m);
            break;
        }
        cnt++;
        printf("consumer get msg id=%d value=%d\n", m->id, m->value);
        free(m);
        usleep(2000);
    }
    printf("consumer done, count=%d\n", cnt);
    return NULL;
}

int main(void) {
    pthread_t pids[PRODUCER_NUM];
    pthread_t cids[CONSUMER_NUM];
    int idx[PRODUCER_NUM];

    msgq_init(&g_queue, 16);

    for (int i = 0; i < PRODUCER_NUM; i++) {
        idx[i] = i;
        pthread_create(&pids[i], NULL, producer_worker, &idx[i]);
    }
    for (int i = 0; i < CONSUMER_NUM; i++) {
        pthread_create(&cids[i], NULL, consumer_worker, NULL);
    }

    for (int i = 0; i < PRODUCER_NUM; i++) {
        pthread_join(pids[i], NULL);
    }

    /* 所有生产者结束后，投递退出消息，每个消费者一条 */
    for (int i = 0; i < CONSUMER_NUM; i++) {
        msg_t *quit = (msg_t *)malloc(sizeof(msg_t));
        quit->type = 1;
        msgq_send(&g_queue, quit);
    }

    for (int i = 0; i < CONSUMER_NUM; i++) {
        pthread_join(cids[i], NULL);
    }

    msgq_destroy(&g_queue);
    printf("all done\n");
    return 0;
}

编译和运行命令：

bash复制gcc -pthread -o msgq_demo msgq_demo.c
./msgq_demo

运行结果会看到两个消费者交替打印消息，最后各自输出处理数量，两个数量加起来一定是 100。如果某一次运行发现总数不对，那就是队列实现有问题，这一步可以作为基本正确性验证。把队列容量改成 16，观察生产速度明显快于消费速度时生产者会阻塞在 msgq_send 上，这就是有界队列最核心的背压效果。

3. 代码背后的关键细节与为什么是这样

3.1 条件变量必须配互斥锁的原因：丢失唤醒

很多人初学条件变量时都会问一句：为什么 pthread_cond_wait 一定要配一个互斥锁，而且等待前要先加锁？这要从条件变量的使用协议说起。

正确用法是“加锁 → 检查谓词条件 → 条件不满足时调用 wait”。pthread_cond_wait 内部会做三件事：原子地释放互斥锁、把线程加入等待队列然后睡眠、被唤醒后重新获取互斥锁再返回。关键在于“释放锁”和“加入等待队列”是原子操作，中间不会被生产者插进来。

如果不用锁，消费者检查 count == 0 后发现队列为空，正打算去睡眠的这一刻，生产者抢先往队列里塞了一条消息并调用了 pthread_cond_signal。但此时消费者还没进等待队列，这个 signal 直接就丢了。消费者随后进入睡眠，永远等不到那条消息。这就是著名的 lost wakeup 问题。互斥锁保证了从检查谓词到进入等待的整个过程中，生产者无法插入修改状态的操作，所以唤醒不会丢。

3.2 为什么等待条件必须写在 while 循环里

按照 POSIX 标准，条件变量允许虚假唤醒，也就是线程可能在没有收到 signal 的情况下就从 wait 返回。此外，在多消费者场景下，即使没有虚假唤醒，也会出现另一种情况：两个消费者同时在等待，生产者发送一条消息后调用 signal，只唤醒其中一个。但被唤醒的线程还没抢到锁时，另一个消费者可能先抢到锁把消息取走了。等第一个消费者拿到锁继续往下走时，队列又空了。

所以等待条件绝不能写成 if，必须用 while 反复检查。这样即使醒来时发现条件还是不满足，也能回到 wait 继续睡，而不是带着错误的状态往下执行。我在面试候选人的时候，会故意把 while 改成 if 问他们会不会出事，大多数人都能说出“可能读空队列”，但要让他们解释清楚“虚假唤醒”和“多消费者竞争”两个原因，就很少有人能说全。

3.3 量满时的三种策略：阻塞、丢弃、覆盖

有界队列满了以后，生产者应该怎么办？没有标准答案，取决于业务场景。

阻塞等待是最常用的策略，也是我这份代码默认的行为。它的好处是天然背压：消费者处理不过来时，生产者自动降速，整个系统的生产节奏被强制匹配消费能力，内存不会无限增长。日志模块、任务队列都适合这种策略。

非阻塞返回失败适合实时性要求高的场景。比如你不想让某个业务线程卡住，发送失败后直接走降级逻辑，或者把消息丢弃并增加一个统计计数。还有一种是覆盖旧数据，队列满时把最老的消息挤掉，给新消息腾位置。这种策略适合只关心最新状态的场景，比如传感器数据、实时位置上报，旧数据过期了保留也没意义，直接丢掉反而合理。

我建议把三套行为拆成三个函数，而不是在一个函数里用参数控制。调用方的意图能直接体现在函数名上，代码可读性会好很多。现实中大多数项目其实只会用到其中一两种，别为了通用性把签名搞得太复杂。

3.4 消息内存管理约定：所有权随指针一起转移

队列存储的是 void * 指针，意味着队列本身不负责分配和释放消息对象的内存。那这个内存到底谁管？我在项目里遵守的约定是：谁创建，谁负责释放，但释放动作发生在消费完之后，所以本质上消息对象的所有权在 send 时从生产者转移给了队列，在 recv 时又从队列转移给了消费者。

消费者取出消息后，用完必须显式 free，这是消息队列使用中最大的泄漏来源。生产者也绝不能发送栈上变量或者全局变量的地址，否则消费者拿到的可能是已经被覆盖的数据，这比崩溃还难排查。如果消息是一个结构体，比较稳妥的做法是每个消息对象独立 malloc，消费者处理完后 free。如果消息本身就是小块整数，用 (void *)(intptr_t)value 直接传值也是可以的，但需要统一约定，不要混用。

很多无锁队列之所以难写，一部分难点就在内存回收上——生产者和消费者可能同时持有同一个节点的引用，你没法确定何时可以安全释放。有锁版本配合所有权转移就没有这个困扰，这也是为什么我建议先把有锁版本用到极限，再考虑无锁。

3.5 容量怎么定：吞吐与延迟的折中

环形数组的容量在创建时就得固定，所以容量估算很重要。容量太小，生产者频繁被阻塞，线程切换开销变大，吞吐上不去；容量太大，虽然缓冲能力强，但消息在队列里排队的时间变长，端到端延迟升高，内存也白白占用。

我一般用一个简单的估算公式：假设生产者的峰值速率是每秒 3000 条消息，消费者正常情况下每处理一条要 1ms，那么消息在队列里排队等待的延迟如果允许最多 200ms，容量至少需要 3000 × 0.2 = 600 条。再考虑消费者抖动、GC 停顿、IO 阻塞等不确定因素，我会在这个数字上再放大 50% 到 100%，取 1000 到 1200 条。注意队列本身存储的是指针，一条只占 8 字节，真正吃掉内存的是消息对象本身。所以在估算内存时重点是消息对象大小乘以容量，而不是只看队列数组。

如果你的程序里队列长期处于满的状态，说明消费者是瓶颈，加大容量只是把问题往后推，不会真正解决。这时候应该优化消费者的处理逻辑，或者增加消费者线程数，而不是一味扩充缓冲。

4. 消息队列在真实项目里的典型场景与扩展思路

4.1 三个我能直接说出名字的实战场景

第一个是日志异步落地。业务线程不再直接写日志文件，而是把将要写入的内容封装成消息塞进队列，专门的日志线程从队列取消息，攒够一批再统一 write 甚至 fsync。这样做最大的好处是业务线程完全不会被磁盘 IO 拖累，写日志再慢也不影响主流程。即便日志量突然暴增，队列的背压机制也会让业务线程暂时卡一下，而不是让内存里的日志无限堆积。

第二个是网络收包与协议解析的流水线。一个线程负责 recv，把收到的原始数据包塞进队列，多个解析线程从队列里取包做协议解析。这里消息队列承担了流量整形的作用，收包线程的速度不可能长期超过解析线程的处理能力，系统会自然稳定在某个平衡点。

第三个是线程池任务分发。主线程收到请求后封装一个任务对象塞进队列，工作线程空闲时就阻塞在 recv 上，有任务就取出执行。多消费者天然实现了任务的负载均衡，谁空闲谁处理，不需要复杂的调度算法。我见过一些项目用信号量加链表手工实现类似功能，复杂不说，边界条件一堆，真不如踏实封装一个消息队列。

这三个场景的共同点都是生产者和消费者的节奏天然不一致，中间需要一层缓冲和解耦。这也正是消息队列最核心的价值。

4.2 从这版基础队列出发可以继续扩展的方向

多消费者场景下，唤醒策略值得专门说一下。我上面所有实现里用的都是 pthread_cond_signal，它只唤醒一个等待线程。对于“一条消息只能被一个消费者取走”这个语义，signal 是正确的选择。如果改成 pthread_cond_broadcast，所有消费者都会被唤醒，但只有一个人能抢到消息，其他人醒来发现队列又空了，只能再次睡眠，这就是惊群效应，白白增加上下文切换。

如果业务需求是所有消费者都能收到同一条消息，那就不适合直接套这个队列了。那属于广播语义，可以考虑每个消费者维护独立队列，生产者复制消息分别投递，或者用一个全局共享状态加条件变量，让所有消费者都醒来处理。不要把“唤醒一个”和“唤醒全部”搞混，这是面试里很喜欢挖的一个点。

无锁队列是很多人关心的方向。我的建议是：先做好性能测量，确定互斥锁确实成了瓶颈，再考虑无锁。实测中很多系统的瓶颈其实在业务处理、内存分配或者 IO，锁的耗时占比很小。即使锁确实是瓶颈，也别一上来就上 MPMC 无锁队列，可以优先尝试分片队列——每个消费者一个独立队列，生产者在投递时按规则分散到不同队列，减少锁竞争。分片实现简单，效果通常立竿见影。真到了必须无锁的程度，SPSC 的环形队列比 MPMC 容易得多，ABA 问题和内存回收问题也会小很多。

另一个实用扩展是批量收发。比如日志模块从队列里一次取出 100 条再统一写文件，能显著减少锁的获取次数和 IO 次数。可以加一个 msgq_recv_batch 接口，循环取 N 条消息，直到取满或队列为空为止。这个改造对现有代码的影响很小，吞吐提升却很可观，很适合作为第二篇的内容。

5. 我踩过的坑与排查实录

5.1 用 if 代替 while，偶发崩溃找了两天

有一回线上程序偶尔出现段错误，频率不高，一天一两次，core dump 里看不出规律。后来在一个消费线程的入口加了打印，发现 msgq_recv 返回之后，队列的 count 明明已经是 0 了。一查代码，原来同事把 while 写成了 if，在消费者特别多、消息特别少的时候，多个消费者被同时唤醒，一个抢到消息，另一个醒来后直接读空队列的 head 位置，拿到一个野指针。这个问题不会每次必现，但一旦出现就是崩溃，非常难定位。

教训就一条：条件变量的等待谓词一律用 while，没有例外。哪怕你当时确信不会虚假唤醒，也要考虑到多线程竞争带来的“伪虚假唤醒”。

5.2 只唤醒消费者不唤醒生产者，死锁卡死整个流程

有一次我测试一个批量任务，跑着跑着整个程序就没有任何日志输出了，像死锁一样。用 gdb attach 上去后挨个线程看栈，发现所有生产者线程都卡在 pthread_cond_wait 上，消费者线程也全卡在 pthread_cond_wait 上，队列 count 一直是容量最大值。

原因不复杂：消费者取走消息后只处理了业务逻辑，没有调用 pthread_cond_signal(&q->not_full)，导致那些因为队列满而睡着的生产者永远等不到空位通知，整个生产消费链路彻底停摆。这属于条件变量使用中的对称性问题：有 not_empty 就一定别忘了 not_full，两个方向的唤醒都要覆盖到。

排查手段方面，pstack 或者 gdb attach 后 thread apply all bt 是最直接的。看到大量线程阻塞在 pthread_cond_wait 并且 count 始终打满，优先检查消费者的唤醒逻辑。

5.3 timedwait 的超时时间用成了相对时间

pthread_cond_timedwait 的第二个参数是绝对时间点，不是相对毫秒数。新手很容易直接传一个 struct timespec { .tv_sec = 0, .tv_nsec = 200ms }，结果函数认为目标时刻是 1970 年，立刻超时返回，接收循环变成一个忙轮询，CPU 直接飙到 100%。

我用了一个小工具函数来避免踩坑：先 clock_gettime(CLOCK_REALTIME, &now)，然后在 now 的基础上加超时量。如果你的业务对系统时间修改非常敏感，比如服务器偶尔会做时间同步，CLOCK_REALTIME 可能会往回跳，导致等待时间异常。这种情况下可以用单调时钟，但条件变量默认不认 CLOCK_MONOTONIC，需要先用 pthread_condattr_setclock 设置条件变量属性，再创建条件变量。

c复制pthread_condattr_t attr;
pthread_condattr_init(&attr);
pthread_condattr_setclock(&attr, CLOCK_MONOTONIC);
pthread_cond_init(&cond, &attr);
pthread_condattr_destroy(&attr);

5.4 队列销毁时机不对，join 之前 destroy 直接崩溃

有人会在主线程里先 msgq_destroy，再去 join 线程，这会导致还在 wait 的线程访问到已经销毁的互斥锁和条件变量，行为未定义，常见表现就是崩溃或者卡死。正确的销毁顺序是先让所有消费者退出，也就是用退出消息通知它们停止等待，然后 pthread_join 回收所有线程，最后才 destroy 队列。

还有个容易踩的点是队列里的消息对象没有全部消费完就 destroy，内存直接泄漏。我一般在 destroy 前会遍历队列把剩余消息打印出来，确认没有消息残留再释放。

5.5 调试小技巧：给队列加一个状态观测点

我实际项目里的消息队列版本会比上面的代码多一个调试接口，专门用来打印 head、tail、count 这三个值。线上定位问题时非常有用：如果 count 长期等于 capacity，说明消费跟不上；如果 count 长期等于 0，说明生产跟不上或者生产根本没启动。还可以做告警，count 超过容量 80% 时记一条 WARN 日志，这样很多队列问题在爆发之前就能提前发现。

排查多线程问题时，先加日志确认“有没有消息”“消息在哪一步丢的”，往往比盯着代码空想要快得多。我甚至见过有人靠手工模拟内存池去排查队列问题，最后发现只是消费者里某一行 free 写错了变量。先确认数据流的边界是否正常，再往深处挖，这是我从无数次线上事故里总结出来的笨办法，但确实最有效。

这套代码是我从一个长期运行的 Linux 后台服务模块里抽出来的简化版本，经过多轮压测和线上考验，基础功能层面是可靠的。你直接拿来用不会有大问题，但一定要根据业务场景重新审视几个问题：队列容量是否合理？唤醒逻辑是否对称？消息对象生命周期是否清晰？把这些想明白，再复杂的需求都能在这份骨架上安全地往上搭。后面我还会写线程间消息队列的第二篇，重点聊优先级消息、批量收发和队列监控统计，先把这一版跑稳比什么都重要。