Java 25: апгрейд, который экономит до 30% RAM (без правок кода)

В JDK 25 добавили одну из самых заметных оптимизаций за долгое время: Compact Object Headers (JEP 519).

Что меняется:

- размер заголовка объекта уменьшается примерно с ~12 байт до 8 байт
- меньше памяти на объект -> меньше heap
- меньше heap -> меньше давление на GC
- меньше GC -> сервис быстрее + облако дешевле

Где профит максимальный:
Spring Boot, микросервисы, DTO, records, кэши, в общем всё, где много мелких объектов.

Включается одной опцией:
-XX:+UseCompactObjectHeaders

По отзывам из реальных систем:
снижение heap на 15–30% встречается довольно часто.

Просто протестируй на своих сервисах и забирай “бесплатную” экономию.

👉 Java Portal

Java: Records не ограничены ролью просто контейнера данных, в них можно добавлять кастомные конструкторы и методы для валидации.

✅ В records можно иметь конструкторы, статические методы и методы экземпляра:

public record Email(String address) {

    // Конструктор с валидацией
    public Email {
        if (address == null || !address.matches("^[\\w-.]+@([\\w-]+\\.)+[\\w-]{2,4}$")) {
            throw new IllegalArgumentException("Некорректный email-адрес: " + address);
        }
    }

    // Метод экземпляра
    public String domain() {
        return address.substring(address.indexOf('@') + 1);
    }

    // Статический метод
    public static Email from(String raw) {
        return new Email(raw.trim().toLowerCase());
    }
}

👉 Java Portal

В Spring Boot можно включить асинхронное логирование, настроив Logback (logback-spring.xml).

✅Лог-сообщения отправляются в очередь и обрабатываются отдельным фоновым потоком.

✅Это снижает узкие места на I/O (ввод-вывод).

Положи конфиг Logback в папку resources:

src/main/resources/logback-spring.xml

Пример:

<configuration>

    <!-- Консольный appender, обернутый в async -->
    <appender name="ASYNC_CONSOLE" class="ch.qos.logback.classic.AsyncAppender">
        <appender-ref ref="CONSOLE" />
        <queueSize>5000</queueSize>
        <discardingThreshold>0</discardingThreshold>
        <includeCallerData>false</includeCallerData>
    </appender>

    <appender name="CONSOLE" class="ch.qos.logback.core.ConsoleAppender">
        <encoder>
            <pattern>%d{yyyy-MM-dd HH:mm:ss} %-5level [%thread] %logger - %msg%n</pattern>
        </encoder>
    </appender>

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

</configuration>

👉 Java Portal

Развенчиваем распространенный миф про Java Garbage Collector

Миф: мне НЕ нужно заниматься управлением памятью в Java, потому что GC все делает за меня

Garbage Collector (GC) действительно очищает неиспользуемые объекты, на которые больше нет активных ссылок. Благодаря этому в Java не нужно вручную освобождать память, как в C++.

Несколько предпосылок, из которых обычно рождается этот тезис:

- В языках с ручным управлением памятью (C, C++) утечки очевидны: если забыл вызвать free(), память потеряна навсегда.
- В Java GC работает автоматически, поэтому кажется, что он сам решает все проблемы.
- «Ну раз есть GC, значит о памяти можно больше не думать» - типичная ошибка.

GC удаляет только те объекты, на которые больше нет активных ссылок. Если объект остается доступным, но фактически уже не используется, он будет занимать память до завершения приложения.

* Несколько случаев утечек памяти

[1] Статические коллекции (заполняем, но не очищаем)

Если создать static List и постоянно добавлять в него объекты, GC их никогда не освободит, потому что статические поля живут в течение всего времени работы приложения.

public class MemoryLeak {
    private static final List<byte[]> cache = new ArrayList<>();
    public static void main(String[] args) {
        while (true) {
            cache.add(new byte[10 * 1024 * 1024]);
            System.out.println("Added 10MB to the cache. Used memory: " +
                    (Runtime.getRuntime().totalMemory() - Runtime.getRuntime().freeMemory()) / (1024 * 1024) + "MB");
        }
    }
}

Через пару минут - OutOfMemoryError.

[2] Переменные потока (ThreadLocal)

Объекты, сохраненные в ThreadLocal, привязаны к потоку, а в пуле потоков могут жить дольше, чем нужно.

