Что такое ForkJoinPool?

ForkJoinPool – специальный вид ExecutorService (пулла потоков), который появился в Java с версии 7. Предназначен для выполнения рекурсивных задач.

Задача для сервиса представляется экземпляром класса ForkJoinTask. В основном используются подклассы RecursiveTask и RecursiveAction, для задач с результатом и без соответственно. Аналогично интерфейсам Callable и Runnable обычного ExecutorService.

Тело рекурсивной операции задается в реализации метода compute() задачи ForkJoinTask. Здесь же создаются новые подзадачи, и запускаются параллельно методом fork(). Чтобы дождаться завершения выполнения задачи, на каждой форкнутой подзадаче вызывается блокирующий метод join(), результат выполнения при необходимости агрегируется.

С точки зрения использования метод ForkJoinTask.join() похож на аналогичный метод класса Thread. Но в случае fork-join поток может на самом деле не заснуть, а переключиться на выполнение другой задачи. Такая стратегия называется work stealing, и позволяет эффективнее использовать ограниченное количество потоков. Это похоже на переиспользование потоков корутинах Kotlin (green threads).

Примеры практического использования ForkJoinPool.

Java Guru🤓 #java

Чем ForkJoinPool отличается от ExecutorService?

ForkJoinPool сам по себе является наследником ExecutorService. Вопрос подразумевает его отличия от обычного пула потоков – ThreadPoolExecutor.

Преимущества, которые дает work stealing по сравнению с обычным пулом:
• Сокращение расходов на переключение контекста;
• Защита от проблемы голодания потоков (thread starvation);
• Защита от дедлока для рекурсивных задач.

Как положено любому представителю ExecutorService, ForkJoinPool тоже умеет выполнять Runnable и Callable, но помимо этого работает и со специальными задачами ForkJoinTask, о которых также говорилось ранее.

Интерфейс настройки и мониторинга остается тем же, что и в классических тред-пулах.

Каждый обычный пул использует собственный набор потоков. ForkJoinPool по умолчанию использует общий пул-синглтон commonPool. Альтернативный отдельный пул всё еще можно задать в конструкторе.

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

Java Guru🤓 #java

15 июля в 20:00 МСК OTUS проведёт открытый урок «Нормальная денормализация» — ключевой приём для оптимизации доступа к данным в NoSQL.

На примере Spring Data MongoDB разберём, как настраивать связи между сущностями: когда выбрать вложенные документы, а когда — ссылочные связи. Вы поймёте, как денормализация влияет на производительность запросов, расходы на память и сложность поддержки.

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

Присоединяйтесь к уроку и получите скидку на полный курс «Разработчик на Spring Framework».

Регистрируйтесь прямо сейчас: https://vk.cc/cNzFo6

Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576

Что будет результатом кода?

Что будет результатом кода?

Как работают параллельные стримы?

Основная цель, ради которой в Java 8 был добавлен Stream API – удобство многопоточной обработки.

Обычный стрим будет выполняться параллельно после вызова промежуточной операции parallel(). Некоторые стримы создаются уже многопоточными, например результат вызова Collection#parallelStream(). Для распараллеливания используется единый общий ForkJoinPool.

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

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

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

Java Guru🤓 #java

🔥 БЕСПЛАТНЫЙ КУРС ПО СОЗДАНИЮ НЕЙРО-СОТРУДНИКОВ НА GPT И ДРУГИХ LLM 🔥

Ищете практический и углубленный курс, чтобы освоить создание нейро-сотрудников? Мы создали курс из 5 объемных занятий. Это именно то, что нужно, чтобы прокачать свои навыки абсолютно бесплатно!

📌 Темы занятий:
1. Введение в мир нейро-сотрудников
2. Как работают LLM и их аналоги
3. Создание базы знаний для нейро-сотрудника (RAG)
4. Тестирование и отладка нейро-сотрудников
5. Интеграция нейро-сотрудников в Production

Вот 5 тем курса - он максимально простой и доступный, общеобразовательный, без какого-либо сложного программирования 📚Прохождение этого курса, скорее всего, займет у вас от 1 до 3 часов

🤖 Присоединяйтесь к нашему бесплатному курсу и разберитесь в этой увлекательной теме с нами!

Чем CompletableFuture отличается от Future?

Future – интерфейс, который представляет пока еще недовычисленный результат. Когда породившая его асинхронная операция заканчивается, он заполняется значением. Метод get блокирует выполнение до получения результата, isDone проверяет его наличие. К примеру результат выполнения задач в ExecutorService, ForkJoinTask, реализует интерфейс Future.

CompletableFuture появился в Java 8. Это класс-реализация старого интерфейса Future, а значит всё сказанное выше справедливо и для него. Вдобавок к этому, CompletableFuture реализует работу с отложенными результатами посредством коллбэков. Метод thenApply регистрирует код обработки значения, который будет автоматически вызван позже, когда это значение появится.

В Java 9 прогресс пошел дальше, и появилась библиотека Flow API. Это встроенная реализация реактивных стримов. Реактивный стрим, сильно упрощая, – это более общий случай, последовательность отложенных значений. Другая их реализация – популярная, но не входящая в стандарт библиотека Reactive Extensions (RxJava).

Java Guru🤓 #java

Зачем выбирать ReentrantLock вместо synchronized?

Объект класса ReentrantLock решает те же задачи, что и блок synchronized. Поток висит на вызове метода lock() в ожидании своей очереди занять этот объект. Владеть локом, как и находиться внутри блока synchronized может только один поток одновременно. unlock(), подобно выходу из блока синхронизации, освобождает объект-монитор для других потоков.

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

