размер ConcurrentLinkedQueue
При чтении Документов ConcurrentLinkedQueue Java, интересно, почему для реализации не возможно сохранить размер:
Остерегайтесь этого, в отличие от этого, в большинстве наборов, метод размера НЕ является постоянно-разовой операцией. Из-за асинхронной природы этих очередей, определяя текущее число элементов требует обхода элементов.
Где в источнике эта "асинхронная природа"? Я только вижу цикл с условием продолжения для повторения enqueing, пока AtomicReferences не соответствуют ожидаемым значениям/ссылкам. Почему не возможно увеличить size:AtomicInteger после успешного предложения значения Очереди?
Большое спасибо.
3 ответа
Представьте, что у вас есть два потока, один добавляет новый элемент, а другое удаление элемента. В начале очереди нет товаров.
Предположим, что первый поток добавляет элемент, за ним сразу же следует другой поток, удаляющий элемент и уменьшающий размер, в этот момент ваш размер равен -1, затем первый поток увеличивает размер до 0.
A немного надуманный пример, но вам нужно будет сделать всю операцию атомарной, чтобы гарантировать, что никакие другие потоки не могут получить доступ к размеру -1.
Одно из важных преимуществ производительности ConcurrentLinkedQueue связано с тем, что вы не беспокоитесь о хвосте при обновлении заголовка, и наоборот, верно?
В основном это означает, что 2 потока могут опрашивать / предлагать одновременно, не мешая друг другу (если размер очереди был не равен 0).
Этого не было бы, если бы у вас был счетчик. Даже если это был AtomicInteger с хорошим параллелизмом, у вас все равно будет повышенная вероятность неудачных операций CAS, потому что теперь у вас есть эта «горячая точка», которую вы обновляете каждый раз, когда проводите опрос / предложение.
Не совсем уверен, имеют ли авторы это в виду, когда говорят «асинхронный характер», но я думаю, что это самая большая причина, по которой у них нет счетчика, как вы предложили.
Почему невозможно увеличить размер : AtomicInteger после успешного предложения значения очереди?
Вероятно потому, что это предложение / декремент не могло быть выполнено атомарно без отрицательного воздействия на параллелизм метода.