LinkedBlockingQueue по сравнению с ConcurrentLinkedQueue
Во втором примере вызывающая сторона должна снабдить префиксом имя переменной '&'; передать адрес переменной.
Это может быть преимуществом - вызывающая сторона не может непреднамеренно изменить переменную путем передачи его как ссылки, когда они думали, что были передающими значением.
3 ответа
Для потока производителя / потребителя я не уверен, что ConcurrentLinkedQueue даже разумный вариант - он не реализует BlockingQueue , который является основным интерфейсом для очередей производителей / потребителей IMO. Вам придется вызвать poll () , немного подождать, если вы ничего не нашли, а затем снова опросить и т. Д., Что приведет к задержкам при поступлении нового элемента и неэффективности, когда он пуст. (из-за ненужного пробуждения из спящего режима).
Из документации для BlockingQueue:
Реализации BlockingQueueпредназначены для использования в первую очередь для очередей производитель-потребитель
Я знаю, что это не так строго говорят, что для очередей производитель-потребитель должны использоваться только очереди блокировки, но даже в этом случае ...
Другое решение (которое плохо масштабируется) - это каналы рандеву: java.util.concurrent SynchronousQueue
If your queue is non expandable and contains only one producer/consumer thread. You can use lockless queue (You don't need to lock the data access).