可視性和原子計數器更新的順序VS阻塞隊列

Question

如果生產者線程將對象添加到數的BlockingQueue之一：S，並按照該遞增的原子整數。消費者線程在查詢每個BlockingQueue並查找排隊的對象之前是否會看到遞增的整數值？

該文件說明有一個發生在與閱讀計數器的關係。所以我的理解是消費者線程應該始終在阻塞隊列中看到添加的項目。

我有一個困難的錯誤，它看起來好像消費者線程首先看到遞增的整數，但他們永遠不會在它們輪詢的阻塞隊列中找到任何對象（因爲輪詢對所有隊列都返回null）。所有生產者線程都遵循「添加到隊列然後增加計數器」的行爲。

另外，還有一些無證原因，你可以從輪詢的BlockingQueue，比隊列爲空的其他空回。

（如果它的事項，我用java.util.concurrent.LinkedBlockingQueue中看到這一點。）

Answer 1

在這種情況下的之前發生關係的添加到隊列在寫之前發生原子整數。

爲了能夠保證的關係，一個線程需要知道原子整數已更改或有一個原子整數的價值和隊列的當前狀態之間的關聯。

太難講什麼錯誤是根據您的描述，而只是閱讀的原子整數的值意味着什麼，除非你知道它已經改變了（或者已經不依賴於關係）。

至於返回null。如果您調用非等待方法，LinkedBlockingQueue可以返回null。例如poll是非等待

獲取並移除此隊列的頭，如果此 隊列爲空，則返回null。

凡爲take將等待隊列

中檢索存在的元素，並移除此隊列的頭，如有必要則等待，直到元素變得可用。