上下文切换开销和同步开销之间的关系？答案

【问题标题】：Relationship between context swich overhead and synchronization overhead?上下文切换开销和同步开销之间的关系？
【发布时间】：2015-01-22 19:32:19
【问题描述】：

我想了解一个简单的场景，其中有这么多线程竞争同步共享资源。只有一个线程肯定会获得资源锁，所有其他线程必须等待，现在在资源可用性上，每个等待线程将再次尝试获得锁，如果失败则再次暂停以进行下一次尝试。这种情况是否不会增加上下文切换开销，因为线程一次又一次地暂停和恢复以获取资源。我只是想问一下，1）同步开销和上下文切换开销之间是否存在直接比例关系 2）在任何算法中通过锁引入更多共享变量会增加上下文切换开销，即共享资源的数量和上下文切换开销

我说的对吗？

现在我的第二个问题是“如果在上述场景中使用非阻塞算法进行同步，即如果将原子变量用作共享资源，那么在原子共享资源的情况下上下文切换开销的影响是什么”。共享资源的竞争线程是否不会暂停或恢复，即如何处理这种非阻塞同步现象？

【问题讨论】：

这似乎是家庭作业。
这不是家庭作业。我只是想澄清我的概念。请在你能回答的情况下回复
我不知道 synchronized 在 JVM 中的实际工作原理，但我猜测只要有多个 CPU，它就是一种混合实现，其中锁定互斥锁的比赛的失败者将旋转一小会儿，如果互斥锁的所有者持有它太久，只有 yield() （即放弃它的时间片）。 (en.wikipedia.org/wiki/Spinlock)
使用并发实用程序，避免通知所有问题。

标签： java multithreading synchronization nonblocking context-switch

【解决方案1】：

等待线程不会导致永久上下文切换，请参阅这个问题：context switching thread waiting

（编辑：可能会发生一些上下文切换：JVM 会在短时间内尝试spinlock，但一段时间后，线程会在操作系统级别挂起，如果这种情况发生在其量程到期之前，那么这是一个额外的上下文切换）

所有相关的状态变量都应该在单个原子操作中更新（例如在单个同步块中），因此同步引起的上下文切换不应该与变量的数量成正比。

原子变量为了达到原子性尽量使用special CPU instructions，所以这里应该没有上下文切换。

【讨论】：

【解决方案2】：

假设没有使用 wait() 或 notify() 方法。这些似乎不在您的问题中。如果不是这样，请更正。

在这种情况下，会有上下文切换，因为所有这些线程都将处于 RUNNABLE 状态，并且会被安排运行并且会有上下文切换。您可以使用等待通知方法来减少这种情况。

如果你有更多的锁定，那么就会有更多的开销 - 这是正确的。

如果您使用原子变量，那么它将利用 compareAndSet 方法，其中它们将尝试旋转以在分配给它的处理器片中提供例如原子增量（参见 Linux：http://en.wikipedia.org/wiki/Completely_Fair_Scheduler）。如果它无法在其中进行原子增量，则不会有上下文切换，否则当再次切换回该线程时必须重新访问它。

希望这会有所帮助。

【讨论】：