互斥锁错误是否会抛出异常？场景验证未达预期疑问

嘿，这个问题我之前踩过坑，刚好对C++ mutex的异常逻辑有点研究，来跟你唠唠～

首先先明确标准里mutex操作可能抛出的异常对应的错误码：

• resource_deadlock_would_occur：系统检测到死锁风险时抛出
• resource_unavailable_try_again：资源暂时不可用，建议重试
• operation_not_permitted：当前线程无权限执行锁定操作
• device_or_resource_busy：目标资源已被占用/锁定
• invalid_argument：传入的mutex参数无效

你提到用了Stroustrup著作里的两个测试场景，但都没触发预期异常？这其实是因为标准对mutex的异常抛出有严格的限定，不是所有场景都会按直觉抛异常，我拆解下两个场景的问题：

一、死锁场景未触发resource_deadlock_would_occur #

首先要搞清楚：普通std::mutex的lock()是阻塞式调用，它不会主动检测死锁——只有当你使用std::lock()函数（用来原子性地锁定多个互斥量），且系统能提前检测到循环等待的死锁条件时，才会抛出这个异常。

举个例子：如果你是手动嵌套锁定两个mutex（比如线程1先lock m1再lock m2，线程2先lock m2再lock m1），这种情况下普通的lock()只会让线程一直阻塞，不会抛异常，因为系统没法提前检测到这种运行时才会出现的死锁。只有用std::lock(m1, m2)这种原子锁定多个互斥量的函数，当内部检测到死锁风险时，才会抛出resource_deadlock_would_occur。

二、重复锁定同一互斥锁未触发device_or_resource_busy #

这里核心是mutex的类型和标准定义的行为：

• 普通std::mutex重复调用lock()属于未定义行为，程序可能直接崩溃、卡死，或者出现其他奇怪的状况，但标准不会要求它抛出任何异常；
• std::recursive_mutex允许同一线程重复锁定，但它也不会抛出device_or_resource_busy——这个错误码对应的异常，更多是在平台特定的实现里出现（比如POSIX线程的pthread_mutex_lock，当尝试重复锁定非递归mutex时会返回EBUSY），但C++标准并没有强制要求普通mutex要抛出这个异常。

Stroustrup的例子可能是基于特定平台（比如早期的UNIX系统）或者特定的标准库实现，放到现在的通用编译器（比如GCC/Clang）上，可能因为标准库遵循C++标准的未定义行为，所以不会抛出预期的异常。

几个验证方向 #

如果你想复现预期的异常，可以试试这些调整：

• 对于死锁场景：改用std::lock()函数同时锁定多个互斥量，而不是手动逐个调用lock()；
• 对于重复锁定场景：使用平台特定的mutex API（比如pthread_mutex_t），或者尝试std::timed_mutex的try_lock_for()方法（某些平台会在锁定失败时抛出对应异常）；
• 检查你的标准库实现：不同的libstdc++/libc在异常映射上可能有差异，比如某些版本会把POSIX的错误码转换为C异常抛出。

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