Monitor.IsEntered 是什么，能用来判断锁状态吗？
Monitor.IsEntered是一个静态方法，用于检查当前线程是否已对指定对象获取了
Monitor锁（即是否已执行过
Monitor.Enter且尚未配对调用
Monitor.Exit）。但它**不能安全用于同步逻辑判断**——它只反映“当前线程是否持有该对象的 Monitor 锁”，不反映其他线程是否持有、是否正在等待、或锁是否已被释放。
常见误用是想靠它实现“如果没锁就加锁”，类似：
if (!Monitor.IsEntered(obj)) { Monitor.Enter(obj); } 这种写法存在竞态：IsEntered返回
false后，另一线程可能立刻
Enter，导致本线程仍会阻塞在后续
Enter上，且无法保证原子性。
真正可用的典型场景：调试与异常恢复
它的实用价值集中在开发期诊断和极少数需要“自救”的异常处理中。例如在
finally块里做防御性
Exit，但又不确定是否真的
Enter过： 避免因重复
Exit抛出
SynchronizationLockException在
catch中尝试清理锁时防止崩溃 日志记录当前线程锁持有状态，辅助排查死锁
示例（安全的 finally 清理）：
object lockObj = new object();
try
{
Monitor.Enter(lockObj);
// 可能抛异常的临界区操作
}
finally
{
if (Monitor.IsEntered(lockObj))
Monitor.Exit(lockObj);
}
为什么不能替代 lock 关键字或 try/finally 模式？
lock(obj) { ... } 编译后自动展开为带 try/finally的
Monitor.Enter/Exit，确保即使异常也能释放锁。
Monitor.IsEntered本身不参与任何同步语义，它既不加锁也不放锁，也不影响其他线程行为。
使用它来“绕开”标准锁模式，往往意味着逻辑已变得难以追踪。尤其要注意：
它返回true仅当本线程对同一对象调用了
Enter且未
Exit；嵌套
Enter也会返回
true，但
Exit必须配对次数才能完全释放 它对
async方法无效——
await后续可能在不同线程执行，
IsEntered在新线程上永远返回
false.NET 6+ 中，
Monitor对不可重入锁做了更多优化，但
IsEntered行为未变，依然不提供跨线程可见性保证
替代方案建议：优先用 lock，复杂需求考虑 SemaphoreSlim
绝大多数需要“条件加锁”或“尝试加锁”的场景，应直接使用更明确的原语：
需要非阻塞尝试：用Monitor.TryEnter(obj, 0)或
Monitor.TryEnter(obj, timeout)需要异步等待：改用
SemaphoreSlim.WaitAsync()（注意它不是
Monitor的替代，但支持 async） 需要可重入控制：自行用
ThreadLocal<int></int>+ 计数管理，或评估是否真需可重入（多数情况不需要）
Monitor.IsEntered留给调试输出或极端兜底清理即可，把它当成生产代码里的控制分支，基本等于给并发问题埋雷。真正棘手的是锁粒度、持有时间、以及跨 await 的上下文丢失——这些它一个都帮不上忙。
