Linux多线程性能瓶颈常源于高频锁竞争与伪共享，优化需减少争抢：用perf/pidstat定位调度与缓存问题，细化锁粒度、改用原子操作和读写锁，对齐变量防伪共享，并绑定CPU提升缓存局部性。
Linux 下多线程程序 CPU 利用率低、响应变慢，往往不是因为线程数不够，而是线程间存在高频竞争——尤其是对共享资源（如锁、计数器、缓存行）的争抢，导致大量线程阻塞、上下文频繁切换、CPU 缓存失效。优化核心在于“减少争抢”，而非单纯增加线程。
定位真实瓶颈：别只看 top 的 %CPU
高 %CPU 不代表高效，可能是自旋等待或锁竞争；低 %CPU 也不代表空闲，可能是线程在 futex 等待中“假死”。关键要看：
- 使用 perf record -e sched:sched_switch,sched:sched_stat_sleep -g 捕获调度事件，观察线程是否频繁进出睡眠/就绪态
- perf record -e cycles,instructions,cache-misses,cpu-cycles:u 查看用户态缓存未命中率（>5% 值得警惕）
- cat /proc/[pid]/status | grep -E 'thr|vol'| grep -v nonvol 看自愿（voluntary）上下文切换次数——若远高于非自愿切换，说明线程主动让出 CPU（如锁等待、cond_wait）
- 使用 pidstat -t -w 1 观察每个线程的 cswch/s（每秒上下文切换）和 nvcswch/s（非自愿切换），突增项即热点线程
锁粒度与替代方案：从 mutex 到无锁设计
全局互斥锁是常见性能杀手。优化方向是“缩小临界区 + 避免锁”：
- 将大锁拆为多个细粒度锁（如哈希分桶锁），按 key 分片保护，使不同线程操作不同数据时不互斥
- 用读写锁（pthread_rwlock_t）替代 mutex，当读多写少时显著提升并发吞吐
- 对计数类场景，优先使用原子操作（__atomic_add_fetch、__atomic_load_n）而非锁；GCC 内建原子函数比 pthread_mutex 更轻量
- 高频小对象分配可换用线程本地内存池（如 tcmalloc 的 per-CPU cache 或自实现 slab allocator），避免 malloc/free 全局锁
CPU 缓存友好性：避免伪共享（False Sharing）
多个线程修改同一缓存行（通常 64 字节）中的不同变量，会引发缓存行在核间反复无效化，性能骤降。典型场景：
- 结构体中相邻定义的计数器被不同线程更新（如 struct { int a; int b; } stats[2]; 线程0改a、线程1改b）
- 数组元素按索引分配给线程，但步长过小（如 1）导致不同线程访问相邻元素
解决方法：
- 用 __attribute__((aligned(64))) 对热点变量强制 64 字节对齐，隔离缓存行
- 结构体内变量按访问频率/线程归属分组，并插入 padding（如 char pad[64]）
- 数组访问采用 stride ≥ 64 字节（如每线程处理间隔 16 个 int），或使用 per-thread 本地缓冲再批量合并
调度与亲和性：让线程“各守其核”
默认调度下线程可能在 CPU 间频繁迁移，破坏缓存局部性。合理绑定可降低迁移开销：
- 用 taskset -c 0-3 ./app 启动进程限定 CPU 范围；或运行中用 taskset -cp 2 [pid] 绑定线程
- 在代码中调用 pthread_setaffinity_np() 将工作线程固定到特定核，配合 CPU_SET 宏管理掩码
- 注意：绑定前确保负载均衡——避免某些核满载、其余空闲；可用 numactl --cpunodebind=0 --membind=0 同时约束 CPU 和内存节点
- 慎用 SCHED_FIFO/RR 实时策略，除非确定无其他高优任务干扰，否则易引发系统卡顿
