Win32命名Mutex未及时释放 进程重启时CreateMutexW返回ERROR_ALREADY_EXISTS

该现象属于Windows内核对象的正常设计逻辑，并非操作系统Bug。
命名互斥量是Windows内核管理的内核对象，所有内核对象采用引用计数制管理生命周期，不存在和进程终止绑定的原子销毁逻辑：

• 进程被强制终止时，内核会先标记该进程持有的所有内核句柄为无效，再异步执行引用计数扣减、对象清理流程。WaitForSingleObject收到进程句柄的信号仅代表进程已停止执行、不再被CPU调度，不代表其持有的所有内核对象已经完成回收。
• 服务在进程终止后立即拉起新实例时，旧进程持有的互斥量内核对象引用计数尚未扣减到0，因此新实例调用CreateMutexW会返回ERROR_ALREADY_EXISTS。

该逻辑是Windows内核的有意设计，核心出发点是性能和接口一致性：

• 若将内核资源回收与进程终止做原子绑定，进程终止的耗时会随持有的内核对象数量线性上升，严重时会阻塞系统调度，对高并发多进程场景的性能损耗极大。
• 部分内核对象支持多进程共享持有，本身无法和单个进程绑定销毁，统一采用引用计数的异步回收逻辑可以保持内核层接口逻辑的一致性。

无需使用粗暴的固定时长Sleep，可采用以下可靠性更高的方案：

• 方案一：业务进程层逻辑优化。调用CreateMutexW返回ERROR_ALREADY_EXISTS时不直接退出，对拿到的互斥量句柄调用WaitForSingleObject设置10~50ms的超时等待：若返回值为WAIT_ABANDONED，说明该互斥量是已终止进程遗留的废弃对象，当前进程可以直接持有该互斥量正常运行，无需退出。
• 方案二：服务层拉起逻辑优化。WaitForSingleObject收到进程终止信号后，额外等待100ms以内的短时长再拉起新进程，相比在业务进程中固定Sleep 1000ms的资源占用更低，也能覆盖绝大多数场景下的内核资源回收耗时。
• 方案三：互斥量创建逻辑优化。调用CreateMutexW时将第二个参数设为TRUE（请求初始所有权），若返回已存在的错误，尝试调用ReleaseMutex后再次申请所有权，只要所有权申请成功即可判定该互斥量为废弃对象，可正常运行。

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