如何用 Monitor.IsEntered()
检测当前线程是否已持有指定对象的锁
Monitor.IsEntered(obj)是 C# 中唯一公开、轻量且线程安全的 API，用于判断当前线程是否已通过
Monitor.Enter()（或
lock语句）获取了
obj上的互斥锁。它不阻塞、不改变锁状态，只做查询。
注意：该方法在 .NET Core 2.0+ 和 .NET 5+ 中仍可用，但微软文档明确标注为“仅供诊断和调试用途”，不可用于控制逻辑分支（比如“如果已加锁就跳过 lock”），否则会引发竞态或死锁。
必须传入与lock或
Monitor.Enter()使用的**完全相同的引用对象**，值类型装箱后不等价 返回
true仅表示当前线程已进入该对象的 Monitor（包括重入），不表示其他线程没在等 对未被任何线程锁定的对象，始终返回
false
为什么不能用 try { Monitor.Enter(obj, 0); } 来探测
试图用超时为 0 的
Monitor.TryEnter()探测锁状态是常见误区——它会尝试获取锁，若失败则释放已有锁（如果重入计数 >1）或破坏锁一致性。更严重的是：即使当前线程已持有锁，
TryEnter(obj, 0)在某些运行时版本中可能返回
false，导致误判。
正确做法永远是
Monitor.IsEntered(obj)。下面是一个典型调试场景：
object _lockObj = new object();
void LogIfLocked()
{
if (Monitor.IsEntered(_lockObj))
{
Console.WriteLine("⚠️ 正在锁内执行 —— 可能导致递归死锁");
}
}
lock
语句下无法直接调用 IsEntered
？小心编译器优化
在
lock (_lockObj) { ... } 块内部，编译器生成的 IL 会确保 Monitor.Enter/Exit成对，但
IsEntered调用本身没问题。不过要注意： 不要在
lock块里基于
IsEntered结果做同步决策（如嵌套
lock），这违反锁层次设计原则 Release 模式下 JIT 可能内联或重排，但
IsEntered是 runtime 内部原子检查，行为稳定 若对象是私有字段，确保没被外部代码误传给其他
lock，否则检测失效
替代方案：用 AsyncLocal<hashset>></hashset>
追踪异步上下文中的锁栈
当需要跨
await边界检测“是否在某锁保护的 async 方法链中”，
Monitor.IsEntered失效（因为 await 后可能切换线程）。此时可手动维护锁上下文：
static AsyncLocal<HashSet<object>> _lockContext = new AsyncLocal<HashSet<object>>();
<p>void EnterLock(object obj)
{
var set = _lockContext.Value ??= new HashSet<object>();
set.Add(obj);
}</p><p>void ExitLock(object obj)
{
var set = _lockContext.Value;
set?.Remove(obj);
}</p><p>bool IsInLock(object obj) => _lockContext.Value?.Contains(obj) == true;这个方案需你显式包装所有
lock，适合框架层或严格审计场景；普通业务代码仍应优先依赖设计约束，而非运行时检测。
真正难的不是“怎么查”，而是“查出来之后敢不敢信、敢不敢用”。生产环境里，靠
IsEntered做逻辑分支比不用锁还危险。它只该出现在日志、断言或诊断工具里。
