Структура данных параллельной очереди с ArrayList в качестве элемента

Question

Проблемы в деталях

Вызывает ли это какую-либо проблему при использовании структуры данных, например, ArrayBlockingQueue<ArrayList<MyClass>>
с несколькими потоками?

Фон

На высоком уровне,Я пытаюсь добиться того, чтобы у меня был один продюсер, который создаст гигантский список.Для того, чтобы ускорить обработку.Я решил использовать несколько потребителей (потоков), потребляющих гигантский список, созданный производителем.

My Proposal Solution

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

Постановка проблемы

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

• Но будет ли безопасно использование не-поточно-ориентированной структуры данных в качестве элемента поточно-ориентированной структуры данных?

• Будет ли это вызыватькакие-либо проблемы при использовании структуры данных, например, ArrayBlockingQueue<ArrayList<MyClass>>
  с несколькими потоками?

• Повлияет ли это на производительность?

Answer 1

Не должно быть очевидной проблемы с этим подходом.

Будет ли безопасно использование не поточно-ориентированной структуры данных в качестве элемента поточно-ориентированной структуры данных?

Это безопасно, если вы правильно координируете (или избегаете) параллельный доступ к не поточно-ориентированной внутренней структуре данных. ArrayBlockingQueue обеспечивает установление отношения «до того», когда вы получаете доступ к его элементам с помощью peek, poll или связанных методов.

Будет ли это вызывать какие-либо проблемы при использовании структуры данных, например, ArrayBlockingQueue<ArrayList<MyClass>> с несколькими потоками?

Нет, это то, для чего предназначен BlockingQueue, пока вы координируете доступ к внутренним спискам (см. Выше).

Повлияет ли это на производительность?

В целом подход, при котором один производитель разделяет список на подсписки, может быть неоптимальным. Производитель не знает / не должен знать о количестве потребителей и их пропускной способности и, следовательно, в целом не знает, какие размеры разделов работают хорошо. Лучшим подходом может быть использование ArrayBlockingQueue<MyClass>, а со стороны потребителя всегда потреблять несколько элементов за один раз, вызывая drainTo для подходящего числа maxElements элементов.

Answer 2

Спасибо за ответ от michid @ и Thilo @

Окончательное разрешение

В итоге я использую LinkedBlockingQueue<List<MyObjClass>> и получаю несколько дочерних потоков, опрашивающих из очереди.Каждый дочерний поток будет иметь список MyObjClass для работы.

Это разрешение не влияет на замедление производительности.
Почему я выбираю LinkedBlockingQueue вместо ArrayBlockingQueue, см. Ссылка