看起来自旋锁并不是那么好，因为它们在等待（阻塞）时会浪费CPU周期 . 如果线程在等待唤醒信号时进入休眠状态，则在旋转时CPU周期不会丢失 .
如果把锁保持很短的时间，使用螺旋锁也许是好的，那么它可能使用更少的时间？如果这是真的么？
对，那是正确的 .
因为上下文切换很昂贵 . 操作系统和CPU必须执行（相对）大量工作才能执行上下文切换 . 相反，旋转几个周期将会便宜很多，即使这些周期在理论上被浪费了 .
当自旋锁没有阻塞时，它们会更快，这就是为什么它们在锁中争用率很低的情况下很有用（即它已被锁定的可能性很小） .
当一个线程休眠时，它会引起一个上下文切换（即，这个线程被另一个线程换掉，以便另一个线程可以运行） . 获取标准互斥锁的开销通常高于检查自旋锁是否空闲的开销 . 当锁是空闲时，螺旋锁通常只需要单个原子操作 .
这些属性使自旋锁对细粒度锁定很有用，因为使用较小的锁会减少每个锁的争用 . 例如，我的一个项目有一个 Map ，其中有大约200,000个条目同时被16个线程访问（企业服务器类型的东西） . 每个条目都有一个自旋锁是相当有效的，因为这个应用程序中的两个线程试图同时命中同一个条目的可能性很低 .
当锁定可用时，自旋锁允许紧密轮询和更快的唤醒 . @Chris指出，它们也适用于非竞争锁 . 我会说使用自旋锁：
如果您关心的只是您自己的应用程序的性能，并且不想屈服于其他应用程序，并且您的应用程序具有<=线程而不是核心数量 . 我仍然会考虑使用票证锁来优化缓存未命中但是......它们也会旋转，但会减少缓存未命中率 .
或者，如果你的锁争议较少
3 回答
对，那是正确的 .
因为上下文切换很昂贵 . 操作系统和CPU必须执行（相对）大量工作才能执行上下文切换 . 相反，旋转几个周期将会便宜很多，即使这些周期在理论上被浪费了 .
当自旋锁没有阻塞时，它们会更快，这就是为什么它们在锁中争用率很低的情况下很有用（即它已被锁定的可能性很小） .
当一个线程休眠时，它会引起一个上下文切换（即，这个线程被另一个线程换掉，以便另一个线程可以运行） . 获取标准互斥锁的开销通常高于检查自旋锁是否空闲的开销 . 当锁是空闲时，螺旋锁通常只需要单个原子操作 .
这些属性使自旋锁对细粒度锁定很有用，因为使用较小的锁会减少每个锁的争用 . 例如，我的一个项目有一个 Map ，其中有大约200,000个条目同时被16个线程访问（企业服务器类型的东西） . 每个条目都有一个自旋锁是相当有效的，因为这个应用程序中的两个线程试图同时命中同一个条目的可能性很低 .
当锁定可用时，自旋锁允许紧密轮询和更快的唤醒 . @Chris指出，它们也适用于非竞争锁 . 我会说使用自旋锁：
如果您关心的只是您自己的应用程序的性能，并且不想屈服于其他应用程序，并且您的应用程序具有<=线程而不是核心数量 . 我仍然会考虑使用票证锁来优化缓存未命中但是......它们也会旋转，但会减少缓存未命中率 .
或者，如果你的锁争议较少