🐸 Библиотека джависта

#DevLife

⚙️ Как работает Garbage Collector

Механизм сборки мусора в JVM — это не просто “магия, которая чистит память”, а сложная система, работающая по поколениям, фазам и стратегиям.

Понимание его внутренней архитектуры важно, если вы хотите управлять производительностью, избегать утечек и эффективно настраивать параметры JVM.

🔹 Архитектура: как устроена куча (Heap)

Куча памяти делится на поколения:

Heap
├── Young Generation
│   ├── Eden Space
│   └── Survivor Spaces (S0, S1)
└── Old Generation (Tenured)

Eden — вновь созданные объекты.
Survivor — те, кто “выжил” после первой сборки.
Old Gen — объекты, пережившие несколько сборок, считаются “долгоживущими”.

Дополнительно есть Metaspace (с Java 8), где хранятся данные о классах.

🔹 Алгоритм работы GC: по фазам

1. Mark
GC начинает с “корневых” ссылок (стек, глобальные переменные) и помечает все достижимые объекты.

2. Sweep
Удаляются все немаркированные объекты — они считаются “мертвыми”.

3. Compact (в некоторых GC)
Уплотнение памяти: “живые” объекты перемещаются ближе друг к другу, чтобы избежать фрагментации.

🔹 Типы сборок

1. Minor GC
Запускается при заполнении Eden. Очищаются только молодые поколения. Быстро, но может происходить часто.

2. Major GC / Full GC
Включает Old Gen и Metaspace. Дорогая операция, может “заморозить” все потоки (stop-the-world pause).

🔹 Типы сборщиков и их принципы

— Serial GC: однопоточная сборка. Просто и медленно.
— Parallel GC: многопоточная сборка всех поколений. Высокая пропускная способность.
— G1 GC: делит кучу на регионы, параллельно собирает “Region Set”. Поддерживает предсказуемые паузы.
— ZGC: целиком конкурентный сборщик. Работает с огромными кучами (до терабайта), паузы <10 мс.
— Shenandoah: минимальные паузы за счёт почти полной конкуренции с пользовательскими потоками.

🔹 Как GC определяет, что объект мёртв?

GC не использует reference count. Он строит граф достижимости:
1. Начинает с “корней” (GC roots)
2. Если оттуда нельзя добраться до объекта — он считается мусором
3. Это позволяет избежать утечек при циклических ссылках

🔹 Советы по оптимизации

— Избегайте долгоживущих ссылок (static, ThreadLocal) без необходимости
— Используйте WeakReference, если хотите избежать удержания объекта GC
— Кэшируйте объекты осознанно — утечка через Map может быть незаметной
— Задавайте лимиты памяти (-Xms512m -Xmx1024m)

💬 Ловили OutOfMemoryError в проде когда-нибудь?

══════ Навигация ══════
Вакансии • Задачи • Собесы

🐸 Библиотека джависта

#CoreJava #лучшее2025

😮 Топ-вакансий для джавистов за неделю

Java Developer — офис (Москва)

Java Developer (Middle) — 100 000 – 200 000 ₽ — офис (Тольятти)

Java-разработчик — 300 000 —‍ 490 000 ₽ — офис/Гибрид (Москва)

➡️ Еще больше топовых вакансий — в нашем канале Java jobs

🐸 Библиотека джависта

#DevLife

👑 Магия IntelliJ IDEA: Ctrl+E

Переключаешься между файлами через Project View? Теряешь время на поиск нужной вкладки среди десятка открытых? Есть способ быстрее.

🔹 Что это

Ctrl+E (Recent Files) — показывает список недавно открытых файлов. Быстрый доступ к тому, с чем ты работал последние 5-10 минут.

🔹 Что умеет

— Показать последние открытые файлы.
— Переключиться на файл по первым буквам названия.
— Видеть структуру директорий для контекста.
— Отметить часто используемые файлы звёздочкой.
— Фильтровать список прямо в окне поиска.

🔹 Зачем это нужно

— Не нужно искать файл в дереве проекта.
— Быстрее, чем кликать по вкладкам.
— Видишь историю своей работы.
— Меньше отвлекаешься от кода.

🎯 Бонус

— Нажми Ctrl+E дважды — увидишь только недавно редактированные файлы.
— Начни печатать — список отфильтруется автоматически.
— Стрелками вверх/вниз быстро переключаешься между последними 2-3 файлами.

══════ Навигация ══════
Вакансии • Задачи • Собесы

🐸 Библиотека джависта

#Enterprise

⌛ Сохраняйте шпаргалку по командам git

══════ Навигация ══════
Вакансии • Задачи • Собесы

🐸 Библиотека джависта

#Enterprise

💼⌛️ ТОП-5 причин, почему программист не может долго найти работу

Почему некоторые разработчики остаются "между работами" месяцы?

