Библиотека Java разработчика
📚 Лайфхаки, приёмы и лучшие практики для Java-разработчиков. Всё, что ускорит код и прокачает навыки. Java, Spring, Maven, Hibernate. По всем вопросам @evgenycarter РКН clck.ru/3KoGeP
Show more📈 Analytical overview of Telegram channel Библиотека Java разработчика
Channel Библиотека Java разработчика (@bookjava) in the Russian language segment is an active participant. Currently, the community unites 10 264 subscribers, ranking 12 013 in the Technologies & Applications category and 63 881 in the Russia region.
📊 Audience metrics and dynamics
Since its creation on невідомо, the project has demonstrated rapid growth, gathering an audience of 10 264 subscribers.
According to the latest data from 12 June, 2026, the channel demonstrates stable activity. Although there has been a change in the number of participants by 8 over the last 30 days and by 1 over the last 24 hours, overall reach remains high.
- Verification status: Not verified
- Engagement rate (ER): The average audience engagement rate is 8.51%. Within the first 24 hours after publication, content typically collects 4.36% reactions from the total number of subscribers.
- Post reach: On average, each post receives 873 views. Within the first day, a publication typically gains 447 views.
- Reactions and interaction: The audience actively supports content: the average number of reactions per post is 6.
- Thematic interests: Content is focused on key topics such as string, интерфейс, строка, boot, api.
📝 Description and content policy
The author describes the resource as a platform for expressing subjective opinions:
“📚 Лайфхаки, приёмы и лучшие практики для Java-разработчиков. Всё, что ускорит код и прокачает навыки. Java, Spring, Maven, Hibernate.
По всем вопросам @evgenycarter
РКН clck.ru/3KoGeP”
Thanks to the high frequency of updates (latest data received on 13 June, 2026), the channel maintains relevance and a high level of publication reach. Analytics show that the audience actively interacts with content, making it an important point of influence in the Technologies & Applications category.
java.io.
Каналы. Реализации интерфейса Channel – сущности, представляющие соединения между разными участниками ввода-вывода (файлы, сокеты, консоль).
Селекторы. Наследники класса Selector. «Мультиплексоры» каналов – комбинируют несколько каналов в один. Регистрация канала в селекторе возвращает SelectionKey, который содержит ссылку на сам канал, и ряд его атрибутов. Селектор позволяет выбрать из набора зарегистрированных каналов подмножество готовых к работе, при необходимости блокируя выполнение на время ожидания. Каналы и селекторы располагаются в пакете java.nio.channels. Полный пример использования селекторов можно найти в статье на baeldung.
Кодировки. Charset – то, как бинарные данные будут конвертироваться в родные для Java символы UTF-16 и обратно. Классы для работы с кодировками хранятся в пакете java.nio.charset.
#Сеть
#МногопоточностьBlockingQueue.
На собеседовании обычно просят реализовать паттерн с нуля. Реализация представлена на изображении ниже. Модификатор synchronized делает так, чтобы в каждый момент времени мог выполняться только один из методов, и только одним потоком. Этого достаточно для корректной работы пока буфер не пуст и не полон. При пустом или полном буфере управление явно перебрасывается на производителя или потребителя соответственно, с помощью методов notify() и wait().
Шаблону producer/consumer посвящена глава 5.3 книги Java Concurrency in Practice.
Сильно упрощая, на основе этого паттерна работают сервисы-брокеры сообщений: Rabbit MQ, Apache ActiveMQ и другие.
#Многопоточностьjava.io. Вы наверняка много раз сталкивались с ними, работая с файлами и консольным вводом-выводом (классы Reader, IOException, InputStream). При блокирующем чтении тред останавливается, пока не получит из потока необходимые данные. Для этих самых распространенных случаев использование неблокирующего чтения не несет пользы, потому что сама запись пользователем консоли и жестким диском будет последовательной.
Чтение данных из сетевого подключения – другое дело. Обычно программа обрабатывает данные быстрее, чем работает сеть. Возникают паузы, в которые поток блокирующего чтения стоит в ожидании, не принося пользы. К тому же серверное приложение работает со многими параллельными подключениями.
Блокирующее чтение можно распараллеливать на потоки, читая в пулле. Но делать это нужно вручную, а количество одновременных подключений будет всё ещё ограничено количеством потоков-обработчиков, потоки буду всё ещё останавливаться без дела.
Для случаев, когда в вашем приложении ожидается большое количество подключений, был добавлен пакет стандартной библиотеки java.nio. С помощью NIO один тред может обслуживать несколько сетевых соединений одновременно, и переключаться между ними не теряя времени на ожидание данных.
IO использует потоки. данные приходят последовательно, и сами нигде не сохраняются. Если вы не обеспечили буферизацию вручную, нет возможности откатиться назад и прочитать уже пришедшие данные еще раз.
NIO сразу читает данные в буфер. Вы можете перемещаться по этому буферу перечитывая уже прочитанную ранее информацию. Плата за это – необходимость вручную следить, что буфер заполнен достаточным объемом данных для обработки, и что он не переполнился.
В этой статье приводится показательная аналогия. Блокирующее чтение – это телефонный разговор, неблокирующее – переписка в чате. Делая телефонный звонок, вы ждете пока собеседник ответит, можете «обрабатывать» только один звонок одновременно, получаете ответы сразу и не можете переслушать услышанный но забытый ответ. В мессенджере вы ведете несколько чатов одновременно, обращаетесь к истории переписки, но ответы на ваши сообщения приходят не всегда сразу, а порядок их получения неоднозначен.
Для более подробного изучения можно начать со статьи на хабре, в статье на dzone приведены примеры использования разных подходов на практике.
#Сеть
#Многопоточностьmain(), выполняется в потоках. Поток, в котором было выброшено и не обработано исключение, остановится, и распечатает стектрейс в вывод System.err. Если это был последний пользовательский поток, приложение начнет завершение работы.
Для изменения логики обработки непойманных исключений в Java существует функциональный интерфейс Thread.UncaughtExceptionHandler.
Обработчик упущенных исключений может быть установлен (в порядке возрастания приоритета):
• глобально на всё приложение, статическим методом Thread.setDefaultUncaughtExceptionHandler();
• для группы потоков, переопределением метода uncaughtException() в реализации объекта подкласса ThreadGroup (т.к. ThreadGroup сам является наследником UncaughtExceptionHandler);
• для отдельного потока, методом setUncaughtExceptionHandler().
Естественно, установка нестандартного обработчика не имеет обратной силы. Используя его, нужно убедиться, что он установлен достаточно рано, до выброса какого-либо исключения.
Хорошей практикой считается обрабатывать исключение настолько близко к месту его выброса, насколько возможно. Следовательно, использование глобальных обработчиков – самый плохой вариант.
Так же как в случае различных финализаций, несмотря на все её недостатки, глобальная обработка иногда лучше, чем ничего. Она может, например, дать последний шанс освободить внешние ресурсы, или уведомить о некорректной работе программы более эффективно, чем через логи.
Когда код с исключением выполняет ExecutorService, мы не имеем прямого доступа к объектам потока. Но в этом случае результатом выполнения будет объект типа Future. Такой отложенный объект при попытке прочитать значение перевыбросит полученное исключение, завернув его в ExecutionException. Новое исключение-обертка уже пойдет по обычному пути обработки текущего потока. Исключение как бы перекочует из внутреннего потока пулла во внешний, который использует этот пулл.
Если же пользовательский код не станет дожидаться результатов, исключение будет потеряно, не оставив даже стектрейса в потоке вывода. Для предотвращения такой ситуации стоит снабдить поток обработчиком сразу после создания, определив для сервиса собственную ThreadFactory.
Обычно, если фреймворк скрывает от пользователя детали работы с потоками, он также скрывает и детали работы с исключениями, оставляя свой специальный способ назначить обработчик. И этот специальный обработчик – более специфичный, а значит более правильный подход, чем стандартная глобальная обработка исключений Java. Так, например, в Spring MVC применяется аннотация @ExceptionHandler.
#JVM
#МногопоточностьThread, и передаются в Runtime.getRuntime().addShutdownHook().
При использовании обработчика нужно учитывать ряд нюансов:
1. Нет гарантии, что он будет выполнен целиком, и выполнен вообще. Хуки вызываются при нормальном завершении программы – завершении всех пользовательских потоков или вызове System.exit(). Например вызов System.halt() или получение от системы SIGKILL программа завершится незамедлительно. Это может случиться как до выполнения обработчиков, так и во время. Сигнал SIGTERM запустит обработчики, но ОС может не дождаться завершения и оборвать процесс.
2. В хуке нельзя использовать System.exit(0). Завершить работу можно ненулевым кодом, или методом System.halt(). Возврат нулевого кода после старта хуков приведет к зависанию программы.
3. Набор обработчиков задается до их старта. Когда процесс обработки начался, новый вызов addShutdownHook() вызовет исключение.
4. Нет гарантий о порядке выполнения. Если обработчиков несколько, они могут вызываться в случайном порядке, и даже параллельно, в соседних потоках. Об этом намекает и форма объявления обработчика – класс Thread.
Больше деталей об особенностях обработчиков смотрите в официальных вопросах и ответах о Shutdown Hooks API.
#JVMThread, передать им инстансы Runnable, с нужными задачами в реализации их методов run, и запустить вызвав thread.start(). Если в основном потоке нужно дождаться завершения задач – после start() вызывается метод thread.join(). Исполнение зависнет на вызове этого метода до тех пор, пока тред не закончит свою задачу и не умрет. Вся работа задач с внешними данными должна быть синхронизирована.
Такое ручное создание тредов полезно в учебных целях, но считается плохой практикой в промышленном коде: само создание – дорогостоящая операция, а большое количество случайно созданных потоков может приводить к проблеме голодания (starvation) потоков.
В качестве продвинутой альтернативы используются пуллы потоков – реализации интерфейса ExecutorService. Такие сервисы создаются статическими фабричными методами класса Executors. Они умеют принимать задачи в виде Runnable- или Callable-объектов на заранее созданном наборе потоков (собственно, пулле).
Кроме самого пулла, экземпляры ExecutorService содержат фабрику потоков («инструкцию» как создать тред при необходимости), и коллекцию-очередь задач на исполнение.
В ответ на передачу на исполнение Runnable или Callable, сервис возвращает связанный с ним объект типа Future – хранилище, которое будет заполнено результатом выполнения задачи в будущем. Даже если никакого результата не ожидается, Future поможет дождаться момента завершения обработки задачи.
В Android для асинхронного выполнения используется похожая сущность – Looper.
#МногопоточностьThreadLocal представляет хранилище тред-локальных переменных. По способу использования он похож на обычную обертку над значением, с методами get(), set() и remove() для доступа к нему, и дополнительным фабричным методом ThreadLocal.withInitial(), устанавливающим значение по-умолчанию.
Отличие тред-локальной переменной от обычной в том, что ThreadLocal хранит отдельную независимую копию значения для каждого ее использующего потока. Работа с такой переменной потокобезопасна.
Проще говоря, объект класса ThreadLocal хранит внутри не одно значение, а как бы хэш-таблицу поток➝значение, и при использовании обращается к значению для текущего потока.
Первый, самый очевидный вариант использования – данные, относящиеся непосредственно к треду, определенный пользователем «контекст потока». На скриншоте ниже пример такого использования: ThreadId.get() вернет порядковый номер текущего треда.
Другой случай, с которым локальная переменная потока может помочь – кэширование read-only данных в многопоточной среде без дорогостоящей синхронизации.
Помимо обычного ThreadLocal, в стандартной библиотеке присутствует его расширение InheritableThreadLocal. Этот класс «наследует» значение – изначально берет его для потока, являющегося родителем текущего.
#МногопоточностьВсе уроки записаны в 2022 году, материал обновлен и дополнен.
Спикеры:
Марсель Ибраев (Southbridge)
Павел Селиванов (Yandex Cloud).
Форматы обучения:
Поток: открываем доступ к двум новым темам каждую неделю, общаемся в чате с куратором и спикерами, два раза в неделю — AMA-сессии по темам курса со спикерами.
Видеокурс: доступны сразу все темы, можно изучать в своём темпе.
Оба формата включают практику на стендах и итоговую сертификацию.
Подробнее про курс: https://slurm.club/3xBZu13
Available now! Telegram Research 2025 — the year's key insights 
