我想了解一个简单的场景，其中有很多线程竞争同步的共享资源。只有一个线程肯定会获得对资源的锁定而所有其他线程必须等待，现在在资源可用性上，每个等待的线程将再次尝试获取锁定，如果失败则再次暂停以进行下一次尝试。此方案是否不会增加上下文切换开销，因为线程会一次又一次地挂起和恢复以获取资源。我只是想问一下，1）同步开销和上下文切换开销之间存在直接比例关系2）在任何算法中通过锁引入更多共享变量会增加上下文切换开销，即共享资源数量与之间存在直接比例关系。上下文切换开销
我是对的吗？
现在我的第二个问题是“如果在上述场景中使用非阻塞算法进行同步，即如果将原子变量用作共享资源，那么在原子共享资源的情况下，上下文切换开销会产生什么影响”。共享资源的竞争线程是否会暂停或恢复，即如何处理这种非阻塞同步现象？
答案 0 :(得分：0)
等待线程不会导致永久性上下文切换，请参阅此问题：context switching thread waiting
（编辑：可能会发生一些上下文切换：JVM尝试spinlock一段时间，但过了一段时间后，线程在操作系统级别挂起，如果在量程到期之前发生这种情况，那么这是一个额外的上下文切换）
所有相关的状态变量应该在单个原子操作中更新（例如在单个同步块中），因此同步引起的上下文切换不应与变量数成比例。
原子变量试图使用special CPU instructions来实现原子性，所以这里不应该有上下文切换。
答案 1 :(得分：0)
假设没有使用wait（）或notify（）方法。似乎这些问题并不在你的问题中。如果不是这样，请更正。
在这种情况下，会有上下文切换，因为所有这些线程都将处于RUNNABLE状态并且将被安排运行并且将存在上下文切换。您可以使用wait-notify方法来减少这种情况。
如果你有更多的锁定，那么会有更多的开销 - 这是正确的。
如果您使用原子变量，那么将使用compareAndSet方法，其中他们将尝试旋转以在分配给它的处理器片中提供（例如原子增量）（参见Linux：http://en.wikipedia.org/wiki/Completely_Fair_Scheduler）。如果它无法进行原子增量，那么就没有上下文切换，否则当再次切换回这个线程时，必须重新访问它。
希望这有帮助。