测锁延迟关键在于真实争用下的等待时间，而非单次纳秒级抖动；需用高精度挂钟测量阻塞延迟、构造可控争用、区分锁类型特征，并统计延迟分布（p50/p90/p99）及上下文切换。
测锁延迟，关键不是“跑一次看耗时”，而是让测试反映真实争用下的响应行为。单纯用 Stopwatch 或 clock_gettime 测单次加锁/解锁，结果几乎都是纳秒级抖动，没实际参考价值。真正有意义的延迟，是线程在竞争激烈时“等待获得锁”的时间——也就是排队+上下文切换+调度带来的可观测延迟。
聚焦真实等待延迟：避免 clock() 和 CPU 时间陷阱
很多测试误用 clock() 或 GetTickCount64()，它们要么累计所有线程 CPU 时间（并行下严重高估），要么精度不足（毫秒级无法捕捉微秒级锁争用）。正确做法是：
- 用高精度挂钟时间（如 Windows 的
QueryPerformanceCounter，Linux 的clock_gettime(CLOCK_MONOTONIC, ...)）测量端到端操作耗时 - 将“等待锁”环节单独剥离：例如在
Monitor.Enter前打点，进入临界区后打点，差值即为实际阻塞延迟 - 禁用 JIT 优化干扰（如用
[MethodImpl(MethodImplOptions.NoOptimization)]包裹关键路径）
构造可控争用：让延迟“浮出水面”
低并发下所有锁都快，差异被掩盖。要测出延迟差异，必须制造持续、可调的资源争用：
- 固定共享资源（如一个
int counter），让全部线程反复争夺同一把锁 - 线程数 ≥ CPU 核心数（例如 16 线程跑在 8 核机器上），确保调度器必须排队
- 临界区保持极短（如仅执行
counter++），避免掩盖锁本身开销 - 每轮测试重复足够次数（如 10 万次/线程），再统计延迟分布（P50/P90/P99），而非只看平均值
区分锁类型对应的延迟特征
不同锁机制的延迟表现逻辑不同，测试时需对应设计：
- mutex / lock / Monitor：延迟主要来自内核态阻塞和唤醒，P99 延迟易飙升（毫秒级），尤其在线程数远超核心数时
- 自旋锁（SpinLock）：无上下文切换，但空转消耗 CPU；延迟稳定在百纳秒级，P99 接近 P50，但高负载下可能推高整体 CPU 使用率
- 原子操作（如 Interlocked.Increment）：无锁、无等待，延迟恒定在 10–50 纳秒，适用于简单计数等场景
- ReaderWriterLockSlim：读多写少时读延迟极低（接近原子操作），但写操作会清空所有读线程，引发突发性长延迟（写等待期间所有新读请求也被阻塞）
记录与分析：不止看平均值
延迟不是单一数字，而是一个分布。建议记录每次获取锁的耗时，生成直方图或分位数报告：
- P50（中位数）：反映典型情况
- P90 / P95：反映多数请求体验
- P99 / P999：暴露尾部延迟问题——对实时系统、高频交易尤为致命
- 同时监控线程上下文切换次数（如 Linux
perf stat -e context-switches），高切换往往意味着 mutex 类锁在频繁休眠/唤醒
