Java: fill the gaps

Open in Telegram

Привет! Меня зовут Диана, и я занимаюсь разработкой с 2013. Здесь пишу просто и понятно про джава бэк 🔥Тот самый курс по многопочке🔥 https://fillthegaps.ru/mt Комплименты, вопросы, предложения: @utki_letyat

Russia52 819 Technologies & Applications10 113...

📈 Analytical overview of Telegram channel Java: fill the gaps

Channel Java: fill the gaps (@java_fillthegaps) in the Russian language segment is an active participant. Currently, the community unites 12 543 subscribers, ranking 10 113 in the Technologies & Applications category and 52 819 in the Russia region.

📊 Audience metrics and dynamics

Since its creation on невідомо, the project has demonstrated rapid growth, gathering an audience of 12 543 subscribers.

According to the latest data from 08 June, 2026, the channel demonstrates stable activity. Although there has been a change in the number of participants by -43 over the last 30 days and by -3 over the last 24 hours, overall reach remains high.

Verification status: Not verified
Engagement rate (ER): The average audience engagement rate is 34.73%. Within the first 24 hours after publication, content typically collects N/A% reactions from the total number of subscribers.
Post reach: On average, each post receives 0 views. Within the first day, a publication typically gains 0 views.
Reactions and interaction: The audience actively supports content: the average number of reactions per post is 0.
Thematic interests: Content is focused on key topics such as redis, hashmap, linkedhashmap, индекс, фича.

📝 Description and content policy

The author describes the resource as a platform for expressing subjective opinions:
“Привет! Меня зовут Диана, и я занимаюсь разработкой с 2013. Здесь пишу просто и понятно про джава бэк 🔥Тот самый курс по многопочке🔥 https://fillthegaps.ru/mt Комплименты, вопросы, предложения: @utki_letyat”

