咨询等待已锁定mutex与semaphore的CPU时间消耗差异

嘿，这个问题其实挺容易搞混的，咱们把它拆开来理清楚：

首先说标准实现的共同点 #

不管是Mutex还是Semaphore，按照POSIX等标准规范，当你尝试获取一个已经被锁定/占用的实例时，默认行为都是让线程进入阻塞状态——说白了就是操作系统会把这个线程从CPU的就绪队列移到专门的等待队列里，线程暂停执行，完全不会消耗CPU时间，直到锁被释放、线程被唤醒为止。

主流操作系统（Linux、Windows、macOS）的原生实现都是遵循这个逻辑的，这也是手册里明确说明的内容。

为什么会有「Mutex是忙等待」的说法？ #

这种说法其实是把可选的优化手段当成了Mutex的默认行为：

• 很多Mutex实现会加入自旋锁（Spinlock）优化：当线程发现Mutex被锁定时，不会立刻进入阻塞，而是先原地循环几次（也就是所谓的「忙等待」），看看锁会不会很快被释放。如果循环了一定次数还没拿到锁，再切换到真正的阻塞状态。
• 这么做的原因是：如果锁的持有时间非常短，自旋的开销比线程上下文切换（阻塞/唤醒的代价）要小，能提升性能。
• 划重点：Semaphore其实也可以加入同样的自旋优化，只是大家讨论Mutex时更容易提到这个细节而已。

二者在CPU消耗上的核心差异 #

• 在默认的标准实现下：等待已锁定的Mutex和Semaphore对CPU的消耗完全一致——都是线程阻塞，不占用CPU时间。
• 在带有自旋优化的场景下：不管是Mutex还是Semaphore，都会在锁短暂被持有的情况下出现短暂的CPU忙等；但如果锁持有时间较长，最终都会进入阻塞状态，不会持续消耗CPU。

关于你提到的重复问题 #

那个问题更多是聚焦在Mutex和Semaphore的功能差异（比如Mutex是互斥原语，同一时间只能被一个线程持有；Semaphore可以是计数型，支持多个线程同时获取），而你问的是等待时的CPU消耗细节，属于不同维度的问题，所以并不算完全重复。

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