java - 为什么 Queue.poll 比 Iteration 快？ (java.util.concurrent.ConcurrentLinkedQueue)

Question

我有一段代码可以从队列中获取所有元素。之后我不关心队列的状态，我可以确信在我从队列中删除元素时队列不会被修改。

我最初使用迭代器来提取元素，因为我认为它比轮询元素更快...

但我运行了以下测试:

ConcurrentLinkedQueue<Object> queue = new ConcurrentLinkedQueue<>();
for (int i=0; i < 1000000; i++)
    queue.add(new Object());

LinkedList<Object> list = new LinkedList<>();
long start = System.currentTimeMillis();
for (Object object: queue)
    list.add(object);
long time1 = System.currentTimeMillis() - start;

list = new LinkedList<>(); 
start = System.currentTimeMillis();
Object object;
while ((object = queue.poll()) != null)
    list.add(object);
long time2 = System.currentTimeMillis() - start;

System.out.println(time1 + " " + time2);

我得到了以下输出(平均超过 100 次运行)

1169 46

我的问题是:为什么轮询比迭代快？这对我来说完全不直观，因为 poll 必须修改队列，而 iterate 只需要查看状态。

编辑 --- 格雷是对的

我在循环中运行它并获得了输出(首先应该这样做)

1180 46
1422 25
287 32
14 26
226 26
236 25
12 26
14 25
13 25
13 26
13 25
268 25
13 25
14 176
13 26
13 26
13 25
13 25
13 26
13 24
13 26
13 25
...

Answer 1

My question is: Why is poll faster than iterate? It is completely unintuitive to me because poll will have to modify the queue and iterate will only have to look at the state.

正如@csoroiu 指出的那样，这似乎是热点编译器问题。考虑到 Java 的工作原理，在开始像这样进行计时调用之前“预热”您的应用程序非常重要。

如果我在一个方法中运行您的测试 100 次，我最初看到由于 GC 开销和其他 JVM 魔术而导致的性能大不相同。但是，在添加一些 .clear() 方法和方法末尾的 System.gc() 之后，性能数字与迭代器获胜更加一致:

108 143
89 152
83 148
78 140
79 153
90 155
...

有关更多详细信息，请在此处查看 Peter 的回答:CPU execution time in Java

有关如何像这样正确地进行微基准测试的大量更多信息，请参阅这个详尽的答案:How do I write a correct micro-benchmark in Java?