Mutex（互斥体）是.NET中功能最强大的同步原语之一，它属于System.Threading命名空间，继承自WaitHandle。与常见的lock语句和Monitor类相比，Mutex最大的特点是支持跨进程的互斥访问，也就是说两个不同的进程可以通过一个命名Mutex协调对同一资源的独占访问。本文将从基本用法、跨进程应用、与其他同步方式的对比以及常见陷阱四个方面，系统地讲解Mutex的使用方法。
Mutex的基本原理与WaitOne和ReleaseMutex的配对使用
Mutex的核心思想非常直观：同一时刻只有一个线程可以持有它。线程通过调用WaitOne()方法请求所有权，如果Mutex当前无人持有，线程立即获得所有权并继续执行；如果已被其他线程持有，当前线程就会被阻塞，直到Mutex被释放。持有Mutex的线程在访问完共享资源后，必须调用ReleaseMutex()方法释放所有权，让其他等待的线程有机会获取它。
这里有一个非常重要的规则：ReleaseMutex只能由当前持有Mutex的线程调用。如果其他线程尝试释放，会抛出ApplicationException。这与Monitor不同，Monitor的Exit虽然也要求同一线程释放，但Mutex作为内核对象，其所有权的管理更加严格。来看一个基础示例：
using System;
using System.Threading;
class Program
{
// 第一个参数为true表示创建线程立即获得所有权
private static Mutex _mutex = new Mutex(false);
static void Main()
{
for (int i = 0; i < 5; i++)
{
Thread t = new Thread(DoWork);
t.Name = "线程-" + i;
t.Start();
}
Console.ReadLine();
}
static void DoWork()
{
Console.WriteLine($"{Thread.CurrentThread.Name} 等待获取Mutex");
// 请求所有权，未获取到则阻塞
_mutex.WaitOne();
try
{
Console.WriteLine($"{Thread.CurrentThread.Name} 已进入临界区");
Thread.Sleep(1000); // 模拟耗时操作
}
finally
{
// 必须在finally中释放，避免异常导致Mutex被永久占用
_mutex.ReleaseMutex();
Console.WriteLine($"{Thread.CurrentThread.Name} 已释放Mutex");
}
}
}这段代码中有两个细节值得注意。第一，构造函数new Mutex(false)中的布尔参数是initiallyOwned，如果传true表示创建该Mutex的线程立即拥有它，其他线程必须等它释放后才能进入。传false则所有线程公平竞争。第二，ReleaseMutex放在finally块中是必须养成的习惯，因为一旦临界区代码抛出异常而未释放Mutex，其他线程将永远等待下去，造成整个应用卡死。
使用命名Mutex实现跨进程同步与单实例应用
匿名Mutex（即不带名字参数创建的Mutex）只能在当前进程内使用，作用和lock差不多，但性能更差。Mutex真正的价值在于命名Mutex。给Mutex指定一个全局唯一的名称后，操作系统会保证所有进程中使用相同名称创建的Mutex引用的是同一个内核对象，这样就实现了跨进程的互斥。命名规则上，普通名称如MyAppMutex只在当前会话中有效，如果希望跨会话（例如多个终端服务用户之间）互斥，需要使用Global\前缀，例如Global\MyAppMutex。
命名Mutex最经典的应用场景就是单实例程序：程序启动时尝试获取一个命名Mutex，如果发现已有另一个实例在运行，就提示用户并退出。下面是完整实现：
using System;
using System.Threading;
class Program
{
static void Main()
{
bool createdNew;
// out参数返回该Mutex是否由当前进程新建
using (Mutex mutex = new Mutex(true, "Global\\MyUniqueAppMutex", out createdNew))
{
if (!createdNew)
{
Console.WriteLine("程序已在运行，请勿重复启动！");
Console.ReadLine();
return;
}
Console.WriteLine("程序启动成功，按回车键退出...");
Console.ReadLine();
// using结束时会自动调用ReleaseMutex和Close
}
}
}这个例子中第三个参数createdNew非常关键，它告诉我们这个命名Mutex是当前进程新建的，还是已经存在的。如果已存在，说明有另一个实例正在运行。另外要说明一点：如果构造时第一个参数传了true且Mutex已存在，构造函数不会抛异常，但当前线程并不拥有它，此时调用WaitOne会被阻塞，所以判断单实例时应依赖createdNew而不是依赖所有权状态。
除了单实例控制，命名Mutex还常用于保护多个进程共同访问的文件、数据库或硬件设备。例如一个后台服务和一个桌面程序都要写入同一个日志文件，就可以约定一个Mutex名称，各自在写入前获取、写入后释放，从而避免内容交叉混乱。
Mutex与Monitor、Semaphore的区别及选型建议
在.NET中有多种同步手段，选错工具往往带来性能损失或逻辑缺陷，因此有必要厘清它们之间的区别。Monitor（也就是lock语句的底层实现）是进程内的托管对象，通过自旋加内核等待实现，开销较小，适合单进程内的线程互斥。Mutex是内核对象，每次获取和释放都要陷入操作系统内核，开销明显大于Monitor，但换来了跨进程能力。Semaphore则允许指定数量的线程同时进入临界区，适合限制并发数的场景，比如最多允许5个线程同时访问某个连接池。
三者的核心差异可以用下表概括：
| 特性 | Monitor/lock | Mutex | Semaphore |
|---|---|---|---|
| 作用范围 | 单进程 | 可跨进程 | 可跨进程（命名时） |
| 允许并发数 | 1 | 1 | N（可配置） |
| 性能开销 | 低 | 较高（内核对象） | 较高（内核对象） |
| 支持等待超时 | 支持（TryEnter） | 支持（WaitOne重载） | 支持 |
| 典型场景 | 进程内保护共享字段 | 跨进程互斥、单实例程序 | 限制并发连接数 |
根据经验，如果只是单进程内的线程安全，优先使用lock，简单高效；只有在确实需要跨进程互斥时才使用Mutex；而需要控制并发数量而非独占访问时选择Semaphore或SemaphoreSlim。另外补充一点，Mutex支持递归获取：同一线程可以多次调用WaitOne而不会死锁，但必须调用相同次数的ReleaseMutex才能真正释放。
常见陷阱：AbandonedMutexException与死锁防范
使用Mutex时最容易遇到的问题是AbandonedMutexException。当一个线程持有Mutex时未释放就终止了（比如进程崩溃或线程异常退出），操作系统会自动将Mutex标记为废弃状态，下一个等待该Mutex的线程在WaitOne返回时会收到这个异常。很多开发者以为这是致命错误，实际上它同时意味着当前线程已经获得了Mutex的所有权，正确的处理方式是在catch中判断状态并进行资源校验或修复，然后正常释放：
try
{
_mutex.WaitOne();
}
catch (AbandonedMutexException)
{
// 前一个持有者异常退出，当前线程已获得Mutex
Console.WriteLine("检测到废弃的Mutex，共享资源状态可能不一致，需校验");
}
finally
{
try
{
_mutex.ReleaseMutex();
}
catch (ApplicationException)
{
// 当前线程不拥有Mutex时Release会抛此异常
}
}死锁也是需要重点防范的问题。如果两个线程各自持有一个Mutex并互相等待对方释放，就会永久阻塞。预防方法包括：为所有Mutex规定统一的获取顺序；使用带超时的重载WaitOne(TimeSpan.FromSeconds(5))，超时后返回false，此时应主动释放已持有的Mutex并重试或放弃；尽量避免在持有Mutex时执行耗时操作或调用未知的外部代码。
最后还需要注意正确释放资源。Mutex实现了IDisposable接口，用完应调用Close或放在using块中，确保内核句柄及时归还。特别是在长时间运行的服务程序中，频繁创建Mutex而不释放会导致句柄泄漏，最终拖垮整个进程。掌握这些细节后，Mutex就能在跨进程同步场景中稳定可靠地发挥作用。