размер ConcurrentLinkedQueue - PullRequest
       35

размер ConcurrentLinkedQueue

14 голосов
/ 03 мая 2010

Чтение Документы Java ConcurrentLinkedQueue , мне интересно, почему реализация не может сохранить размер:

Помните, что, в отличие от большинства коллекций, метод size НЕ является операцией с постоянным временем. Из-за асинхронного характера этих очередей определение текущего количества элементов требует обхода элементов.

Где в источнике эта "асинхронная природа"? Я вижу только цикл while для повторного включения, пока AtomicReferences не совпадет с ожидаемыми значениями / ссылками. Почему невозможно увеличить size:AtomicInteger после успешного предложения значения в очередь?

Большое спасибо.

Ответы [ 3 ]

5 голосов
/ 03 мая 2010

Представьте, что у вас есть две темы: одна добавляет новый элемент, а другая удаляет элемент. В начале нет элементов в очереди.

Предположим, что первый поток добавляет элемент, после чего другой поток сразу же удаляет элемент и уменьшает его размер, после чего ваш размер равен -1, а затем первый поток увеличивает размер до 0.

Слегка надуманный пример, но вам нужно сделать всю операцию атомарной, чтобы гарантировать, что никакие другие потоки не смогут получить доступ к размеру -1.

4 голосов
/ 03 мая 2010

Одно из важных преимуществ производительности ConcurrentLinkedQueue заключается в том, что вы не беспокоитесь о хвосте при обновлении головы, и наоборот, верно?

В основном это означает, что 2 потока могут одновременно опрашивать / предлагать без вмешательства (если размер очереди не равен 0, то есть).

Это был не тот случай, если у вас был счетчик. Даже если это был AtomicInteger с хорошим параллелизмом, у вас все равно будет повышенная вероятность неудачных операций CAS, потому что теперь у вас есть «горячая точка», которую вы обновляете каждый раз, когда делаете опрос / предложение.

Не совсем уверен, что авторы имеют в виду это, когда говорят «асинхронный характер», но я думаю, что это самая большая причина, по которой у них нет счетчика, как вы предложили.

0 голосов
/ 03 мая 2010

Почему невозможно увеличить размер: AtomicInteger после успешно предлагая значение для очереди?

Вероятно, потому что это предложение / декремент не может быть сделано атомарно без отрицательного влияния на параллелизм метода.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...