Thanks to the high frequency of updates (latest data received on 09 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.

12 543

Subscribers

-324 hours

-207 days

-4330 days

4 358

Post views

No data24 hours

No data48 hours

34.73%

Engagement rate

No data

Posts per day

Ads index

beta

Posts Archive

12 543

Виды многозадачности Сегодня выйдем за пределы JVM и посмотрим на многопоточность на уровне ОС. Многопоточность — когда в одном процессе параллельно работают несколько потоков. Многозадачность — несколько процессов параллельно исполняются в ОС. При этом параллельно — не значит одновременно. Процесс/поток использует ресурсы процессора некоторое время, потом выполнение прерывается, ОС сохраняет временные данные (контекст), а ресурсы переходят на другой процесс/поток. Загружается контекст другой задачи, и выполнение продолжается. Многозадачность бывает двух типов: 1. Вытесняющая. ОС выделяет кванты времени для каждой задачи и управляет их переключением. Так работают потоки в джаве, а также процессы в современных ОС. ✅ не нужно думать о переключении задач, всё делает ОС ✅ повисшая задача не блокирует остальные ❌ сложная работа с общими ресурсами ❌сложно координировать связанные параллельные задачи 2. Кооперативная. Программа/поток сами сигнализируют, что пора сохранить контекст и переключиться на другую задачу. Так были организованы ОС давным-давно. В прикладных программах эта модель реализуется через fibers – «легковесные потоки», которые исполняются на одном потоке ОС и имеют собственный планировщик. ✅ переключение контекста происходит в 10-100 раз быстрее ✅ проще работа с общими ресурсами, не нужно часто синхронизироваться ✅ эффективная обработка некоторого типа задач ❌ увеличенная сложность разработки ❌ ошибка в одной задаче сильно влияет на другие, вплоть до остановки основного процесса По умолчанию для java программ используется вытесняющая многозадачность. Однако преимущества кооперативной модели можно получить с помощью некоторых библиотек или конструкций из котлина. #fillthegaps_mt #java #multitasking #fibers #preemptive #cooperative

12 543

Бесполезная калибровка Thread.sleep или как JDK создаёт иллюзию выбора. Все знают метод sleep(long millis) у класса Thread. Он останавливает выполнение потока на заданное количество миллисекунд. Также в классе есть похожий метод sleep(long millis, int nanos). Здравый смысл подсказывает, что это тот же sleep, только время приостановки задаётся точнее. Документация к методу подтверждает нашу догадку: ...sleep for the specified number of milliseconds plus the specified number of nanoseconds. Что тут ещё обсуждать? Расходимся! Но всё же посмотрим в код. После проверок на валидность, видим следующие строки:

if (nanos >= 500000 || (nanos != 0 && millis == 0)) {
 millis++;
}
sleep(millis);

То есть прибавить 1 миллисекунду, если наносекунд больше 500к. Или выставить паузу в 1 миллисекунду, если микросекунд 0, а наносекунд не 0. У JVM доступен один нативный метод, который работает только с миллисекундами. Поэтому результат не очень удивляет. Но зачем тогда нужен второй метод? #core

12 543

Нужно ли разбираться в многопоточке если на проекте она используется на базовом уровне? Ответ простой: надо. Это базовая часть функционала JDK. Если этого мало, вот ещё причины углубить знания: 1. Заодно изучаешь более сложные алгоритмы и структуры данных, организацию JVM и ещё много интересного. Эта тема - самая близкая к реальным проблемам область языка. 2. Видишь проблемы в коде, которые невозможно поймать на тестировании, но которые обязательно проявятся на продакшене. 3. Увидишь, как оптимизировать ресурсы и ускорить работу системы. 4. Серьёзно увеличиваешь свой рейтинг в коллективе и на собеседованиях Многопоточное программирование — тесная связь теории и практики. Если ты иногда читаешь статьи по теме, то ты не станешь мастером многопоточки, здесь нужен основательный подход. Большинство видео на youtube, курсов и статей дают поверхностный обзор инструментов, основываются на java 7 и устарели. В них много воды и мало практики. Я потратила много времени на изучение многопоточности. Читала сотни статей лучших экспертов, разбиралась в исходниках JDK, применяла на своих проектах и смотрела кейсы других компаний. Изучение и сравнение инструментов порождает много вопросов. Когда использовать одно, а когда другое? Это действительно влияет на производительность, или разница не так велика, чтобы тратить усилия? Сейчас я работаю над полным и актуальным курсом по многопоточности в java 13. От основ до тонкостей использования. Этот курс поможет разобраться в теме , эффективно применять свои знания и, самое главное, серьёзно сэкономит ваше время. Планирую закончить курс уже в следующем месяце, stay tuned. #fillthegaps_mt #multithreading #learning #fillthegaps_course

12 543

Как удалить элементы из коллекции? Допустим, мы хотим удалить устаревшие или неправильные значения из коллекции. Если менять коллекцию во время обхода, то результаты будут неоднозначны, поэтому в JDK в таком случае бросается ConcurrentModificationException. Популярный способ решения такой задачи — проверять элементы и складывать кандидатов на удаление в отдельную коллекцию. Затем эту коллекцию удалить из исходной (рисунок 1). Второй вариант — использовать метод remove() в интерфейсе Iterator, тогда можно обойтись без дополнительной коллекции (рисунок 2) Счастливым пользователям джавы 8+ доступна короткая запись (рисунок 3): Если метод не синхронизирован, то результат будет неточным во всех вариантах — кандидаты на удаление могут появиться в коллекции уже во время обхода итератора. Удаляйте элементы с умом и делайте это красиво! #fillthegaps_mt #multithreading #java #collections

12 543

Как стать лучшим разработчиком Главное конкурентное преимущество любого специалиста — знать правила и понимать когда, где и зачем они нужны. Нормальный разработчик решает проблемы по мере поступления, учится тому, что пригодится в работе, бессистемно читает статьи по разным темам. Хороший разработчик углубляет текущие знания, смотрит лекции по другим технологиям, читает фундаментальные книги. Лучший разработчик делает то же, что и хороший. Но не просто поглощает факты, а разбирается, почему всё работает именно так. Какие границы применимости у новых знаний. Чем один подход лучше другого. Недостаточно заучить типовые ситуации и типовые решения. В лекциях даются упрощённые однобокие примеры. На каждом проекте свои проблемы, подходы и технологии. У каждой задачи несколько решений. Анализируйте то, что делаете. Даже если вы ещё джуниор или мидл, и задачи выглядят как «напиши это по подобию того». Посмотрите на задачу шире и постарайтесь понять, почему сделано так, а не иначе. Когда читаете статьи и смотрите лекции задавайте себе вопрос - как ещё решить исходную проблему? Когда мой вариант лучше варианта из статьи? Сначала будет казаться, что других достойных опций нет, но со временем вы будете видеть их всё чаще. Мгновенного профита от такого процесса не будет, но если привычка закрепится — вы будете на голову выше своих коллег. Чем выше должность - тем больше принимаемых решений и тем важнее навык критического мышления. В разработке ПО полно инертности. Однажды выбранные способы решения выбираются снова и снова. Thinking out of the box — самый редкий и ценный навык и над ним тоже нужно работать. #soft_skills

12 543

Fairness. Честная многопоточность. Одна из проблем многопоточного программирования называется starvation. Её суть в том, что поток не может получить доступ к общим ресурсам и продолжать работу. Так получается, если: - у потока низкий приоритет, - другие потоки захватывают доступ к критической секции быстрее, - поток вызвал wait() у объекта, но notify() достаётся другим потокам. Ситуация неприятная: ресурсы потока заняты, а задача не выполняется. Чтобы избежать проблем выше можно использовать средства синхронизации с флажком fairness = true. Например, Lock lock = new ReentrantLock(true); Что при этом происходит? И почему этот параметр по умолчанию false? При fairness=true преимущество получает самый долго ожидающий поток. При этом вероятность starvation ощутимо снижается. Конкретная очередность не гарантируется, так как параметр не влияет на планировщик потоков в ОС. Пропускная способность при этом ухудшается в разы Интересный факт: tryLock() не обращает внимания на параметр fairness и постарается захватить блокировку, даже если в очереди стоят другие потоки. tryLock(0, TimeUnit.SECONDS) учитывает fairness и при наличии других ожидающих потоков встанет в общую очередь. Что же делать? Использовать флажок fairness или нет? Если описанные выше проблемы возможны и критичны, надёжнее использовать tryLock с увеличивающимся временем ожидания и не полагаться на fairness. #core