Моє запитання стосується цього питання, заданого раніше. У ситуаціях, коли я використовую чергу для спілкування між виробниками та споживачами, люди зазвичай рекомендують використовувати LinkedBlockingQueueабо ConcurrentLinkedQueue?
Які переваги / недоліки використання одного над іншим?
Основна відмінність, яку я бачу з точки зору API, полягає в тому, що a LinkedBlockingQueueможе бути необмежено обмеженим.
Відповіді:
Що стосується потоку виробника / споживача, я не впевнений, що ConcurrentLinkedQueueце навіть розумний варіант - він не реалізується BlockingQueue, що є основним інтерфейсом для черг виробника / споживача IMO. Вам доведеться зателефонувати poll(), трохи почекати, якщо ви нічого не знайшли, а потім знову опитуйте і т. Д. ... що призводить до затримок, коли надходить новий товар, і неефективності, коли він порожній (через непотрібне прокидання від сну) .
З документів для BlockingQueue:
BlockingQueueреалізація розроблена таким чином, щоб використовувати їх насамперед для черг виробник-споживач
Я знаю, що це не чітко говорить про те, що для черг виробника-споживача слід використовувати лише блокуючі черги, але навіть так ...
ConcurrentLinkedQueueтакож корисно, якщо ваша нитка перевіряє кілька черг. Наприклад, на сервері з багатьма орендарями. Припустимо, що з причин ізоляції ви замість цього не використовуєте єдину чергу блокування та дискримінатор орендатора.
take()і put()просто споживаємо додатковий ресурс (інтервали синхронізації), ніж ConcurrentLinkedQueue . хоча це стосується використання обмежених черг для сценаріїв «Продюсер-споживач»
Це питання заслуговує кращої відповіді.
Java ConcurrentLinkedQueueзаснована на відомому алгоритмі Магеда М. Майкла та Майкла Л. Скотта для незаблокування черг без блокування .
"Неблокуючий" як термін тут для суперечливого ресурсу (нашої черги) означає, що незалежно від того, що робить планувальник платформи, як-от переривання потоку, або якщо нитка, про яку йдеться, просто занадто повільна, інші потоки змагаються за той самий ресурс все ще зможе прогресувати. Якщо, наприклад, задіяний замок, то нитка, що тримає замок, може бути перервана, і всі потоки, які чекають цього блокування, будуть заблоковані. Внутрішні блокування ( synchronizedключове слово) на Java також можуть суворо штрафувати за ефективність, як, наприклад, при необ'єктивному блокуваннізадіяний і у вас є суперечки, або після того, як VM вирішить "надути" замок після періоду граціозного відключення і блокувати нитки, що складаються ... саме тому у багатьох контекстах (сценарії низької / середньої суперечки) роблять порівняння та -набори атомних посилань можуть бути набагато ефективнішими, і саме це робить багато неблокуючих структур даних.
Java ConcurrentLinkedQueueне тільки не блокує, але й володіє приголомшливою властивістю, яку виробник не суперечить споживачеві. У сценарії одного виробника / єдиного споживача (SPSC) це дійсно означає, що говорити не доводиться. У сценарії декількох виробників / одного споживача споживач не буде протиставлятися виробникам. Ця черга має суперечки, коли намагаються зробити кілька виробників offer(), але це паралельність за визначенням. Це в основному загальна мета та ефективна неблокуюча черга.
Що стосується того, що це не бути BlockingQueueдобре, блокування нитки чекати в черзі - це дивно жахливий спосіб проектування сумісних систем. Не варто. Якщо ви не можете зрозуміти, як користуватися ConcurrentLinkedQueueсценарієм споживача / виробника, просто перейдіть до абстракцій вищого рівня, як у хороших акторських рамок.
LinkedBlockingQueueблокує споживача або виробника, коли черга порожня або заповнена, і відповідна нитка споживача / виробника переходить у режим сну. Але ця функція блокування пов'язана з вартістю: кожна операція "поставити або взяти" є замком між виробниками чи споживачами (якщо їх багато), тому в сценаріях з багатьма виробниками / споживачами операція може бути повільнішою.
ConcurrentLinkedQueueне використовує замки, але CAS в операціях “поставити / взяти” потенційно зменшує суперечки з багатьма виробниками та споживачами. Але будучи структурою даних "чекати безкоштовно", ConcurrentLinkedQueueвона не блокується, коли вона порожня, це означає, що споживачеві доведеться мати справу з take()поверненими nullзначеннями "зайнятим очікуванням", наприклад, з споживчою потоком споживача CPU.
Отже, яка з них "краща" залежить від кількості споживчих ниток, від норми, яку вони споживають / виробляють тощо. Для кожного сценарію необхідний орієнтир.
Один конкретний випадок використання, коли ConcurrentLinkedQueueявно краще, коли виробники спочатку щось виробляють і закінчують свою роботу, розміщуючи роботу в черзі і лише після того, як споживачі почнуть споживати, знаючи, що це буде зроблено, коли черга буде порожньою. (тут не виникає суперечності між виробником-споживачем, а лише між виробником-виробником і споживачем-споживачем)
unbounded blockingqueueвикористовується, було б краще, ніж одночасне використання на основі CASConcurrentLinkedQueue
Ще одне рішення (яке не має масштабів) - це канали рандеву: java.util.concurrent SynchronousQueue