在我的项目中,到目前为止,我已经使用 Runnable
“同步”多个线程(每个线程运行相同类型的CyclicBarrier
)。在我的情况下,由于同步频率很高,因此使用CyclicBarrier
效率低下,但是忙等待机制可能会更快地工作。这是到目前为止我得到的(遗漏了一些部分):
public class MyRunnable implements Runnable {
private static AtomicInteger counter = null; // initialized to the number
// of threads
public void run() {
// do work up to a "common point"
synchronized (this) {
// decrement the counter and - if necessary - reset it
if (counter.decrementAndGet() == 0) {
counter.set(numberOfThreads);
// make all the busy waiting threads exit from the loop
for (int i = 0; i < threads.length; i++)
threads[i].interrupt();
}
}
// busy wait until all threads have reached the "common point"
while (!Thread.interrupted()) {}
}
}
不幸的是,此代码的性能甚至比
CyclicBarrier
还要差。 Here's一个简短的可编译示例。关于如何改善它的任何建议? 最佳答案
如果您有更多的处理器,然后有正在运行的线程,那么繁忙的等待只会在“更快”的情况下起作用。如果您连续使用Thread.interrupted并消耗CPU时间,则实际上会大大降低性能。
CyclicBarrier/CountDownLatch出了什么问题?这似乎是一个更好的解决方案。