mq_send返回-1且errno==EAGAIN表示消息队列已满且处于非阻塞模式，应检查mq_maxmsg容量、优化消费者处理速度，或改用阻塞模式/超时发送。
mq_send 返回 -1 且 errno == EAGAIN 怎么办
这是 POSIX 消息队列满的明确信号，不是错误，而是提示你队列已无空闲槽位。默认行为是阻塞等待（除非你显式设了 O_NONBLOCK），但一旦设了非阻塞，mq_send 就会立刻返回 -1 并置 errno 为 EAGAIN 或 EWOULDBLOCK。
关键点在于：不能忽略这个返回，也不能盲目重试——得结合业务逻辑判断是否可丢弃、缓存、降级或限流：
- 若消息允许丢失（如监控心跳），直接跳过或记录告警即可
- 若必须送达，需在应用层做缓冲（比如用
std::queue+ 独立线程轮询重发），但注意避免内存无限增长 - 若队列容量长期打满，大概率是消费者处理太慢，应检查
mq_receive调用频率、消息体大小、反压机制是否缺失 - 别在循环里高频
usleep(1)等待——这既浪费 CPU，又无法解决根本问题
如何创建带足够容量的 POSIX 消息队列
mq_open 的 attr 参数若传 nullptr，系统用默认大小（通常是 10 条），极易满。必须显式配置 mq_maxmsg 和 mq_msgsize：
struct mq_attr attr = {};
attr.mq_maxmsg = 1024; // 最大消息数，别用默认值
attr.mq_msgsize = 1024; // 每条消息最大字节数，需匹配实际 payload
int mqd = mq_open("/cfg_queue", O_CREAT | O_RDWR, 0644, &attr);
注意：mq_msgsize 必须 ≥ 实际发送消息长度，否则 mq_send 直接失败并设 errno = EMSGSIZE；mq_maxmsg 太大会占用内核资源，太小则频繁触发 EAGAIN。
立即学习“C++免费学习笔记（深入）”；
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
mq_receive 阻塞 vs 非阻塞对满队列的影响
队列满只影响发送端，但接收端是否阻塞会影响整体吞吐节奏。如果消费者用阻塞方式调用 mq_receive，而生产者持续高速写入，队列满只是时间问题。
更稳健的做法是让接收端也用非阻塞 + 轮询（配合 epoll 或 timerfd 控制节奏）：
- 用
mq_notify注册异步通知，避免轮询消耗 CPU - 若必须轮询，至少加
nanosleep（比usleep更准）而非忙等 -
mq_receive成功后检查返回值是否为 0（表示收到空消息），某些旧内核有此行为，需兼容
为什么不用 System V msgget 而选 POSIX mq_open
System V 消息队列的 msgsnd 在满时同样会阻塞或失败，但它没有标准超时参数，也没法方便地设成非阻塞；更麻烦的是它依赖全局 key_t 和 IPC key 冲突风险高，ipcs -q 查到的 ID 还可能被其他进程误删。
POSIX 队列名以 / 开头（如 "/log_queue"），作用域清晰，权限可控，且 mq_send/mq_receive 原生支持 O_NONBLOCK 和 mq_timedsend——后者能真正实现“超时丢弃”，比手动 sleep + 重试靠谱得多。
真正容易被忽略的是：mq_unlink 必须在所有进程都关闭句柄后再调用，否则下次 mq_open 会失败（errno = EBUSY），这点在调试队列满问题时经常被绕过。
