Вже доступно! Дослідження Telegram за 2025 — головні інсайти року 
Java: fill the gaps
Відкрити в Telegram
Привет! Меня зовут Диана, и я занимаюсь разработкой с 2013. Здесь пишу просто и понятно про джава бэк 🔥Тот самый курс по многопочке🔥 https://fillthegaps.ru/mt Комплименты, вопросы, предложения: @utki_letyat
Показати більше📈 Аналітичний огляд Telegram-каналу Java: fill the gaps
Канал Java: fill the gaps (@java_fillthegaps) у мовному сегменті Російська є активним учасником. На даний момент спільнота об'єднує 12 543 підписників, посідаючи 10 113 місце в категорії Технології та додатки та 52 819 місце у регіоні Росія.
📊 Показники аудиторії та динаміка
З моменту свого створення невідомо, проект продемонстрував стрімке зростання, зібравши аудиторію у 12 543 підписників.
За останніми даними від 08 червня, 2026, канал демонструє стабільну активність. Хоча за останні 30 днів спостерігається зміна кількості учасників на -43, а за останні 24 години на -3, загальне охоплення залишається високим.
- Статус верифікації: Не верифікований
- Рівень залученості (ER): Середній показник залученості аудиторії становить 34.73%. Протягом перших 24 годин після публікації контент зазвичай збирає N/A% реакцій від загальної кількості підписників.
- Охоплення публікацій: В середньому кожен допис отримує 0 переглядів. Протягом першої доби публікація в середньому набирає 0 переглядів.
- Реакції та взаємодія: Аудиторія активно підтримує контент: середня кількість реакцій на один пост – 0.
- Тематичні інтереси: Контент зосереджений навколо ключових тем, таких як redis, hashmap, linkedhashmap, индекс, фича.
📝 Опис та контентна політика
Автор описує ресурс як майданчик для висловлення суб'єктивної думки:
“Привет! Меня зовут Диана, и я занимаюсь разработкой с 2013. Здесь пишу просто и понятно про джава бэк
🔥Тот самый курс по многопочке🔥
https://fillthegaps.ru/mt
Комплименты, вопросы, предложения: @utki_letyat”
Завдяки високій частоті оновлень (останні дані отримано 09 червня, 2026), канал підтримує актуальність та високий рівень охоплення публікацій. Аналітика показує, що аудиторія активно взаємодіє з контентом, що робить його важливою точкою впливу в категорії Технології та додатки.
12 543
Підписники
-324 години
-207 днів
-4330 день
Архів дописів
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 доступен один нативный метод, который работает только с миллисекундами. Поэтому результат не очень удивляет. Но зачем тогда нужен второй метод?
#core12 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
