monitor 是 c# 中最常用、最接近 java reentrantlock 语义的可重入锁机制，基于 .net 运行时内置同步原语实现，支持同一线程多次进入并自动维护计数，lock(obj) 是其语法糖；而 system.threading.lock（.net 5+）不可重入，适用于短临界区与高性能场景。
有，Monitor 是 C# 中最常用、也最接近 Java ReentrantLock 语义的可重入锁机制，但它不是类而是语言级构造；.NET 5+ 还提供了更显式的 System.Threading.Lock（仅限 .NET 5+），但默认不可重入。
Monitor.Enter / Monitor.Exit 是 C# 的可重入锁核心
Monitor 是 .NET 运行时内置的同步原语，支持同一线程多次进入（即重入），且自动维护计数。它不依赖 IDisposable，但推荐配合 try/finally 或 using（C# 8+ 的 lock 语法糖）使用。
-
lock(obj)本质就是Monitor.Enter(obj)+try/finally+Monitor.Exit(obj) - 同一对象上，同一线程重复
lock不会死锁，计数器递增；对应次数的Exit后才真正释放锁 - 注意：
Monitor锁的是引用对象的“同步块索引”，不是对象内容或类型；多个线程对同一实例lock才互斥 - 不要用
string、装箱值类型或常量作为锁对象——它们可能被池化或共享，导致意外锁竞争
Monitor.TryEnter 可实现带超时的可重入尝试
当需要避免无限等待时，Monitor.TryEnter 比直接 lock 更灵活，且仍保持可重入特性。
object syncRoot = new object();
if (Monitor.TryEnter(syncRoot, TimeSpan.FromMilliseconds(100)))
{
try
{
// 临界区
if (Monitor.TryEnter(syncRoot, 0)) // 同一线程再次进入：成功，计数+1
{
try
{
// 嵌套临界区
}
finally
{
Monitor.Exit(syncRoot);
}
}
}
finally
{
Monitor.Exit(syncRoot);
}
}
else
{
// 获取锁失败
}-
TryEnter(obj, timeout)返回bool，超时前未获取到则返回false - 即使在
TryEnter成功后，后续同一线程的TryEnter（无论 timeout=0 或 >0）仍会成功并增加重入计数 - 必须严格配对
Exit，否则锁不会完全释放，其他线程将永久阻塞
System.Threading.Lock（.NET 5+）不是可重入的
System.Threading.Lock 是为高性能、低分配场景设计的结构体锁，但它明确不可重入：同一线程重复 Lock.Enter 会抛出 InvalidOperationException。
本文档主要讲述的是Android JNI开发入门与提高；JNI在Android系统中有着广泛的应用。Android系统底层都是C/C++实现的，上层提供的API都是Java的，Java通过JNI调用底层的实现。比如：Android API多媒体接口MediaPlayer类，其实底层通过JNI调用libmedia库。希望本文档会给有需要的朋友带来帮助；感兴趣的朋友可以过来看看
立即学习“Java免费学习笔记（深入）”；
- 适用场景：短临界区、已确保无嵌套调用、追求极致性能（避免堆分配和 Monitor 内部哈希查找）
- 若业务逻辑天然存在递归或间接重入（比如 A 调 B，B 又 lock 同一资源），用它会直接崩溃
- 没有等价于
ReentrantLock.isHeldByCurrentThread()的检查方法；也不支持条件变量（Condition）
自定义 ReentrantLock 类需谨慎权衡
虽然可以用 Monitor 封装一个类似 Java ReentrantLock 的 API（如 lock()/unlock()、isHeldByCurrentThread()），但实际极少必要。
- .NET 生态中绝大多数并发控制靠
lock、Monitor、AsyncLock（如Microsoft.Extensions.DependencyInjection中的异步锁）或无锁结构（ConcurrentDictionary等）解决 - 手动维护持有线程 ID 和计数容易出错，尤其在异步上下文（
async/await）中，线程切换会导致Thread.CurrentThread.ManagedThreadId不一致 - 若真需类似 Java 的显式锁 API（比如公平性、中断响应、条件队列），应优先评估是否能用
System.Threading.SemaphoreSlim（支持 async、可取消）替代
真正容易被忽略的是：可重入 ≠ 安全。哪怕 Monitor 允许重入，如果锁粒度太粗、嵌套过深或跨 await 边界持有，依然会导致死锁、响应延迟或上下文丢失。写锁逻辑时，先想清楚“谁要等谁”，再决定用哪一层抽象。
