Joshua Bloch 的“Effective Java”，第 51 条不是关于依赖线程调度程序以及不要将线程不必要地保持在可运行状态。引用文本:

The main technique for keeping the number of runnable threads down is to have each thread do a small amount of work and then wait for some condition using Object.wait or for some time to elapse using Thread.sleep. Threads should not busy-wait, repeatedly checking a data structure waiting for something to happen. Besides making the program vulnerable to the vagaries of the scheduler, busy-waiting can greatly increase the load on the processor, reducing the amount of useful work that other processes can accomplish on the same machine.

然后继续显示繁忙等待与正确使用信号的微基准测试。在书中，忙等待每秒进行 17 次往返，而等待/通知版本每秒进行 23,000 次往返。

但是，当我在 JDK 1.6 上尝试相同的基准测试时，我看到的恰恰相反——繁忙等待每秒 76 万次往返，而等待/通知版本每秒 53300 次往返——也就是说，等待/通知应该有快了约 1400 倍，但结果却慢了约 13 倍？

我知道忙等待不好，信号仍然更好 - 忙等待版本的 cpu 利用率约为 50%，而等待/通知版本的 cpu 利用率保持在 ~30% - 但有什么东西可以解释数字？

如果有帮助，我正在 Win 7 x64(核心 i5)上运行 JDK1.6(32 位)。

更新:来源如下。要运行繁忙的工作台，将 PingPongQueue 的基类更改为 BusyWorkQueue 导入 java.util.LinkedList； 导入 java.util.List;

abstract class SignalWorkQueue { 
    private final List queue = new LinkedList(); 
    private boolean stopped = false; 

    protected SignalWorkQueue() { new WorkerThread().start(); } 

    public final void enqueue(Object workItem) { 
        synchronized (queue) { 
            queue.add(workItem); 
            queue.notify(); 
        } 
    } 

    public final void stop()  { 
        synchronized (queue) { 
            stopped = true; 
            queue.notify(); 
        } 
    } 
    protected abstract void processItem(Object workItem) 
        throws InterruptedException; 
    private class WorkerThread extends Thread { 
        public void run() { 
            while (true) {  // Main loop 
                Object workItem = null; 
                synchronized (queue) { 
                    try { 
                        while (queue.isEmpty() && !stopped) 
                            queue.wait(); 
                    } catch (InterruptedException e) { 
                        return; 
                    } 
                    if (stopped) 
                        return; 
                    workItem = queue.remove(0); 
                } 
                try { 
                    processItem(workItem); // No lock held 
                } catch (InterruptedException e) { 
                    return; 
                } 
            } 
        } 
    } 
}

// HORRIBLE PROGRAM - uses busy-wait instead of Object.wait! 
abstract class BusyWorkQueue {
    private final List queue = new LinkedList();
    private boolean stopped = false;

    protected BusyWorkQueue() {
        new WorkerThread().start();
    }

    public final void enqueue(Object workItem) {
        synchronized (queue) {
            queue.add(workItem);
        }
    }

    public final void stop() {
        synchronized (queue) {
            stopped = true;
        }
    }

    protected abstract void processItem(Object workItem)
            throws InterruptedException;

    private class WorkerThread extends Thread {
        public void run() {
            final Object QUEUE_IS_EMPTY = new Object();
            while (true) { // Main loop
                Object workItem = QUEUE_IS_EMPTY;
                synchronized (queue) {
                    if (stopped)
                        return;
                    if (!queue.isEmpty())
                        workItem = queue.remove(0);
                }

                if (workItem != QUEUE_IS_EMPTY) {
                    try {
                        processItem(workItem);
                    } catch (InterruptedException e) {
                        return;
                    }
                }
            }
        }
    }
}

class PingPongQueue extends SignalWorkQueue {
    volatile int count = 0;

    protected void processItem(final Object sender) {
        count++;
        SignalWorkQueue recipient = (SignalWorkQueue) sender;
        recipient.enqueue(this);
    }
}

public class WaitQueuePerf {
    public static void main(String[] args) {
        PingPongQueue q1 = new PingPongQueue();
        PingPongQueue q2 = new PingPongQueue();
        q1.enqueue(q2); // Kick-start the system

        // Give the system 10 seconds to warm up
        try {
            Thread.sleep(10000);
        } catch (InterruptedException e) {
        }

        // Measure the number of round trips in 10 seconds
        int count = q1.count;
        try {
            Thread.sleep(10000);
        } catch (InterruptedException e) {
        }
        System.out.println(q1.count - count);

        q1.stop();
        q2.stop();
    }
}

最佳答案

在您的测试中，队列不断获取新项目，因此忙等待几乎没有实际等待。

如果队列每 1 毫秒获得一个新项目，您可以看到忙等待将花费大部分时间来白白消耗 CPU。它会减慢应用程序的其他部分。

所以这取决于。如果你忙于等待用户输入，那肯定是错误的；而像 AtomicInteger 这样的无锁数据结构中的忙等待绝对是好的。

关于Java 并发 JDK 1.6 : Busy wait does better than signalling? Effective Java #51，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/3311587/