Сборщик мусора не защищает Java от утечек памяти.

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

Типичные причины:

• Растущая статическая коллекция.
• Кэш без удаления устаревших записей.
• Неочищенный ThreadLocal в долгоживущем потоке.
• Слушатель, который забыли отписать.

«Объект больше не нужен» ≠ «объект недостижим». Поэтому приложение может расходовать всё больше памяти в куче, даже когда сборщик мусора работает исправно.

👉 Java Portal

Память в Java растёт? Сначала выясните, что удерживает объекты

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

Если ненужные объекты остаются в статической Map, безразмерном кэше или коллекции, которую никто не очищает, они продолжают занимать память. Это уже может быть утечкой на уровне приложения.

Увеличение -Xmx даст больше времени, но не устранит причину.
Анализируйте heap dump: какие объекты накапливаются, кто хранит ссылки на них и почему они остаются достижимыми.

Важен не только объём занятой памяти, но и причина, по которой объекты всё ещё живы.

👉 Java Portal

💡 GC есть, а утечки памяти в Java всё равно возможны

Сборщик мусора освобождает недостижимые объекты. Если ненужный объект всё ещё удерживается сильной ссылкой, он остаётся в памяти.

✅ Статические коллекции, кэши и слушатели могут удерживать объекты дольше необходимого.
✅ Коллекция, которая постоянно растёт без удаления элементов, увеличивает потребление памяти.
✅ Отписывайте слушатели, ограничивайте кэши и удаляйте ненужные ссылки. Слабые ссылки используйте там, где это соответствует логике приложения.

Объект больше не нужен — ещё не значит, что GC может его удалить.

👉 Java Portal

🎯

👉 Java Portal

ООП — основа понимания Java

Чтобы уверенно разрабатывать приложения на Java, важно освоить эти темы:

• Классы и объекты — как описывать сущности, их состояние и поведение.
• Инкапсуляция — как скрывать внутренние данные и контролировать работу с ними.
• Наследование и переопределение методов — как расширять поведение классов и когда лучше выбрать композицию.
• Полиморфизм — как работать с разными реализациями через общий интерфейс или базовый класс.
• Абстракция — как выделять важные свойства и скрывать детали реализации с помощью интерфейсов и абстрактных классов.
• Конструкторы и перегрузка — как создавать объекты и предоставлять разные варианты инициализации.
• static и final — чем члены класса отличаются от членов экземпляра и как ограничивать присваивание, переопределение и наследование.
• Вложенные и внутренние классы — как объявлять классы внутри других классов и зачем это нужно.

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

👉 Java Portal

Spring AI: AI-приложения на привычном Java-стеке

Интеграция с LLM быстро обрастает деталями: HTTP-запросы, форматы ответов, настройки провайдеров, обработка ошибок. Spring AI предлагает общие абстракции, чтобы эту работу было проще встроить в Spring-приложение.

Что стоит знать:

• ChatModel — общий интерфейс для взаимодействия с чат-моделями. Позволяет уменьшить зависимость бизнес-кода от API конкретного провайдера.

• ChatClient — удобный API для формирования запросов к модели и обработки ответов.

• PromptTemplate — шаблоны промптов с переменными. Инструкции можно переиспользовать и поддерживать отдельно от бизнес-логики.

• Структурированный вывод — преобразование ответов модели в Java-объекты. При этом проверка данных и бизнес-правил остаётся задачей приложения.

• Работа с разными провайдерами — интеграции с OpenAI, Anthropic, Google, Azure OpenAI и локальными моделями через Ollama. Общий API упрощает переключение, но возможности и настройки моделей всё равно различаются.

Spring AI можно использовать для ассистентов, анализа документов, RAG и вызова инструментов. AI-функциональность при этом оформляется как обычный сервис приложения: со своими зависимостями, тестами и обработкой ошибок.

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

👉 Java Portal

💡 Java: кэшируйте результаты дорогих вычислений

Если результат зависит от входных данных, сохраните его в Map, используя эти данные как ключ.

✅ Для общего кэша нескольких потоков подойдёт ConcurrentHashMap.
✅ computeIfAbsent() вычислит и сохранит значение, если его ещё нет. Последующие вызовы используют сохранённый результат.

var result = cache.computeIfAbsent(key, this::calculate);