Не всегда дело в нехватке вакансий или «рынок просел». Часто дело в подходе к поиску проекта. Вроде бы есть опыт, стек, даже pet-проекты, но офферов всё нет.

Часто корень проблемы — неумение продать себя правильно. Отказ выполнять тестовые задания, считая их ненужными или обидными. Кроме того, нежелание рассматривать стажировки как стартовую площадку для получения опыта и расширения профессиональных связей также может замедлить процесс трудоустройства. И это далеко не все возможные причины.

🔗 Подробнее в статье

══════ Навигация ══════
Вакансии • Задачи • Собесы

🐸 Библиотека джависта

#CoreJava #лучшее2025

🐸 Библиотека джависта

#DevLife

❓ Как бы вы оптимизировали запрос с JOIN?

— Создание индексы на колонках, которые используются для соединений. Это ускорит поиск строк, особенно если соединяемые таблицы большие.

— Если возможно, уменьшить размер данных, участвующих в соединении. Для этого можно использовать подзапросы или фильтровать данные до соединения.

— Использование правильного типа JOIN.

— EXPLAIN для анализа выполнения запроса и выявления узких мест. Это покажет, как именно СУБД обрабатывает запрос и на каких этапах происходят замедления.

— Если запросы с JOIN используются часто, создать материализованные представления для хранения результатов, что снизит нагрузку на базу данных при повторных обращениях.

— Рассмотреть варианты изменения структуры БД (например, денормализация).

🐸 Библиотека собеса по Java

#core #лучшее2025

📈 Как «ленивая разработка» захватывает IT-рынок

Пока мы выстраиваем архитектуру, пишем тесты и спорим о лучших практиках, рынок всё активнее обживают те, кто вообще не пишет код. Low-code и no-code решения не просто живы — они становятся нормой для бизнеса.

Порог входа минимальный, скорость разработки — бешеная, а заказчику всё равно, написано ли это на Java или накликано в визуальном редакторе. Вопрос: как долго останется актуальной классическая разработка?

🔗 Подробнее в статье

══════ Навигация ══════
Вакансии • Задачи • Собесы

🐸 Библиотека джависта

#CoreJava #лучшее2025

🐸 Библиотека джависта

#DevLife

⚡️ Параллельные стримы: ускорение или нет?

Java предоставляет мощный инструмент для обработки данных — параллельные стримы. Они позволяют автоматически распределять вычисления по нескольким потокам, но их эффективность зависит от множества факторов.

Добавление parallelStream() бездумно — это не "оптимизация", а лотерея с шансом на баги и падение.

❌ Когда не использовать

— При небольшом наборе данных (<10 000 элементов) затраты на управление потоками могут превышать прирост скорости.
— Операции sorted(), distinct() или limit() требуют полного знания данных, что снижает эффективность параллельного выполнения.
— Вложенные parallelStream() в CompletableFuture или ExecutorService могут привести к конкуренции за ресурсы и неожиданному падению производительности.

✔️ Когда использовать

— Обработка больших объёмов данных (100 000+ элементов).
— Операции независимы и ресурсоёмки, например, сложные вычисления, парсинг файлов, загрузка данных из сети.

🔍 Важная особенность

parallelStream() использует ForkJoinPool.commonPool(). Если есть другие задачи, использующие этот же пул, они могут начать конкурировать за потоки, замедляя всё приложение.

💬 Делитесь в комментах интересными кейсами

══════ Навигация ══════
Вакансии • Задачи • Собесы

🐸 Библиотека джависта

#CoreJava #лучшее2025

🐸 Библиотека джависта

#DevLife

👑 Магия IntelliJ IDEA: покрытие тестами

Запускаешь тесты, они зелёные, и ты думаешь всё ок? А потом баг на проде в ветке, которую никто не проверил. IDEA умеет показывать, что реально покрыто тестами.

🔹 Что это

Run with Coverage — запуск тестов с визуализацией покрытия кода. Видишь прямо в редакторе, какие строки покрыты тестами, а какие нет.

🔹 Как запустить

— Ctrl+Shift+F10 → выбрать "Run with Coverage".
— Или правой кнопкой на тест/класс → "More Run/Debug" → "Run with Coverage".
— Или через иконку щита рядом с кнопкой Run.

🔹 Что показывает

→ Зелёная полоска слева от кода — строка выполнилась.
→ Красная полоска — строка не покрыта тестами.
→ Жёлтая полоска — ветка покрыта частично (if выполнился, else — нет).
→ Окно Coverage — статистика по классам, пакетам, методам.

🔹 Фишки

→ Кликни на класс в Coverage window → увидишь его code coverage.
→ Кликни на жёлтую полоску → IDEA покажет, какая именно ветка не покрыта.
→ Сортируй классы по проценту покрытия — найдёшь слабые места.
→ Экспортируй отчёт (HTML) через кнопку в Coverage панели.

🔹 Зачем это нужно

