在我的项目中,到目前为止,我已经使用 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出了什么问题?这似乎是一个更好的解决方案。

10-04 13:34