Поражает ли "блокирующая" очередь саму цель многопоточности?

Думаю, это дизайнерское решение. Если он выбрал режим блокировки, ArrayBlockingQueue предоставит ему метод put. Если разработчику не нужен режим блокировки, у ArrayBlockingQueue есть метод offer, который вернет false, когда очередь заполнена, но затем ему нужно решить, что делать с повторным событием регистрации.

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

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

В вашем примере я бы рассмотрел блокировку как функцию: она предотвращает OutOfMemoryError.

Вообще говоря, один из ваших потоков недостаточно быстр, чтобы справиться с назначенной нагрузкой. Таким образом, другие должны как-то замедлиться, чтобы не подвергать опасности все приложение.

С другой стороны, если нагрузка сбалансирована, очередь не блокируется.

Блокировка - необходимая функция многопоточности. Вы должны заблокировать, чтобы иметь синхронизированный доступ к данным. Это не противоречит цели многопоточности.

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

Это позволит вызывающему коду решить, как он хочет обрабатывать полную очередь.

Если порядок выполнения при обработке элементов из очереди не важен, я рекомендую использовать пул потоков (известный как ExecutorService в Java).

Это зависит от характера вашей философии многопоточности. Для тех из нас, кто предпочитает обмен последовательными процессами, очередь с блокировкой почти идеальна. Фактически, идеальным было бы такое сообщение, при котором никакое сообщение не может быть помещено в очередь, если получатель не готов его принять.

Так что нет, я не думаю, что очередь с блокировками идет вразрез с самой целью многопоточности. Фактически, сценарий, который вы описываете (основной поток в конечном итоге останавливается), является хорошей иллюстрацией основной проблемы с актор-моделью многопоточности; вы не знаете, будет ли это взаимоблокировка / блокировка, и вы также не можете полностью проверить это.

Напротив, представьте себе блокирующую очередь с нулевым объемом сообщений. Таким образом, чтобы система работала вообще, вам нужно будет найти способ гарантировать, что регистратор всегда гарантированно сможет получить сообщение из основного потока. Это CSP. Это может означать, что в вашем гипотетическом потоке регистратора у вас должна быть буферизация, определяемая приложением (в отличие от лучшего предположения разработчика фреймворка о том, насколько глубоким должен быть FIFO), подсистема быстрого ввода-вывода, проверки на соответствие, способы решения отставание и т. д. Короче говоря, это не позволяет вам уйти от ответственности, вы вынуждены учитывать все аспекты производительности вашей системы.

Это, конечно, сложнее, но в результате вы получите систему, которая определенно в порядке, а не сомнительное «может быть», которое у вас есть, если ваши очереди блокировки содержат неизвестное количество сообщений.

Похоже, у вас есть общее представление о том, почему вы должны использовать что-то вроде ArrayBlockingQueue для разговора между потоками.

Наличие блокирующей очереди дает вам возможность сделать что-то другое, если что-то пойдет не так с вашими фоновыми рабочими потоками, вместо того, чтобы вслепую добавлять дополнительные запросы в очередь. Если в очереди есть место, то блокировки нет.

Однако для вашего конкретного случая использования я бы использовал ExecutorService вместо прямого чтения / записи очередей, что создает пул фоновых рабочих потоков:

http://docs.oracle.com/javase/6/docs/api/java/util/concurrent/ExecutorService.html

pool = Executors.newFixedThreadPool(poolSize);
pool.submit(myRunnable);

Многопоточная программа является недетерминированной, поскольку вы не можете сказать заранее: n действий производителя будут длиться ровно столько же, сколько действий потребителя. Следовательно, в каждом случае необходима синхронизация между n производителями и m потребителями.

Вы захотите выбрать размер очереди так, чтобы количество активных производителей и потребителей в большинстве случаев было максимальным. Но модель потока java не гарантирует, что любой потребитель будет работать, если только это не единственный разблокированный поток. (Тем не менее, конечно, на многоядерных процессорах весьма вероятно, что потребитель будет работать).

Вы должны выбрать, что делать, когда очередь заполнена. В случае очереди Array Blocking этот выбор - подождать.

Другой вариант - просто выбросить новые объекты, если очередь заполнена; этого можно добиться с помощью предложения.

Вы должны пойти на компромисс.