线程间通信延迟需用perf等系统工具定位，而非仅靠std::chrono打点；真实瓶颈常在锁争用、futex等待、虚假唤醒、NUMA缓存同步及内存分配器抖动中。
线程间通信延迟不是靠猜的，得用可测量、可复现的方式定位——它通常藏在锁争用、条件变量虚假唤醒、原子操作内存序误用或跨NUMA节点缓存同步开销里。
用 std::chrono 手动打点只能看到表层耗时
直接在共享数据读写前后加 std::chrono::high_resolution_clock::now()，容易漏掉关键等待段。比如 cv.wait() 的阻塞时间不会被“读写之间”的差值捕获；而 std::mutex::lock() 返回前的排队等待，也常被忽略。
- 只测临界区入口到出口，会把“等锁时间”算进业务逻辑里
- 没区分是调度延迟（线程被切走）、锁竞争延迟，还是内存可见性延迟
- 多线程下打点本身可能引入额外同步开销，尤其用
std::atomic记录时未指定合适memory_order
识别真实瓶颈必须结合系统级工具
Linux 下优先用 perf record -e sched:sched_switch,sched:sched_wakeup,syscalls:sys_enter_futex 抓取线程调度与 futex 等待事件。futex 是 std::mutex 和 std::condition_variable 底层依赖的系统原语，它的等待次数和时长直接反映通信阻塞程度。
-
perf script输出中频繁出现futex_wait_queue_me→ 锁竞争激烈或生产者/消费者速率严重不匹配 - 大量
sched_wakeup后紧接sched_switch但无实际执行 → 唤醒后立刻被抢占，说明 CPU 资源不足或优先级配置不当 - 用
perf report --sort=comm,symbol查看哪些线程/函数在消耗最多 futex 等待时间
std::condition_variable::wait() 的虚假唤醒和谓词检查开销常被低估
即使没有其他线程调用 notify_one()，wait() 也可能返回（POSIX 允许）。若谓词检查逻辑重（比如每次都要遍历一个容器），就会造成“空转”延迟。
- 避免在谓词中做复杂计算或访问非本地内存：把
!queue.empty() && queue.front().ready拆成两步，先查空再查状态，减少 cache line 多次加载 - 使用
wait_for()配合超时日志，确认是否真卡在等待上，还是逻辑卡在后续处理 - 如果发现
wait()返回后谓词仍为 false，说明发生了虚假唤醒——这不是 bug，是标准允许行为，必须靠循环检查兜底
跨线程传递对象时，移动语义和内存分配器影响远超预期
生产者往队列 push 一个 std::string，消费者 pop 后立即析构，看似简单。但如果字符串内部缓冲区是 new 出来的，且生产者和消费者跑在不同 NUMA 节点上，那一次“传递”实际触发了跨节点内存访问 + 缓存行迁移，延迟可达数百纳秒。
- 用
std::pmr::polymorphic_allocator绑定 per-thread 内存池，避免堆分配抖动 - 对小对象（≤ 24 字节）考虑 SSO（Short String Optimization）是否启用；大对象优先用
std::shared_ptr零拷贝传递 - 检查编译器是否对
std::move()做了 RVO 优化；未优化时，移动构造函数本身也有开销
真正难调的通信延迟，往往不在你写的 wait() 或 lock() 里，而在你没意识到的内存布局、NUMA 亲和性、以及内核 futex 实现细节中。别只盯着代码逻辑，先让 perf 告诉你线程到底在哪儿停住了。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