— Находишь непокрытые edge cases.
— Видишь, что тест не проверяет все ветки if/else.
— Не гадаешь, а точно знаешь, что покрыто.
— Быстро понимаешь, где добавить тесты.

══════ Навигация ══════
Вакансии • Задачи • Собесы

🐸 Библиотека джависта

#Enterprise

🐸 Библиотека джависта

#DevLife

⌛ Как настроить production-ready логирование в Spring Boot

Логи в проде — это не просто System.out.println(). Это структурированные данные, correlation ID, асинхронная запись и ротация. Разбираем настройку от А до Я.

1️⃣ Выбираем стек: Logback + SLF4J

Spring Boot из коробки использует Logback. Добавляем зависимости:

<dependency>
    <groupId>net.logstash.logback</groupId>
    <artifactId>logstash-logback-encoder</artifactId>
    <version>7.4</version>
</dependency>

ИЛИ 

gradleimplementation 'net.logstash.logback:logstash-logback-encoder:7.4'

Это даст JSON-формат логов для удобного парсинга в ELK/Grafana.

2️⃣ Создаём logback-spring.xml

Кладём в src/main/resources:

<configuration>
    <appender name="CONSOLE" class="ch.qos.logback.core.ConsoleAppender">
        <encoder class="net.logstash.logback.encoder.LogstashEncoder">
            <includeContext>false</includeContext>
            <includeMdc>true</includeMdc>
        </encoder>
    </appender>

    <appender name="FILE" class="ch.qos.logback.core.rolling.RollingFileAppender">
        <file>logs/application.log</file>
        <rollingPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedRollingPolicy">
            <fileNamePattern>logs/application-%d{yyyy-MM-dd}.%i.log.gz</fileNamePattern>
            <maxFileSize>100MB</maxFileSize>
            <maxHistory>30</maxHistory>
            <totalSizeCap>10GB</totalSizeCap>
        </rollingPolicy>
        <encoder class="net.logstash.logback.encoder.LogstashEncoder"/>
    </appender>

    <root level="INFO">
        <appender-ref ref="CONSOLE"/>
        <appender-ref ref="FILE"/>
    </root>
</configuration>

Логи ротируются по размеру и времени, старые архивируются в gzip.

3️⃣ Добавляем Correlation ID

Создаём фильтр для трекинга запросов:

@Component
public class CorrelationIdFilter extends OncePerRequestFilter {
    @Override
    protected void doFilterInternal(HttpServletRequest request, 
                                    HttpServletResponse response, 
                                    FilterChain chain) throws ServletException, IOException {
        String correlationId = request.getHeader("X-Correlation-ID");
        if (correlationId == null) {
            correlationId = UUID.randomUUID().toString();
        }
        MDC.put("correlationId", correlationId);
        response.setHeader("X-Correlation-ID", correlationId);
        try {
            chain.doFilter(request, response);
        } finally {
            MDC.clear();
        }
    }
}

Теперь каждый лог привязан к конкретному запросу. В JSON-логе будет поле correlationId.

4️⃣ Настраиваем уровни логирования в application.yml

logging:
  level:
    root: INFO
    com.yourcompany: DEBUG
    org.springframework.web: WARN
    org.hibernate.SQL: DEBUG
  pattern:
    console: "%d{yyyy-MM-dd HH:mm:ss} - %msg%n"

Для прода root: INFO, для дебага поднимаем до DEBUG только нужные пакеты.

5️⃣ Асинхронная запись логов

Добавляем в logback-spring.xml:

<appender name="ASYNC_FILE" class="ch.qos.logback.classic.AsyncAppender">
    <appender-ref ref="FILE"/>
    <queueSize>512</queueSize>
    <discardingThreshold>0</discardingThreshold>
</appender>

<root level="INFO">
    <appender-ref ref="ASYNC_FILE"/>
</root>

Логи пишутся в отдельном потоке и не блокируют бизнес-логику.

6️⃣ Интеграция с мониторингом

Для отправки в Logstash/Fluentd добавляем TCP-аппендер:

<appender name="LOGSTASH" class="net.logstash.logback.appender.LogstashTcpSocketAppender">
    <destination>logstash.example.com:5000</destination>
    <encoder class="net.logstash.logback.encoder.LogstashEncoder"/>
</appender>

══════ Навигация ══════
Вакансии • Задачи • Собесы

🐸 Библиотека джависта

#Enterprise

🐸 Библиотека джависта

#DevLife

❓ Что такое JIT-компилятор?

JIT (Just-In-Time) компилятор — это компонент JVM, который компилирует байт-код в машинный код непосредственно во время выполнения программы, а не до старта приложения. Его задача — улучшить производительность, оптимизируя код, исходя из реальных условий работы программы.

JIT компилирует только те части кода, которые реально исполняются, и может применять различные оптимизации для ускорения работы приложения. Это позволяет сочетать гибкость интерпретируемого байт-кода и производительность нативного кода.

🐸 Библиотека собеса по Java

#core