為什么ConcurrentLinkedQueue.size（）的復雜度不能恆定？

Question

用於ConcurrentLinkedQueue Javadoc明確聲明size（）方法的復雜度為O（n）。 我覺得這很奇怪。 我將通過在計數器中累積大小來遵循股票LinkedList.size()方法。 考慮到ConcurrentLinkedQueue操作的異步性質，自然地，計數器必須是AtomicInteger 。 這樣做是否會因為違反無障礙保證而沒有做到？ 如果是這樣，我期望AtomicInteger計數器帶來多少開銷？

Answer 1

AtomicInteger沒什么問題：在非阻塞環境中使用是一件好事。 但是，如果在隊列中添加了AtomicInteger計數器，則會引入pool()和offer(E)都必須保持更新的位置。 這將增加CAS操作的數量以及失敗的 CAS操作的數量。

Javadoc告訴我們，減少CASes可能是一個很好的優化。

頭和尾都允許滯后。 實際上，每次都無法更新它們是一個重大的優化（較少的CASes）。
...
由於頭和尾同時並獨立地更新，所以尾可能會滯后於頭（為什么不這樣）？

^{JDK 8> java.util.concurrent.ConcurrentLinkedQueue}

請注意，返回的size()結果可能不准確，並且如他們所說，“在並發應用程序中通常不是很有用”。