锁内执行std::cout或write()会拖慢线程池，因阻塞式io可能挂起当前线程数十微秒至毫秒，而std::mutex排他不可重入，导致其他线程在锁外长时间等待。
为什么锁内做 std::cout 或 write() 会拖慢整个线程池
因为 IO 操作（尤其是阻塞式）可能挂起当前线程数十微秒到毫秒级，而互斥锁 std::mutex 是排他且不可重入的——只要一个线程卡在 std::cout 上，其他所有等待该锁的线程就全被堵住。这不是 CPU 跑得慢，是“大家排队等一个人慢慢写日志”。
- 典型现象：
top显示 CPU 利用率很低，但程序吞吐量上不去，perf record -e sched:sched_switch能看到大量线程在 mutex 上频繁切换 - 根本原因：锁的粒度和 IO 的不确定性不匹配——锁本该保护共享数据结构，却被迫承担了设备延迟
-
std::cout还额外带流缓冲同步开销，在多线程下默认加锁，等于“锁中套锁”
把日志/IO 移出锁区的三种实操方式
核心原则：锁里只做内存操作（读/写变量、更新计数器、修改指针），所有涉及文件、网络、终端的操作一律放到锁外。
- 先拷贝再输出：在锁内只读取关键字段到局部变量，比如
auto val = shared_counter.load();，解锁后再std::cout - 批量攒取 + 异步刷盘：用无锁队列（如
boost::lockfree::queue或自研环形缓冲）收集日志字符串，由单独线程消费并写文件 - 用原子类型替代锁保护简单状态：如果只是记录“是否完成”，直接用
std::atomic_bool done{false};，完全绕过锁，自然也不存在锁内 IO
std::mutex 和 std::shared_mutex 对 IO 延迟的敏感度差异
很多人以为换成读写锁就能缓解，其实不然：std::shared_mutex 的写锁仍是排他阻塞的，只要有一个线程在锁内调 write()，所有读写请求照样排队。它只对“读多写少+纯内存读”场景有效。
- 写锁路径和
std::mutex几乎一样长，IO 延迟照样传导给所有竞争者 - 如果真要用
std::shared_mutex，必须确保 write lock 区域绝对不含任何系统调用——连std::time(nullptr)都建议移到锁外（某些实现会触发时钟系统调用） - 更现实的选择：用
std::atomic+ CAS 循环更新状态，或改用folly::MPMCQueue这类专为高并发日志设计的无锁结构
调试时怎么快速定位锁内 IO 问题
别靠猜。Linux 下用 perf + stackcollapse-perf.pl 看热点栈帧最直接：
perf record -e cycles,instructions,syscalls:sys_enter_write -g -- ./my_program perf script | stackcollapse-perf.pl | flamegraph.pl > fg.svg
如果火焰图里出现类似 std::ostream::operator → <code>write → __libc_write 嵌套在 pthread_mutex_lock 下方，就是铁证。
- 用
strace -f -e trace=write,writev,pwrite64 -p $(pidof my_program)观察 write 是否集中在某几个线程 PID 上 - 加编译期断言：在锁内调用 IO 函数的地方插一句
static_assert(!std::is_same_v<decltype std::ostream>, "IO in critical section!");</decltype>（虽不能拦 runtime，但能提醒协作者）
真正难的不是发现，而是说服自己接受“日志不是实时的”——多数业务场景下，10ms 内落盘的日志和立刻打印到终端的日志，语义上并无区别。把 IO 从锁里摘出来，往往比优化算法更能提升吞吐。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
