Примеры реальной жизни для CountDownLatch и CyclicBarrier

один пример приведен одним из наших тренеров, когда он объяснял разницу между CountDownLatch и CyclicBarrier.

CountDownLatch: предположим, камень может быть поднят 10 людьми, так что вы будете ждать всех 10, чтобы прийти. Только тогда вы сможете поднять камень.

CyclicBarrier: если вы собираетесь на пикник, и вам нужно сначала встретиться в какой-то общей точке, откуда вы все начнете свое путешествие.

Если кто-нибудь согласен с эти комментарии, пожалуйста, дайте мне некоторые детали.

Я уже прочитал API sun для обоих этих классов. Но мне нужно еще кое-что объяснить.

8 ответов


ключевое отличие в том, что CountDownLatch разделяет потоки на официантов и прибывших в то время как все потоки с помощью CyclicBarrier выполнить обе роли.

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

ваш пример защелка означает, что все десять человек должны ждать, чтобы поднять камень вместе. Это не так. Лучшим примером реального мира был бы суфлер экзамена, который терпеливо ждет, когда каждый студент сдаст свой тест. Студенты не ждут, как только они закончат свои экзамены и могут уйти. Как только последний студент сдает экзамен (или срок истекает), суфлер перестает ждать и уходит с тестами.


в гипотетическом театр ,

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

здесь человек-это поток, игра-это ресурс.


Пример Реального Мира Я вижу, что во всех ответах на самом деле отсутствует реальный пример. Как и в том, как эти классы могут быть использованы в области программного обеспечения

  1. CountDownLatch за Многопоточный менеджер загрузки. Менеджер загрузки запустит несколько потоков для загрузки каждой части файла одновременно.(Если сервер поддерживает несколько потоков для загрузки). Здесь каждый поток вызывает метод обратного отсчета экземпляр защелки. После всех потоки закончили выполнение, поток, связанный с защелкой обратного отсчета, интегрирует части, найденные в разных частях, вместе в один файл

  2. CyclicBarrier Тот же сценарий, что и выше..Но предположим, что файлы загружаются из P2P. Снова несколько потоков загрузки частей. Но здесь предположим, что вы хотите, чтобы проверка intergity для загруженных частей была сделана через определенный интервал времени. Здесь циклический барьер играет важную роль роль. После каждого интервала времени каждый поток будет ждать у барьера, чтобы поток, связанный с cyclibarrier, мог выполнить проверку целостности. Эта проверка целостности может быть выполнена несколько раз благодаря CyclicBarrier

пожалуйста, поправьте меня, если что-то не правильное.


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


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

таким образом, основной поток инициатора задания инициализирует CountDownLatch на количество используемых потоков, он распределяет задачи по потокам и ждет, когда защелка поднимет ноль с await метод. Каждый поток исполнителя будет вызывать countDown в конце своей задачей. Наконец, основной поток будет просыпайтесь, когда все потоки закончены, поэтому он считает, что вся работа выполнена. В этом сценарии используется doneSignal защелка описывает в Javadoc CountDownLatch.

случай использования 2 Предположим, вы разделили большое задание на n * m задач, распределенных по n потокам. m соответствует строке матрицы, и у вас есть итог для вычисления для каждой строки. В этом случае потоки должны быть синхронизированы после завершения каждой задачи, чтобы вычислить итог для строки. В этом случае CyclicBarrier инициализированный числом потоков n используется для ожидания конца каждого вычисления строки (фактически m раз).

сравнивать как CountDownLatch предполагается использовать только 1 раз и CyclicBarrier может использоваться столько раз, сколько алгоритм требует точки синхронизации для набора потоков.


Теоретическая Разница:

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

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

реальной жизни пример:--

CountDownLatch: рассмотрим сценарий IT world, где менеджер разделил модули между командами разработчиков (A и B), и он хочет назначить его команде QA для тестирования только тогда, когда обе команды завершат свою задачу.

здесь поток менеджера работает как основной поток, а команда разработчиков работает как рабочий поток. Поток диспетчера ожидает, пока поток команд разработки завершит свою задачу.

CyclicBarrier: рассмотреть тот же сценарий IT world, где менеджер разделил модули между командами разработчиков (A и B). Он уходит в отпуск и попросил обе команды подождать друг друга, чтобы выполнить свою задачу, как только оба закончат, назначьте ее команде QA для тестирования.

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


CountDownLatch: Если мы хотим, чтобы все наши нити делали

что-то + обратный отсчет

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

CyclicBarrier: Если мы хотим, чтобы все наши нити

сделать что - то + ждать в общей точке + сделать что-то

(каждый ожидающий вызов уменьшит время ожидания потоков для продолжения)

функциональность CyclicBarrier может быть достигнута только с помощью CountDownLatch один раз позвонив лэтчу.обратный отсчет () с последующей защелкой.await () всеми потоками.

но снова вы не можете сбросить / повторно использовать countdownlatch.

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


циклический барьер, как следует из названия, может использоваться в циклах. Для бывших: Я компания hr ищет N количество резюме из различных веб-каналов портала работы. У меня есть массив наборов навыков, содержащий навыки, отсортированные в порядке приоритета. Например, java, c#, python. Я хочу найти n резюме, соответствующие Java skillset, но если я не найду необходимого, нет. из резюме, я ищу снова на следующий набор навыков и так далее.

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

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