PowerShell中如何使用System.Threading.Monitor锁定对象/类型及跨后台Job锁失效排查？

测试结果不符合预期是两个原理性问题叠加导致的：

1. Start-Job启动的后台任务是独立操作系统进程，而非同进程内的线程
   .NET提供的[System.Threading.Monitor]、C#的lock语句都是进程内同步原语，仅能在同一个CLR运行时、同一个操作系统进程的内存空间内生效。每个后台Job都会启动独立的pwsh/powershell.exe子进程，拥有完全独立的内存空间与CLR实例：Job内对[guid]类型对象加的锁，和父进程内的[guid]是完全不同内存地址上的两个独立对象，根本无法被跨进程感知。这就是为什么TryEnter永远返回true——两边操作的根本不是同一个锁实例。
2. 所选锁对象不具备跨代码段唯一性
   哪怕在同一个进程内，拿[guid]（即System.Guid类型的Type对象）当锁对象也不是可靠方案：Type对象在进程内全局共享，很容易被其他无关代码意外获取、持锁，导致不可预期的阻塞。
3. Wait方法无限等待的原理
   Monitor.Wait的作用是释放当前持有的锁，让同进程内的等待线程进入就绪队列，等待被其他同进程线程发送信号唤醒。在跨进程的当前场景下，不存在同进程的线程会发送唤醒信号，自然会无限阻塞，和后台Job的10秒锁定期完全无关。

注：参考的技术方案适用场景为SMA自动化服务的单进程多Runspace运行环境，所有自动化任务在同一个服务进程内共享内存空间，因此进程内锁可以生效；直接将该方案套用到Start-Job的跨进程场景从原理上就不成立。

根据实际运行场景，可选择对应方案实现并行SQL访问：

• 同进程多Runspace并行（非Start-Job）场景
  首先在所有并行任务共享的作用域内定义一个唯一的固定同步对象：$syncRoot = New-Object -TypeName object。所有调用Invoke-SQLCMD的代码块通过Monitor加锁时必须传入这个共享的对象引用，且加锁逻辑必须包裹try/finally块，防止执行异常导致锁永久泄漏。注意禁止使用Type对象、字符串字面量作为锁对象。
• 跨Job/跨进程并行场景
  放弃使用进程内Monitor锁，改用操作系统级的跨进程同步原语实现串行化：
  • 使用全局命名的System.Threading.Mutex实例，所有Job和父进程统一打开同一个命名互斥体（例如Global\MyApp_SqlCmd_Lock），由操作系统内核完成跨进程的锁状态同步
  • 轻量实现方案：以固定路径的锁文件做独占访问，执行Invoke-SQLCMD前尝试以独占读写模式打开锁文件，获取不到句柄就轮询等待，执行完成后直接释放文件句柄、删除锁文件，不需要复杂的权限配置
• 从根源避免加锁的最优方案
  Invoke-SQLCMD的非线程安全问题本质是模块内部存在全局共享状态，可通过以下方式绕开：
  每个并行任务使用独立的ADO.NET连接对象，直接通过Microsoft.Data.SqlClient库创建独立的SqlConnection、SqlCommand实例，用完及时关闭释放。这种方式不存在跨任务的共享状态，天生线程安全，不需要任何额外的锁同步逻辑，并行度也不受串行化锁的限制，是大规模并行SQL处理的首选方案。

内容的提问来源于stack exchange，提问作者Ben Adams