drd能发现锁粒度太大、锁使用不规范和潜在竞态访问三类问题；它关注posix锁生命周期与占用时长，而非内存访问顺序。
DRD能发现哪些多线程问题
DRD 主要定位三类问题：锁粒度太大（比如一个 pthread_mutex_lock 包裹了耗时 I/O 或 sleep）、锁使用不规范（如重复 pthread_mutex_lock 同一把锁、未配对 unlock）、以及潜在的竞态访问（多个线程读写同一变量但无同步）。它不像 Helgrind 那样强调“数据竞争”的内存访问顺序，而是更关注 POSIX 锁本身的生命周期和占用时长。
编译和运行前必须做的两件事
DRD 只能分析带调试符号、且未被过度优化的程序。否则它无法映射到源码行，也容易漏报锁行为。
- 编译时加
-g，确保生成调试信息；禁用优化（-O0），避免编译器把锁合并、消除或重排 - 链接时显式加上
-lpthread，哪怕你用了 C++11std::thread—— 因为底层仍是 pthread 实现，DRD 依赖对 pthread 符号的拦截 - 不要用
kill -9中断程序，DRD 需要正常退出才能汇总锁统计；测试中用Ctrl+C或让程序自然结束
用 --exclusive-threshold 快速定位慢锁
这是 DRD 最实用的参数。它不是报错，而是提示：“这个锁独占时间太长，可能拖慢并发”。比如：
valgrind --tool=drd --exclusive-threshold=5 ./myapp
当某个 pthread_mutex_lock 持有超过 5ms，DRD 就会在日志里打出类似：
==12345== Thread 2: lock of mutex at 0x... held for 12.3 ms (exceeds threshold of 5 ms)
注意点：
-
--exclusive-threshold单位是毫秒，不是微秒或秒；设太小（如 0.1）会刷屏，设太大（如 100）可能漏掉关键瓶颈 - 它只统计「互斥锁」和「写锁」的持有时间，读锁（
pthread_rwlock_rdlock）不计入 - 如果锁内调用了系统调用（如
read()、nanosleep()），DRD 会把整个阻塞时间算进去——这正是你要优化的地方
DRD 日志里最该盯住的三行
每次看到警告，立刻查这三行：
-
at 0x...: my_func (my_file.cpp:42)—— 锁是在哪一行加上的？不是 unlock，是 lock 的位置 -
by 0x...: pthread_mutex_lock (in /usr/lib/...)—— 确认确实是 pthread 原生锁，排除自定义封装干扰 -
held for X.X ms—— 数值是否明显超出业务预期？比如一个计数器更新不该花 8ms，那大概率里面混进了日志、网络或磁盘操作
真正难的是锁嵌套和跨函数调用场景：一个 lock 在 A 函数，unlock 在 B 函数，中间还调了 C 函数。DRD 不会自动帮你画调用链，得靠日志里的地址 + addr2line -e ./myapp 0x... 手动反查。
