优化多线程锁竞争的核心是降低争抢概率、缩短持有时间、减少无效等待，并依场景选用轻量同步机制；需精简临界区、避免锁内阻塞操作、按访问模式选锁类型。
优化多线程程序的锁竞争开销，核心不是“少用锁”，而是让锁不成为瓶颈——即降低争抢概率、缩短持有时间、减少无效等待，并在合适场景换用更轻量的同步机制。
精简临界区，缩短锁持有时间
锁开销大，往往是因为临界区代码执行太久。哪怕只多几微秒，高并发下就会引发排队雪崩。
- 把纯计算、IO、日志打印等非共享操作移出加锁范围；只对真正读写共享变量的部分加锁
- 避免在锁内调用可能阻塞的函数（如
malloc、printf、网络收发） - 若需批量处理，可先在锁外收集数据，再一次性加锁更新状态
按访问模式选对锁类型
不是所有场景都适合pthread_mutex_t。读多写少时，读写锁能显著降低读线程间竞争；无锁竞争预期时，自旋锁更省上下文切换。
-
读多写少：用
pthread_rwlock_t，允许多个读线程并发，但写仍独占 - 临界区极短（：考虑
pthread_spinlock_t，避免线程休眠唤醒开销 -
需要无锁编程能力：对计数器、队列头尾等简单结构，可用
__atomic_fetch_add或CAS指令替代锁
拆分锁粒度，避免“一把大锁”保护全局
用一个锁保护整个任务队列或哈希表，是典型瓶颈来源。细粒度分段能大幅缓解争抢。
- 将大哈希表按桶分组，每组配独立互斥锁（分段锁）
- 线程池中，任务队列与空闲线程通知可分离：用不同锁或条件变量解耦生产与消费路径
- C++中慎用全局
std::mutex，优先为每个对象实例维护专属锁（如每个连接对象持有一个锁）
用 perf 定位真实锁热点
凭经验猜锁瓶颈容易误判。perf 可直接看到哪条调用路径在等锁、等多久、被谁阻塞。
- 先用
ps -T -p <pid>获取目标线程TID - 采集调度事件：
sudo perf record -e sched:sched_stat_blocked,sched:sched_switch -p <tids> sleep 10 - 分析阻塞源头：
perf script | awk '$3 ~ /blocked/ {print $NF}' | sort | uniq -c | sort -nr | head -5 - 若高频出现
__lll_lock_wait或pthread_cond_wait，且对应符号集中于某把锁（如g_task_mutex），就确认是该锁争抢点
