Monitor.TryEnter 需超时参数以防无限阻塞：超时为0即瞬时尝试，负数等价于无超时（不推荐），单位毫秒；其内部自旋由CLR自动控制且不可干预，需手动组合SpinWait与TryEnter(0)实现可控重试。
Monitor.TryEnter 为什么需要超时参数
不加超时的 Monitor.Enter 会无限阻塞，一旦锁被长期占用（比如持有锁的线程崩溃、死锁或执行过久），调用方就彻底卡住，无法响应、无法释放资源、无法优雅降级。而 Monitor.TryEnter(object, int) 的超时能力，本质是给同步操作加了一道“安全阀”——它让线程最多等待指定毫秒数，超时后直接返回 false，而不是死等。
常见错误现象包括：服务接口偶发长时间 hang、后台任务线程池耗尽、健康检查失败但无明确异常日志——这些背后往往藏着未设超时的 Monitor.Enter。
- 超时值为
0表示“只尝试一次，不等待”，类似自旋检测，成功则返回true，否则立刻返回false - 超时值为负数（如
-1）等价于无超时的Monitor.Enter，**不推荐使用** - 超时单位是毫秒，不是 ticks 或秒；传入
1000就是 1 秒，不是 1000ms 的近似值
Monitor.TryEnter 的自旋行为到底由谁控制
Monitor.TryEnter 本身不暴露自旋开关，它的自旋逻辑是 .NET 运行时内部实现的，且仅在特定条件下触发：当锁处于“轻量级”状态（即无竞争或刚释放）、且等待时间极短（通常几微秒内）时，CLR 可能先做几次 CPU 自旋（spin-wait），再转入真正的内核等待。这个过程对开发者透明，也无法通过参数干预。
这意味着你不能靠 TryEnter 实现可控的自旋重试策略。如果业务需要“最多自旋 100 次，每次 10 微秒，失败再退避”，必须手动写循环 + Thread.SpinWait + TryEnter(0) 组合：
bool acquired = false;
for (int i = 0; i < 100 && !acquired; i++)
{
acquired = Monitor.TryEnter(lockObj, 0);
if (!acquired)
Thread.SpinWait(10);
}
if (!acquired)
{
// 转入带超时的等待，或放弃
acquired = Monitor.TryEnter(lockObj, 50);
}
注意：Thread.SpinWait(n) 中的 n 是提示值，实际时长由 CPU 频率和调度决定，不可精确控制。
超时值设多大才合理
没有通用答案，取决于临界区执行时间和系统 SLA。设得太小会导致频繁抢锁失败，设得太大又失去超时意义。关键判断依据是：「这个锁保护的操作，在正常情况下应该多久完成？」
- 纯内存操作（如修改几个字段）→ 通常
1–10 ms足够，超时可设50ms - 涉及简单 IO 缓存读取（如
ConcurrentDictionary查找）→ 建议100ms 起步 - 任何可能触发 GC、远程调用、磁盘访问的临界区 → 不该放在
Monitor里，应重构；若必须，超时至少设为该操作 P95 延迟的 2–3 倍 - 永远不要设成
Timeout.Infinite（即-1）——它等于放弃超时保障
TryEnter 返回 false 后的典型误操作
很多开发者把 TryEnter 当成“尽力而为”，返回 false 就直接跳过逻辑，导致数据不一致或功能缺失。更危险的是在 false 后仍继续访问被保护资源：
if (Monitor.TryEnter(_lockObj, 100))
{
try
{
_sharedCounter++; // 安全
}
finally
{
Monitor.Exit(_lockObj);
}
}
else
{
_sharedCounter++; // ❌ 危险！未持锁就修改
}
正确做法只有三种：
- 明确允许“跳过”（如日志缓冲刷写失败可丢弃）→ 确保跳过逻辑本身无副作用
- 降级到其他同步机制（如用
SpinLock或无锁结构） - 抛出异常或返回错误码，让上层决定重试/熔断/告警
最容易被忽略的一点：超时不是性能问题的遮羞布。如果 TryEnter(..., 100) 频繁返回 false，说明锁争用已成瓶颈，该优化临界区代码、拆分锁粒度，而不是不断调高超时值。