Шире и возможные режимы блокировки. Кроме обычного ожидающего lock(), вариант tryLock() с параметром ожидает своей очереди только заданное время, а без параметра – вообще не ждет, а только захватывает свободный лок.

Еще одно отличие – свойство fair. Лок с этим свойством обеспечивает «справедливость» очереди: пришедший раньше поток захватывает объект раньше. Блок synchronized не дает никаких гарантий порядка.

Java Guru🤓 #java

Что произойдет при запуске?

Как используется метод Lock.newCondition()?

Если реализации интерфейса Lock представляют высокоуровневую альтернативу блока synchronized, то реализации его спутника, интерфейса Condition – альтернатива методам notify/wait. Оба этих интерфейса относятся к пакету java.util.concurrent.locks.

Как и ожидание на мониторе, Condition реализует примитив синхронизации «Условная переменная». Один или несколько потоков зависают на объекте-кондишне с помощью варианта метода await (ждут удовлетворения условия). Другой поток пробуждает их методами signal и signalAll (сигнализирует об удовлетворении условия).

Конкретные реализации Condition всегда решают те же задачи, что блокировка на мониторе, но в теории могут отличаться в нюансах поведения. Например, может не быть требования вызывать ожидание/сигнал только при захваченном локе (аналог требования, по которому notify/wait всегда вызываются в synchronized). Или может гарантироваться порядок получения сигнала ожидающими потоками.

Возвращаясь к поставленному вопросу, Condition всегда связан со своим объектом типа Lock, и метод Lock.newCondition() – единственный правильный способ создания кондишна.

Java Guru🤓 #java

Чем отличается ReentrantLock от обычного Lock?

Lock – это интерфейс, ReentrantLock – его реализация. «Reentrant» говорит о том, что один и тот же поток может перезахватывать уже захваченный лок. Интерфейс не требует этого свойства. Обычный блок synchronized тоже является reentrant – вложенная синхронизация на том же мониторе отработает без проблем.

Примеры не-reentrant локов из стандартной библиотеки – представления класса StampedLock, возвращаемые его методами asReadLock() и asWriteLock().

Java Guru🤓 #java

Как использовать ReadWriteLock?

Стандартный интерфейс ReadWriteLock предоставляет потокобезопасный разделенный доступ на чтение и на запись. Для этих целей в нём объявлены два метода: readLock() и writeLock(). Они возвращают объекты под интерфейсом Lock.

Оба типа блокировок одного экземпляра ReadWriteLock связаны. Пока какой-то поток не заберет блокировку на запись, сколько угодно потоков могут читать не мешая друг другу. Блокировкой readLock закрывается часть кода с семантикой «только чтения» некоторого условного «ресурса». В критической секции кода writeLock осуществляется модификация ресурса.

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

Интерфейс реализуется классом ReentrantReadWriteLock, который во многом похож на обычный ReentrantLock.

Java Guru🤓 #java

Когда используется StampedLock?

StampedLock – примитив синхронизации, добавленный в Java с версии 8. Общий принцип его работы точно такой же, как у ReadWriteLock: захват неэксклюзивной блокировки (на чтение), и эксклюзивной (на запись). Но есть у этих классов ряд различий в деталях.

Во-первых, если блокировка ReadWriteLock возвращает объекты типа Lock, то StampedLock возвращает числа типа long, которые и называется «штампами». Штамп служит идентификатором лока, он передается параметром в методы по работе с ранее захваченной блокировкой чтения или записи. Специальный штамп 0 означает неудавшийся захват.

StampedLock в отличие от ReentrantReadWriteLock – не реентрант. Это накладывает бóльшую ответственность на программиста: можно устроить дедлок на одном потоке.

В StampedLock расширена функциональность. Новые методы с префиксом try* не висят в ожидании. Методы tryOptimistic* реализуют оптимистичную блокировку. Методы tryConvert* дают возможность изменять «уровень» заблокированности: можно попытаться превратить readLock во writeLock, и наоборот.

Не смотря на похожесть, StampedLock не наследуется от ReadWriteLock. Но для совместимости в нём предусмотрены методы-адаптеры asReadWriteLock, asReadLock и asWriteLock.

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

Java Guru🤓 #java

Чем отличается CountDownLatch от CyclicBarrier?

CountDownLatch, дословно «Запор с обратным отсчетом», – примитив синхронизации из стандартной библиотеки Java. Он останавливает пришедшие потоки, пока внутренний счетчик не достигнет нуля. Чтобы поставить поток на ожидание, нужно вызвать из него метод await().

Начальное значение счетчика задается параметром конструктора, затем уменьшается на 1 методом countDown(). Узнать текущее значение можно с помощью getCount(). Изменение значения счетчика никак не связано с потоками, его можно вызывать откуда и когда угодно.

CyclicBarrier – барьер для потоков, который ломается при достижении критической массы ожидающих. Это тоже класс из Java Concurrency Framework. Поток также встает на ожидание методом await(). Ожидающие потоки называются parties, их лимит также устанавливается в конструкторе.

Технически, parties барьера и count латча – одно и то же, await барьера – это await+countDown латча. В барьере тоже доступна информация о текущем состоянии барьера (методы isBroken, getParties и getNumberWaiting).

Помимо этого, CyclicBarrier дает две дополнительных возможности. Во-первых, в конструктор кроме parties можно передать коллбэк с действием, которое выполнится в момент прорыва барьера. Во-вторых, этот примитив переиспользуется: метод reset() насильно прорывает текущий барьер и устанавливает новый.

Оба этих примитива помогают решить задачу о гарантированных дедлоках. Противоположность латча и барьера – семафор. В нём потоки блокируются при достижении счетчиком нуля.

Java Guru🤓 #java