Учтите: если вычисление вернуло null или выбросило исключение, результат не сохранится. А для долгоживущего кэша нужны ограничения размера и правила удаления устаревших данных.

👉 Java Portal

💡 Java 21: виртуальные потоки для задач с ожиданием I/O

✅ JVM управляет множеством лёгких потоков без отдельного потока ОС для каждого.
✅ Можно сохранить привычный блокирующий код и обрабатывать много задач одновременно.
✅ Подходят для многочисленных HTTP-запросов и обращений к БД, где значительная часть времени уходит на ожидание.

Вычисления на CPU сами по себе быстрее не станут. И не забывайте ограничивать параллельные обращения: виртуальные потоки не увеличивают пропускную способность базы или внешнего API.

👉 Java Portal

Практические уроки для Backend, Data Engineering и DevOps

Площадка с пошаговыми туториалами и облачными окружениями. Изучаем теорию и сразу выполняем команды без настройки локальной среды. В каталоге PostgreSQL, Redis, Docker, Kubernetes, Airflow, Spark и ClickHouse.

https://prepare.sh/

👉 Java Portal

💡 Нужно найти все файлы в папке и её подпапках? Используйте Files.walk().

✅ Возвращает Stream<Path> для рекурсивного обхода дерева каталогов.
✅ Фильтруйте файлы по расширению через path.toString().endsWith(".java") или используйте любой другой предикат.
✅ Всегда закрывайте поток: try-with-resources автоматически освобождает ресурсы обхода.

👉 Java Portal

Spring Boot API отвечает тайм-аутами, а PostgreSQL выглядит здоровым?

CPU в норме, медленных запросов нет. Причина может быть в исчерпании пула соединений HikariCP. Когда все соединения заняты, новые запросы ждут освобождения одного из них. Если время ожидания превышает connectionTimeout, получение соединения завершается ошибкой.

Особенно коварны долгие транзакции: приложение может удерживать соединение, пока ждёт внешний API, хотя сама база в этот момент почти не работает.

В статье разбираются:

• Причины исчерпания пула.
• Влияние долгих транзакций.
• Диагностика по метрикам HikariCP.
• Практические способы устранения проблемы.

Читать статью

👉 Java Portal

💡 Spring Boot 4: EnvironmentPostProcessor переехал в новый пакет

✅ Новый путь: org.springframework.boot.EnvironmentPostProcessor.
✅ Старый org.springframework.boot.env.EnvironmentPostProcessor пока работает, но помечен как устаревший (deprecated).
✅ Обновите импорт в коде и ключ регистрации в META-INF/spring.factories.

👉 Java Portal

Java Records, Lombok и POJO: в чём разница?

Все три подхода помогают описывать данные, но отвечают на разные потребности: краткость, генерация шаблонного кода и контроль над поведением класса.

• Record — компактный носитель данных. Records стали стандартной возможностью языка в Java 16:

public record User(
    Long id,
    String name,
    String email
) {}

Компилятор создаёт конструктор для всех компонентов, методы доступа id(), name(), email(), а также equals(), hashCode() и toString(). Подходит для DTO, моделей запросов и ответов API, данных событий.

Неизменяемость поверхностная: поля компонентов — final, но содержимое переданного списка или другого изменяемого объекта всё ещё может меняться.

• Lombok — меньше шаблонного кода. Аннотации позволяют генерировать методы и конструкторы при компиляции:

@Getter
@Setter
@NoArgsConstructor
@AllArgsConstructor
public class User {
    private Long id;
    private String name;
    private String email;
}

Lombok умеет создавать getters/setters, конструкторы, equals(), hashCode(), toString() и builder через @Builder.

Удобен для существующих проектов и классов с большим количеством повторяющегося кода. При этом добавляет зависимость при сборке и требует понимания того, что именно генерируется.

С JPA-сущностями аннотации стоит выбирать аккуратно: автоматически созданные equals(), hashCode() и toString() могут некорректно работать со связями и ленивой загрузкой.

• POJO — обычный Java-объект. Класс без обязательной привязки к специальному фреймворку или модели программирования. Вы сами определяете конструкторы, валидацию, изменяемость, бизнес-логику и правила сравнения. Подходит для доменных моделей и классов с нестандартным поведением.