public class ThreadLocalLeak {

    private static final ThreadLocal<byte[]> threadLocalData = new ThreadLocal<>();
    public static void main(String[] args) {

        ExecutorService executor = Executors.newFixedThreadPool(5);
        for (int i = 0; i < 10; i++) {

            executor.execute(() -> {
                threadLocalData.set(new byte[10 * 1024 * 1024]); // 10MB per thread
                System.out.println("Memory occupied by the thread!");
            });
        }
        executor.shutdown();

    }
}

Поток завершится, но память останется занятой, потому что ThreadLocal не очищается автоматически.

[3] Внутренние классы и «утекшие» ссылки

Если анонимный класс или lambda-ссылка захватывает внешний объект, это может мешать GC освободить его.

public class InnerClassLeak {

    private String data = "Very important data";
    public void createAnonymousClass() {

        Runnable task = new Runnable() {
            
@Override

            public void run() {
                System.out.println("Using: " + data);
            }
        };
        new Thread(task).start();
    }
}

task держит ссылку на data, и даже если InnerClassLeak больше не используется, GC не сможет очистить объект.

Миф развенчан. GC не всесилен, и даже с ним придется учиться правильно работать с памятью в Java.

👉 Java Portal

Spring Boot: можно использовать spring.jpa.hibernate.ddl-auto=validate, чтобы проверять случайные изменения схемы в продакшене.

✅Если что-то не совпадает, приложение не запустится
✅Это можно комбинировать с инструментами миграций, например Flyway или Liquibase

👉 Java Portal

Твоя база данных не медленная.
Медленный у тебя цикл обратной связи.

Один сеньор написал практический гайд, где показано, как разработчику на Java анализировать производительность PostgreSQL из Quarkus-приложения с помощью pg_stat_statements, hypopg и PostgreSQL MCP-сервера через IBM Bob.

👉 Java Portal

Совет: держите код рядом. Следите, чтобы вычисление было как можно ближе к месту, где используется это значение. Это улучшает читаемость и удобство рефакторинга, снижает вероятность багов и делает код более устойчивым к ошибкам.

👉 Java Portal

Совет по Java: используйте Collectors.groupingBy(...), чтобы группировать результаты стрима по классификатору.

👉 Java Portal

Пессимистическая vs оптимистическая блокировка

Частый вопрос на собеседованиях по backend.

[Пессимистическая блокировка]: -

- Запись недоступна другим потокам, пока текущий поток не закончит с ней работу.
- Даже чтение данных другими потоками невозможно, пока блокировка не снята.
- Пример: EntityManager.lock(entity, LockModeType.PESSIMISTIC_WRITE) в JPA.
- Минусы: снижает производительность при высоком уровне конкуренции.
- Когда использовать: когда критически важна точность данных.

[Оптимистическая блокировка]: -

- Не блокирует данные при чтении, но при сохранении проверяет версию записи.
- Пример: аннотация @Version в JPA (колонка для хранения версии).
- Если версия изменилась другим потоком, выбрасывается OptimisticLockException.
- Минусы: нужно разруливать конфликты.
- Когда использовать: когда чтений много, а вероятность конфликтов низкая.

Какой подход ты чаще используешь в своих проектах?

👉 Java Portal

Задумывался, как работают ActiveMQ и RabbitMQ?

В основе у них producer/consumer паттерн.

Как его реализовать?

Это базовая схема обмена данными между несколькими потоками. Поток-продюсер отправляет объекты на условную обработку, а потоки-консьюмеры асинхронно их получают и обрабатывают.

Общий вид решения такой:

продюсер кладет объекты в специальную коллекцию, буфер. Когда консьюмер освобождается, он запрашивает из буфера один объект. Если буфер пустой, консьюмер блокируется и ждёт; если буфер переполнен, ждёт продюсер.

Реализовать этот паттерн можно по-разному.

Самый правильный способ для продакшена: брать готовую реализацию из стандартной библиотеки, например BlockingQueue.

На собеседованиях обычно просят написать реализацию с нуля. На картинке показан один из вариантов.

Модификатор synchronized гарантирует, что в один момент времени выполняется только один из методов и только одним потоком. Этого достаточно для корректной работы, пока буфер не пуст и не переполнен. Когда буфер пустой или полный, управление явно передаётся продюсеру или консьюмеру соответственно через notify() и wait().

👉 Java Portal