параллельная очередь - общий вопрос (описание и использование)

Под "параллелизмом" я понимаю, что очередь является потокобезопасной. Это не значит, что это будет эффективно. Тем не менее, я мог бы предположить, что очередь Java использует реализацию без блокировки, что означает, что когда два потока пытаются выполнить push или pop одновременно, мало или совсем нет. Обычно происходит то, что они используют атомарную блокировку на уровне ассемблера, которая гарантирует, что один и тот же объект не может быть извлечен дважды.

Однажды я написал свободную от блокировок очередь FIFO (в Delphi), которая работала очень хорошо. Намного более эффективен, чем предыдущая версия, в которой использовались критические разделы. Версия CS остановилась, особенно из-за того, что все потоки пытались получить доступ к очереди. Версия без блокировок, однако, не имела узких мест из-за большого количества потоков, часто обращающихся к ней.

Вы должны начать с проверки определения интерфейса BlockingQueue , так как это краеугольный камень для использования очередей для связи между потоками и содержит служебные методы, позволяющие потокам-производителям и потребителям получать доступ очередь в блокирующем или неблокирующем режиме. Это, наряду с потокобезопасным доступом, является моим пониманием того, что представляет собой «параллельная очередь» (хотя я никогда не слышал об этой фразе - BlockingQueue просто существует в java.util.concurrent ).

Чтобы ответить на вторую часть вашего вопроса, вам следует изучить реализацию приоритетной очереди PriorityBlockingQueue . Это может быть полезно, если ваши потоки-производители создают задачи с разными приоритетами (например, запросы от "обычных пользователей" и «опытные пользователи»), и вы хотите контролировать порядок, в котором задачи обрабатываются вашим потребительским потоком (ами). Одна из возможных ловушек, которую следует избегать - это нехватка задач с низким приоритетом, которые никогда не удаляются из очереди из-за постоянного притока задач с более высоким приоритетом.

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

BlockingQueue использует блокировки для взаимного исключения

ArrayBlockingQueue, LinkedBlockingQueue, PriorityBlockingQUeue: три очереди блокировки, а

ConcurrentLinkedQueue, java 1.7 LinkedTransferQueue: использует неблокирующий алгоритм очереди Майкла и Скотта.

При умеренной или низкой конкуренции (что является более реальным сценарием) неблокирующие очереди значительно превосходят очереди с блокировкой.

И обратите внимание на комментарий Стива об отсутствии узких мест. В условиях сильной конкуренции неблокирующий алгоритм может сдерживать постоянные попытки cas, в то время как блокировка приостанавливает потоки. Затем мы видим, что BlockingQueue в условиях сильной конкуренции с небольшим выходом выполняет неблокирующую очередь, но такой тип конкуренции ни в коем случае не является нормой.

Просто оставьте здесь ссылку на java.util.concurrent package , который, как мне кажется, содержит очень важную информацию по некоторым вопросам, поднятым здесь.

См .: Параллельные коллекции и Свойства согласованности памяти