Это не три взаимоисключающих варианта: record — возможность языка, Lombok — инструмент генерации кода, POJO — характеристика класса. Класс с аннотациями Lombok вполне может оставаться POJO. Выбирайте подход по назначению класса, а не только по количеству сэкономленных строк.

👉 Java Portal

Java Records — больше, чем сокращённая запись класса

record User(String name, String email) {}

Вы получаете:

→ Поля компонентов с модификатором final.
→ Автоматические equals(), hashCode() и toString().
→ Явный сигнал: «этот тип хранит данные».

Используйте records для DTO — меньше шаблонного кода, проще ревью.

👉 Java Portal

💡 Java: используйте Path и Files для работы с файлами

✅ Path.of(...) создаёт путь с учётом файловой системы текущей ОС.
✅ Files.readString(), writeString() и readAllLines() позволяют читать и записывать текст одной строкой.
✅ Для простых операций нужно меньше шаблонного кода, чем с FileReader и BufferedReader.

👉 Java Portal

💡 Ленивая инициализация в Spring Boot

Настройка spring.main.lazy-initialization=true откладывает создание большинства бинов до момента, когда они понадобятся.

✅ Вместе с созданием бина откладывается и вызов @PostConstruct.
✅ Приложение запускается быстрее, но прогрев кэша или проверки схемы БД могут не выполниться, если соответствующий бин никто не запросит.
✅ Ошибки инициализации могут проявиться уже при первом запросе.

👉 Java Portal

Что происходит между GET /users/123 и ответом API?

Несколько сотен миллисекунд могут включать установку соединения, балансировку нагрузки, проверку авторизации, обращение к кэшу и базе данных. Код контроллера занимает лишь часть этого времени.

В статье разобран путь запроса в приложении на Spring Boot:

• DNS и TLS.
• Балансировка нагрузки.
• Spring Security и JWT.
• Попадание и промах кэша Redis.
• Ожидание соединения из пула.
• Запросы к PostgreSQL.
• Взаимодействие с Kafka.
• Источники задержек на каждом этапе.

Не каждый запрос проходит все эти шаги: соединение может переиспользоваться, кэш — исключить обращение к БД, а Kafka участвует только там, где это предусмотрено логикой приложения.

Читать на Medium

👉 Java Portal

💡 @ConditionalOnClass: конфигурация включается, если нужный класс есть в classpath

✅ Используется в автоконфигурациях Spring Boot, например для Kafka и Redis.
✅ Если класса нет, условная конфигурация пропускается.
✅ В паре с @ConditionalOnMissingBean позволяет предоставить бин по умолчанию, который приложение может заменить собственным.

👉 Java Portal

Утечка памяти, фрагментация и нагрузка на GC: в чём разница?

Приложение потребляет много памяти — это ещё не означает утечку. Причины могут быть разными.

Memory Leak — ненужные объекты остаются достижимыми. Программа больше не использует их, но продолжает хранить ссылки, поэтому сборщик мусора не может освободить память.

Типичные причины: кэш без ограничений, растущие статические коллекции, неудалённые слушатели и неправильная работа с ThreadLocal. Один из признаков — устойчивый рост занятой памяти даже после сборок мусора.

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

В Java влияние фрагментации зависит от сборщика мусора и области памяти: heap, native или off-heap. Многие сборщики перемещают объекты и уплотняют память, но это не устраняет все возможные случаи.

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

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

При диагностике смотрите на разные сигналы:

• Утечка: какие объекты остаются живыми и что удерживает ссылки на них.
• Фрагментация: в какой области памяти не удаётся выделить нужный блок.
• GC Pressure: скорость аллокаций, частоту сборок, паузы и затраты CPU.

Увеличение -Xmx иногда помогает, но при утечке лишь откладывает проблему. Сначала выясните, почему память растёт и на что тратится время GC.

👉 Java Portal

💡 Spring Boot + Kafka: отправка и получение событий с минимумом кода

✅ Внедрите KafkaTemplate, чтобы отправлять сообщения в топик.
✅ Добавьте @KafkaListener к методу, чтобы обрабатывать входящие сообщения.
✅ Автоконфигурация Spring Boot настроит компоненты Kafka по параметрам spring.kafka.*.

👉 Java Portal