Kafka, Docker, Spring Cloud, CI/CD, Kubernetes, Prometheus, Grafana, ELK, Микросервисная архитектура (Discovery, API Gateway, Config, Circuit Breaker и т.д.), Spring Boot 3, JWT, Redis, OpenApi, Mockito, Testcontainers
1) Боевой проект
2) Свои стенды со всей инфраструктурой
3) Команда профессионалов с опытом по 15 лет в java
4) 100% рабочий процесс в команде
Статистика:
1) 72% ребят получили как минимум 1 офер на мидла до окончания курса
2) Есть команды в которых этот показатель был 100%
3) В последнем выпуске Влад(без коммерческого опыта) сделал рекорд и получил 7 оферов до конца курса, самый большой на 250к
4) 36% ребят в текущем наборе это практикующие Java разработчики, которые хотят освоить современный стек
5) 64% соответственно это ребята, которые прошли курсы, но не уверенны в себе или не знают микры
Отзывы в плейлисте: https://www.youtube.com/watch?v=BSh0jK2GxqU&list=PLt91xr-Pp57QsW6CLBAosBjwc23kF6mW3
✅ Главный отзыв после курса - я стал уверенным программистом, не боюсь собесов и не боюсь испыталки!
Подробнее здесь: https://javaguru.by/developer
Промокод: JAVAGURU_TG
Действует до 08.10.2024
Кому интересно пишите мне: @AndreiMentorJava
Привет, Андрей, интересен практикум! JAVAGURU_TG
Как понять или подхожу по уровню для практикума?
1) Писали учебные проекты на spring boot
2) Созвониться со мной (Дам обратную связь, что надо подтянуть или наоборот, если уже нет смысла курс проходить)
Буду рад пообщаться!
Please open Telegram to view this post
VIEW IN TELEGRAM
👍6😁4🔥3🌚2😱1
Как выполнить две задачи параллельно?
Простейший, путь – явно создать два объекта типа Thread, передать им инстансы Runnable, с нужными задачами в реализации их методов run, и запустить вызвав thread.start(). Если в основном потоке нужно дождаться завершения задач – после start() вызывается метод thread.join(). Исполнение зависнет на вызове этого метода до тех пор, пока тред не закончит свою задачу и не умрет. Вся работа задач с внешними данными должна быть синхронизирована.
Такое ручное создание тредов полезно в учебных целях, но считается плохой практикой в промышленном коде: само создание – дорогостоящая операция, а большое количество случайно созданных потоков может приводить к проблеме голодания (starvation) потоков.
В качестве продвинутой альтернативы используются пуллы потоков – реализации интерфейса ExecutorService. Такие сервисы создаются статическими фабричными методами класса Executors. Они умеют принимать задачи в виде Runnable- или Callable-объектов на заранее созданном наборе потоков (собственно, пулле).
Кроме самого пулла, экземпляры ExecutorService содержат фабрику потоков («инструкцию» как создать тред при необходимости), и коллекцию-очередь задач на исполнение.
В ответ на передачу на исполнение Runnable или Callable, сервис возвращает связанный с ним объект типа Future – хранилище, которое будет заполнено результатом выполнения задачи в будущем. Даже если никакого результата не ожидается, Future поможет дождаться момента завершения обработки задачи.
В Android для асинхронного выполнения используется похожая сущность – Looper.
Простейший, путь – явно создать два объекта типа Thread, передать им инстансы Runnable, с нужными задачами в реализации их методов run, и запустить вызвав thread.start(). Если в основном потоке нужно дождаться завершения задач – после start() вызывается метод thread.join(). Исполнение зависнет на вызове этого метода до тех пор, пока тред не закончит свою задачу и не умрет. Вся работа задач с внешними данными должна быть синхронизирована.
Такое ручное создание тредов полезно в учебных целях, но считается плохой практикой в промышленном коде: само создание – дорогостоящая операция, а большое количество случайно созданных потоков может приводить к проблеме голодания (starvation) потоков.
В качестве продвинутой альтернативы используются пуллы потоков – реализации интерфейса ExecutorService. Такие сервисы создаются статическими фабричными методами класса Executors. Они умеют принимать задачи в виде Runnable- или Callable-объектов на заранее созданном наборе потоков (собственно, пулле).
Кроме самого пулла, экземпляры ExecutorService содержат фабрику потоков («инструкцию» как создать тред при необходимости), и коллекцию-очередь задач на исполнение.
В ответ на передачу на исполнение Runnable или Callable, сервис возвращает связанный с ним объект типа Future – хранилище, которое будет заполнено результатом выполнения задачи в будущем. Даже если никакого результата не ожидается, Future поможет дождаться момента завершения обработки задачи.
В Android для асинхронного выполнения используется похожая сущность – Looper.
👍17🔥3👏2
Что такое абстрактные классы?
Абстрактные классы — это классы, которые не могут быть инстанциированы напрямую, то есть нельзя создать объект абстрактного класса при помощи оператора new. Они предназначены для обеспечения базовой структуры и функциональности для других классов, которые наследуются от них. Абстрактные классы представляют собой в некотором роде «заготовки» для подклассов, указывая на общие атрибуты и методы, которые они должны реализовать.
@javatasks #java
Абстрактные классы — это классы, которые не могут быть инстанциированы напрямую, то есть нельзя создать объект абстрактного класса при помощи оператора new. Они предназначены для обеспечения базовой структуры и функциональности для других классов, которые наследуются от них. Абстрактные классы представляют собой в некотором роде «заготовки» для подклассов, указывая на общие атрибуты и методы, которые они должны реализовать.
@javatasks #java
🔥17👍11❤3
Что происходит если не обработать исключение?
Если не было предпринято дополнительных действий, в этой ситуации нет никаких хитростей. Всё приложение, и даже метод main(), выполняется в потоках. Поток, в котором было выброшено и не обработано исключение, остановится, и распечатает стектрейс в вывод System.err. Если это был последний пользовательский поток, приложение начнет завершение работы.
Для изменения логики обработки непойманных исключений в Java существует функциональный интерфейс Thread.UncaughtExceptionHandler.
Обработчик упущенных исключений может быть установлен (в порядке возрастания приоритета):
• глобально на всё приложение, статическим методом Thread.setDefaultUncaughtExceptionHandler();
• для группы потоков, переопределением метода uncaughtException() в реализации объекта подкласса ThreadGroup (т.к. ThreadGroup сам является наследником UncaughtExceptionHandler);
• для отдельного потока, методом setUncaughtExceptionHandler().
Естественно, установка нестандартного обработчика не имеет обратной силы. Используя его, нужно убедиться, что он установлен достаточно рано, до выброса какого-либо исключения.
Хорошей практикой считается обрабатывать исключение настолько близко к месту его выброса, насколько возможно. Следовательно, использование глобальных обработчиков – самый плохой вариант.
Так же как в случае различных финализаций, несмотря на все её недостатки, глобальная обработка иногда лучше, чем ничего. Она может, например, дать последний шанс освободить внешние ресурсы, или уведомить о некорректной работе программы более эффективно, чем через логи.
Когда код с исключением выполняет ExecutorService, мы не имеем прямого доступа к объектам потока. Но в этом случае результатом выполнения будет объект типа Future. Такой отложенный объект при попытке прочитать значение перевыбросит полученное исключение, завернув его в ExecutionException. Новое исключение-обертка уже пойдет по обычному пути обработки текущего потока. Исключение как бы перекочует из внутреннего потока пулла во внешний, который использует этот пулл.
Если же пользовательский код не станет дожидаться результатов, исключение будет потеряно, не оставив даже стектрейса в потоке вывода. Для предотвращения такой ситуации стоит снабдить поток обработчиком сразу после создания, определив для сервиса собственную ThreadFactory.
Обычно, если фреймворк скрывает от пользователя детали работы с потоками, он также скрывает и детали работы с исключениями, оставляя свой специальный способ назначить обработчик. И этот специальный обработчик – более специфичный, а значит более правильный подход, чем стандартная глобальная обработка исключений Java. Так, например, в Spring MVC применяется аннотация @ExceptionHandler.
Если не было предпринято дополнительных действий, в этой ситуации нет никаких хитростей. Всё приложение, и даже метод main(), выполняется в потоках. Поток, в котором было выброшено и не обработано исключение, остановится, и распечатает стектрейс в вывод System.err. Если это был последний пользовательский поток, приложение начнет завершение работы.
Для изменения логики обработки непойманных исключений в Java существует функциональный интерфейс Thread.UncaughtExceptionHandler.
Обработчик упущенных исключений может быть установлен (в порядке возрастания приоритета):
• глобально на всё приложение, статическим методом Thread.setDefaultUncaughtExceptionHandler();
• для группы потоков, переопределением метода uncaughtException() в реализации объекта подкласса ThreadGroup (т.к. ThreadGroup сам является наследником UncaughtExceptionHandler);
• для отдельного потока, методом setUncaughtExceptionHandler().
Естественно, установка нестандартного обработчика не имеет обратной силы. Используя его, нужно убедиться, что он установлен достаточно рано, до выброса какого-либо исключения.
Хорошей практикой считается обрабатывать исключение настолько близко к месту его выброса, насколько возможно. Следовательно, использование глобальных обработчиков – самый плохой вариант.
Так же как в случае различных финализаций, несмотря на все её недостатки, глобальная обработка иногда лучше, чем ничего. Она может, например, дать последний шанс освободить внешние ресурсы, или уведомить о некорректной работе программы более эффективно, чем через логи.
Когда код с исключением выполняет ExecutorService, мы не имеем прямого доступа к объектам потока. Но в этом случае результатом выполнения будет объект типа Future. Такой отложенный объект при попытке прочитать значение перевыбросит полученное исключение, завернув его в ExecutionException. Новое исключение-обертка уже пойдет по обычному пути обработки текущего потока. Исключение как бы перекочует из внутреннего потока пулла во внешний, который использует этот пулл.
Если же пользовательский код не станет дожидаться результатов, исключение будет потеряно, не оставив даже стектрейса в потоке вывода. Для предотвращения такой ситуации стоит снабдить поток обработчиком сразу после создания, определив для сервиса собственную ThreadFactory.
Обычно, если фреймворк скрывает от пользователя детали работы с потоками, он также скрывает и детали работы с исключениями, оставляя свой специальный способ назначить обработчик. И этот специальный обработчик – более специфичный, а значит более правильный подход, чем стандартная глобальная обработка исключений Java. Так, например, в Spring MVC применяется аннотация @ExceptionHandler.
👍16🔥3
Тестовое собеседование на Middle Java-разработчика в среду
Заходи завтра, 9 октября в 19:00 по мск на открытое онлайн-собеседование от ШОРТКАТ, чтобы узнать:
Чего ждут от кандидатов на Middle позиции в Java-разработке
Какие вопросы задают на интервью и зачем
Как подготовиться к собесу,
чтобы получить оффер
Интервью проведёт Роман Половинцев, ex. TeamLead в Сбере.
Чтобы записаться на эфир, переходи в бот → @shortcut_sh_bot
Реклама. ООО "ШОРТКАТ", ИНН: 9731139396, erid: 2VtzqxFW2NE
Заходи завтра, 9 октября в 19:00 по мск на открытое онлайн-собеседование от ШОРТКАТ, чтобы узнать:
Чего ждут от кандидатов на Middle позиции в Java-разработке
Какие вопросы задают на интервью и зачем
Как подготовиться к собесу,
чтобы получить оффер
Интервью проведёт Роман Половинцев, ex. TeamLead в Сбере.
Чтобы записаться на эфир, переходи в бот → @shortcut_sh_bot
Реклама. ООО "ШОРТКАТ", ИНН: 9731139396, erid: 2VtzqxFW2NE
👍4🔥3
Чем отличается блокирующее чтение от неблокирующего?
В контексте Java речь в этом вопросе идет о блокирующем/неблокирующем чтении из потоков данных.
Классы блокирующего чтения находятся в пакете java.io. Вы наверняка много раз сталкивались с ними, работая с файлами и консольным вводом-выводом (классы Reader, IOException, InputStream). При блокирующем чтении тред останавливается, пока не получит из потока необходимые данные. Для этих самых распространенных случаев использование неблокирующего чтения не несет пользы, потому что сама запись пользователем консоли и жестким диском будет последовательной.
Чтение данных из сетевого подключения – другое дело. Обычно программа обрабатывает данные быстрее, чем работает сеть. Возникают паузы, в которые поток блокирующего чтения стоит в ожидании, не принося пользы. К тому же серверное приложение работает со многими параллельными подключениями.
Блокирующее чтение можно распараллеливать на потоки, читая в пулле. Но делать это нужно вручную, а количество одновременных подключений будет всё ещё ограничено количеством потоков-обработчиков, потоки буду всё ещё останавливаться без дела.
Для случаев, когда в вашем приложении ожидается большое количество подключений, был добавлен пакет стандартной библиотеки java.nio. С помощью NIO один тред может обслуживать несколько сетевых соединений одновременно, и переключаться между ними не теряя времени на ожидание данных.
IO использует потоки. данные приходят последовательно, и сами нигде не сохраняются. Если вы не обеспечили буферизацию вручную, нет возможности откатиться назад и прочитать уже пришедшие данные еще раз.
NIO сразу читает данные в буфер. Вы можете перемещаться по этому буферу перечитывая уже прочитанную ранее информацию. Плата за это – необходимость вручную следить, что буфер заполнен достаточным объемом данных для обработки, и что он не переполнился.
В этой статье приводится показательная аналогия. Блокирующее чтение – это телефонный разговор, неблокирующее – переписка в чате. Делая телефонный звонок, вы ждете пока собеседник ответит, можете «обрабатывать» только один звонок одновременно, получаете ответы сразу и не можете переслушать услышанный но забытый ответ. В мессенджере вы ведете несколько чатов одновременно, обращаетесь к истории переписки, но ответы на ваши сообщения приходят не всегда сразу, а порядок их получения неоднозначен.
В контексте Java речь в этом вопросе идет о блокирующем/неблокирующем чтении из потоков данных.
Классы блокирующего чтения находятся в пакете java.io. Вы наверняка много раз сталкивались с ними, работая с файлами и консольным вводом-выводом (классы Reader, IOException, InputStream). При блокирующем чтении тред останавливается, пока не получит из потока необходимые данные. Для этих самых распространенных случаев использование неблокирующего чтения не несет пользы, потому что сама запись пользователем консоли и жестким диском будет последовательной.
Чтение данных из сетевого подключения – другое дело. Обычно программа обрабатывает данные быстрее, чем работает сеть. Возникают паузы, в которые поток блокирующего чтения стоит в ожидании, не принося пользы. К тому же серверное приложение работает со многими параллельными подключениями.
Блокирующее чтение можно распараллеливать на потоки, читая в пулле. Но делать это нужно вручную, а количество одновременных подключений будет всё ещё ограничено количеством потоков-обработчиков, потоки буду всё ещё останавливаться без дела.
Для случаев, когда в вашем приложении ожидается большое количество подключений, был добавлен пакет стандартной библиотеки java.nio. С помощью NIO один тред может обслуживать несколько сетевых соединений одновременно, и переключаться между ними не теряя времени на ожидание данных.
IO использует потоки. данные приходят последовательно, и сами нигде не сохраняются. Если вы не обеспечили буферизацию вручную, нет возможности откатиться назад и прочитать уже пришедшие данные еще раз.
NIO сразу читает данные в буфер. Вы можете перемещаться по этому буферу перечитывая уже прочитанную ранее информацию. Плата за это – необходимость вручную следить, что буфер заполнен достаточным объемом данных для обработки, и что он не переполнился.
В этой статье приводится показательная аналогия. Блокирующее чтение – это телефонный разговор, неблокирующее – переписка в чате. Делая телефонный звонок, вы ждете пока собеседник ответит, можете «обрабатывать» только один звонок одновременно, получаете ответы сразу и не можете переслушать услышанный но забытый ответ. В мессенджере вы ведете несколько чатов одновременно, обращаетесь к истории переписки, но ответы на ваши сообщения приходят не всегда сразу, а порядок их получения неоднозначен.
👍19
Приглашаем на открытый урок, где мы разберем:
🗓 10 октября в 20:00 МСК
🆓 Бесплатно. Урок в рамках старта курса «Java Developer. Professional»
🔗 Ссылка на регистрацию : https://vk.cc/cCcwoh
Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576
Please open Telegram to view this post
VIEW IN TELEGRAM
👍5❤2🔥2
@javatasks #java
Please open Telegram to view this post
VIEW IN TELEGRAM
👍19🔥3❤2
Как реализовать паттерн producer/consumer?
Шаблон producer/consumer (производитель/потребитель) – простая и базовая реализация обмена данными между несколькими потоками. Поток-производитель отправляет объекты на условную обработку, потоки-потребители асинхронно принимают и обрабатывают их.
Общий вид решения выглядит так. Продюсер отправляет объекты в специальную коллекцию – буфер. Когда потребитель освобождается, он отправляет запрос на извлечение одного объекта из буфера. Если буфер пуст, потребитель блокируется и ждет, если буфер переполнен – ждет производитель.
На практике реализовать этот паттерн можно множеством способов. Самый правильный способ для применения в бою – использовать готовую реализацию из стандартной библиотеки, объект типа BlockingQueue.
На собеседовании обычно просят реализовать паттерн с нуля. Реализация представлена на изображении. Модификатор synchronized делает так, чтобы в каждый момент времени мог выполняться только один из методов, и только одним потоком. Этого достаточно для корректной работы пока буфер не пуст и не полон. При пустом или полном буфере управление явно перебрасывается на производителя или потребителя соответственно, с помощью методов notify() и wait().
Шаблону producer/consumer посвящена глава 5.3 книги Java Concurrency in Practice.
Сильно упрощая, на основе этого паттерна работают сервисы-брокеры сообщений: Rabbit MQ, Apache ActiveMQ и другие.
Шаблон producer/consumer (производитель/потребитель) – простая и базовая реализация обмена данными между несколькими потоками. Поток-производитель отправляет объекты на условную обработку, потоки-потребители асинхронно принимают и обрабатывают их.
Общий вид решения выглядит так. Продюсер отправляет объекты в специальную коллекцию – буфер. Когда потребитель освобождается, он отправляет запрос на извлечение одного объекта из буфера. Если буфер пуст, потребитель блокируется и ждет, если буфер переполнен – ждет производитель.
На практике реализовать этот паттерн можно множеством способов. Самый правильный способ для применения в бою – использовать готовую реализацию из стандартной библиотеки, объект типа BlockingQueue.
На собеседовании обычно просят реализовать паттерн с нуля. Реализация представлена на изображении. Модификатор synchronized делает так, чтобы в каждый момент времени мог выполняться только один из методов, и только одним потоком. Этого достаточно для корректной работы пока буфер не пуст и не полон. При пустом или полном буфере управление явно перебрасывается на производителя или потребителя соответственно, с помощью методов notify() и wait().
Шаблону producer/consumer посвящена глава 5.3 книги Java Concurrency in Practice.
Сильно упрощая, на основе этого паттерна работают сервисы-брокеры сообщений: Rabbit MQ, Apache ActiveMQ и другие.
👍19🔥3❤2❤🔥1
Какой будет результат?
Anonymous Quiz
12%
howl woof sniff
6%
howl howl затем ошибка
20%
howl howl sniff
11%
howl woof затем ошибка
14%
Ошибка компиляции в строке 12
37%
Ошибка компиляции в строке 13
🔥12👍8⚡2
This media is not supported in your browser
VIEW IN TELEGRAM
Станьте разработчиком нейро-сотрудников на Python и зарабатывайте от 150.000р в месяц 🔥🔥🔥
Мы научим вас создавать топовых нейро-сотрудников на базе GPT-4 Omni, и вы сможете:
1️⃣ Устроиться разработчиком в крупную компанию и зарабатывать от 150 тысяч ₽ в месяц
2️⃣ Разрабатывать такие проекты на заказ и зарабатывать от 500 тысяч ₽ за проект
3️⃣ Создать нейро-сотрудника в вашей компании и вырасти на +30-100% в зарплате
Что будет на интенсиве?
🧬 Теория: как создаются нейро-сотрудники с GPT-4o на Python
🧬 Практика: мы создадим нейро-консультанта, нейро-HR, нейро-маркетолога и др.
Ведущий интенсива - Senior AI разработчик нейросетей и основатель Университета искусственного интеллекта
🔥 Регистрируйтесь на бесплатный интенсив! Встречаемся в ближайший четверг!
Мы научим вас создавать топовых нейро-сотрудников на базе GPT-4 Omni, и вы сможете:
1️⃣ Устроиться разработчиком в крупную компанию и зарабатывать от 150 тысяч ₽ в месяц
2️⃣ Разрабатывать такие проекты на заказ и зарабатывать от 500 тысяч ₽ за проект
3️⃣ Создать нейро-сотрудника в вашей компании и вырасти на +30-100% в зарплате
Что будет на интенсиве?
🧬 Теория: как создаются нейро-сотрудники с GPT-4o на Python
🧬 Практика: мы создадим нейро-консультанта, нейро-HR, нейро-маркетолога и др.
Ведущий интенсива - Senior AI разработчик нейросетей и основатель Университета искусственного интеллекта
🔥 Регистрируйтесь на бесплатный интенсив! Встречаемся в ближайший четверг!
👍3🤩1🥴1
HashSet — это реализация множества (set), которое не допускает дублирующихся элементов. В его основе используется механизм хеширования для быстрого поиска, добавления и удаления элементов.
🔹 Хеш-таблица как основа
В основе HashSet лежит HashMap. Каждый элемент множества хранится в качестве ключа внутри объекта HashMap, а его значение всегда фиксированное — это специальный объект-заглушка. Этот объект используется для обозначения присутствия элемента, так как HashMap требует наличие пары "ключ-значение".
🔹 Хеширование
Когда вы добавляете элемент в HashSet, для него вычисляется хеш-код с помощью метода hashCode(). Этот хеш-код помогает определить, в какую "корзину" (bucket) поместится элемент. Если два элемента имеют одинаковый хеш-код (коллизия), они будут помещены в один и тот же бакет, и далее будут различаться с помощью метода equals().
🔹 Коллизии и структура бакета
До Java 8, если в бакет попадало несколько элементов (коллизия), они сохранялись в виде односвязного списка. Это приводило к тому, что в худшем случае производительность поиска и добавления элементов могла падать до O(n), если список становился слишком длинным.
С Java 8 при превышении 8 элементов в одном бакете, односвязный список преобразуется в красно-чёрное дерево, что улучшает производительность операций до O(log n). Когда количество элементов в бакете падает ниже 6, структура снова преобразуется обратно в связанный список для экономии памяти.
🔹 Добавление элементов
▪️ В среднем: добавление элемента занимает O(1), потому что благодаря хеш-кодам можно быстро находить нужную корзину для элемента.
▪️ В худшем случае: добавление элемента может занять O(n) до Java 8 (связный список) и O(log n) начиная с Java 8 (красно-чёрное дерево).
🔹 Удаление элементов
Удаление происходит также через хеш-код: ищется соответствующая корзина, а затем элемент удаляется, если он там есть. Сложность удаления аналогична добавлению: O(1) в среднем и O(n) или O(log n) в худшем случае (в зависимости от структуры бакета).
🔹 Преимущества и недостатки
▪️ Преимущества: Быстрое добавление, удаление и поиск элементов в среднем за O(1), так как используется хеширование. Улучшенная производительность с Java 8 благодаря использованию красно-чёрного дерева.
▪️ Недостатки: Не гарантирует порядок элементов, а при частых коллизиях, особенно в старых версиях Java, производительность может падать до O(n).
@javatasks #java
Please open Telegram to view this post
VIEW IN TELEGRAM
❤12👍9🔥5
Хотите научиться разрабатывать парсеры pdf-файлов и создавать полезные приложения?
Приглашаем на открытый урок «Разработка парсера pdf-файла».
🗓 24 октября в 20:00 МСК
🆓 Бесплатно. Урок в рамках старта курса «Java Developer. Professional»
На вебинаре разберем:
- как разработать парсер для выписки ВТБ банка в формате pdf;
- весь путь от идеи до практического применения;
- ответы на все возникающие вопросы.
⬇️ В результате урока вы получите практически полезное приложение с подробностями реализации.
Спикер Сергей Петрелевич — опытный Java/Kotlin-разработчик и преподаватель.
Все участники вебинара получат специальную цену на обучение!
🔗 Ссылка на регистрацию: https://vk.cc/cCF02o
Приглашаем на открытый урок «Разработка парсера pdf-файла».
🗓 24 октября в 20:00 МСК
🆓 Бесплатно. Урок в рамках старта курса «Java Developer. Professional»
На вебинаре разберем:
- как разработать парсер для выписки ВТБ банка в формате pdf;
- весь путь от идеи до практического применения;
- ответы на все возникающие вопросы.
Спикер Сергей Петрелевич — опытный Java/Kotlin-разработчик и преподаватель.
Все участники вебинара получат специальную цену на обучение!
🔗 Ссылка на регистрацию: https://vk.cc/cCF02o
Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576
Please open Telegram to view this post
VIEW IN TELEGRAM
👍4🥰3🔥2
Что такое 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.
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.
👏8
Присоединяйтесь к нашему бесплатному курсу и начните увлекательное путешествие в мир Java!
Изучайте основы, создавайте программы, разбирайтесь с методами и анализируйте ошибки в коде. Практика, упражнения и проверочные тесты помогут вам освоить навыки программирования.
🎓 Чему вы научитесь:
— Создавать программы с использованием основных конструкций языка.
— Разделять код на методы для повторного использования.
— Анализировать ошибки в коде с использованием отладочной печати.
💼 Включено в курс:
29 уроков (видео и/или текст), 35 упражнений в тренажере, 95 проверочных тестов + дополнительные материалы.
Вы с нами?😉
Изучайте основы, создавайте программы, разбирайтесь с методами и анализируйте ошибки в коде. Практика, упражнения и проверочные тесты помогут вам освоить навыки программирования.
🎓 Чему вы научитесь:
— Создавать программы с использованием основных конструкций языка.
— Разделять код на методы для повторного использования.
— Анализировать ошибки в коде с использованием отладочной печати.
💼 Включено в курс:
29 уроков (видео и/или текст), 35 упражнений в тренажере, 95 проверочных тестов + дополнительные материалы.
Вы с нами?😉
👍5🔥2🌚2☃1🥴1
Чем ForkJoinPool отличается от ExecutorService?
ForkJoinPool сам по себе является наследником ExecutorService. Вопрос подразумевает его отличия от обычного пула потоков – ThreadPoolExecutor.
Преимущества, которые дает work stealing по сравнению с обычным пулом:
• Сокращение расходов на переключение контекста;
• Защита от проблемы голодания потоков (thread starvation);
• Защита от дедлока для рекурсивных задач.
Как положено любому представителю ExecutorService, ForkJoinPool тоже умеет выполнять Runnable и Callable, но помимо этого работает и со специальными задачами ForkJoinTask, о которых также говорилось ранее.
Интерфейс настройки и мониторинга остается тем же, что и в классических тред-пулах.
Каждый обычный пул использует собственный набор потоков. ForkJoinPool по умолчанию использует общий пул-синглтон commonPool. Альтернативный отдельный пул всё еще можно задать в конструкторе.
ForkJoinPool сам регулирует количество запущенных потоков, достигая максимальной эффективности при заданном уровне параллелизма.
ForkJoinPool сам по себе является наследником ExecutorService. Вопрос подразумевает его отличия от обычного пула потоков – ThreadPoolExecutor.
Преимущества, которые дает work stealing по сравнению с обычным пулом:
• Сокращение расходов на переключение контекста;
• Защита от проблемы голодания потоков (thread starvation);
• Защита от дедлока для рекурсивных задач.
Как положено любому представителю ExecutorService, ForkJoinPool тоже умеет выполнять Runnable и Callable, но помимо этого работает и со специальными задачами ForkJoinTask, о которых также говорилось ранее.
Интерфейс настройки и мониторинга остается тем же, что и в классических тред-пулах.
Каждый обычный пул использует собственный набор потоков. ForkJoinPool по умолчанию использует общий пул-синглтон commonPool. Альтернативный отдельный пул всё еще можно задать в конструкторе.
ForkJoinPool сам регулирует количество запущенных потоков, достигая максимальной эффективности при заданном уровне параллелизма.
🔥12👍5
Ответ:
@javatasks #java
Please open Telegram to view this post
VIEW IN TELEGRAM
👍24🔥5❤4
@javatasks #java
Please open Telegram to view this post
VIEW IN TELEGRAM
👍29🔥5👏2
Какие брокеры использовать, чтобы обеспечить асинхронную связь между микросервисами?
Узнайте на открытом практическом уроке «Брокеры сообщений: RabbitMQ и Kafka» от OTUS, где мы узнаем:
✅ что такое брокеры сообщений и как они помогают в архитектуре микросервисов
✅ основные различия между RabbitMQ и Kafka, включая их архитектурные подходы
✅ как развернуть и настроить RabbitMQ и Kafka для ваших приложений
✅ практическое использование обоих брокеров на реальных примерах в live demo
🗓 Встречаемся 24 октября в 20:00 мск в преддверии старта курса «Microservice Architecture». Все участники вебинара получат специальную цену на обучение и консультацию от менеджеров OTUS!
➡️ Ссылка для регистрации: https://vk.cc/cD4UHz
Узнайте на открытом практическом уроке «Брокеры сообщений: RabbitMQ и Kafka» от OTUS, где мы узнаем:
✅ что такое брокеры сообщений и как они помогают в архитектуре микросервисов
✅ основные различия между RabbitMQ и Kafka, включая их архитектурные подходы
✅ как развернуть и настроить RabbitMQ и Kafka для ваших приложений
✅ практическое использование обоих брокеров на реальных примерах в live demo
🗓 Встречаемся 24 октября в 20:00 мск в преддверии старта курса «Microservice Architecture». Все участники вебинара получат специальную цену на обучение и консультацию от менеджеров OTUS!
➡️ Ссылка для регистрации: https://vk.cc/cD4UHz
Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576
👍7🥰3🔥2
Параллелизм и многопоточность — это два разных, но связанных понятия в программировании. Многопоточность означает
Параллелизм, с другой стороны, означает
@javatasks #java
Please open Telegram to view this post
VIEW IN TELEGRAM
👍17🔥6