Spring Boot 4: проверка null-safety через JSpecify.

Более понятные контракты @Nullable / @NonNull.

Лучший статический анализ в IDE.

#SpringBoot4 #JSpecify

👉 Java Portal

Если достаточно долго работать с базами данных, рано или поздно столкнёшься с проблемами подключений или параллелизма.

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

Эта статья от гениального человека — отличный разбор управления подключениями в Postgres и возможных решений.

Легко свести всё к особенностям Postgres с отдельным процессом на каждое соединение, но похожие проблемы могут возникать и в других базах данных, включая MySQL.

Часто ответ кроется в пуле подключений, но и он добавляет свою сложность, которую тоже важно понимать.

Статье уже 8 лет, но для Postgres она остаётся актуальной и в 2026 году.

Ссылка ниже.

https://brandur.org/postgres-connections

👉 Java Portal

Используйте Collectors.summarizingInt(), чтобы за один проход получить количество элементов, сумму, минимум, максимум и среднее значение.

Так не придётся несколько раз прогонять один и тот же поток данных.

Метод возвращает объект IntSummaryStatistics.

Для long и double есть аналогичные методы: summarizingLong() и summarizingDouble().

#Java #Streams

👉 Java Portal

Чувак декомпилировал Java-игру, чтобы посмотреть, как она устроена внутри.

На выходе получил полностью обфусцированный код: вместо нормальных имён — $$1, $$2 и прочий мусор. Для человека разбирать такое вручную — боль.

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

Такие задачи идеал для ИИ.

👉 Java Portal

Spring Boot 4: теперь лучше использовать RestTestClient вместо TestRestTemplate.

У него более удобный API в стиле RestClient, он работает как с MockMvc, так и с реальным портом приложения.

При необходимости добавьте @AutoConfigureRestTestClient.

#SpringBoot4 #RestTestClient

👉 Java Portal

Как настроить JPA и Hibernate в Spring Petclinic с помощью Hypersistence Optimizer:

https://vladmihalcea.com/spring-petclinic-hypersistence-optimizer/

👉 Java Portal

Типы классов в Java:

1. Concrete Class — обычный класс с полной реализацией методов.
2. Abstract Class — нельзя создать напрямую через new; может содержать абстрактные методы.
3. Final Class — нельзя наследовать.
4. Static Nested Class — статический вложенный класс внутри другого класса.
5. Inner Class — нестатический класс внутри другого класса.
6. Local Class — класс, объявленный внутри метода или другого блока.
7. Anonymous Class — класс без имени, обычно используется для одноразовой реализации.
8. Singleton Class — класс, спроектированный так, чтобы существовал только один его экземпляр.
9. POJO — простой Java-класс без специальных требований к наследованию или фреймворкам.
10. Record Class — компактная форма класса для хранения данных; появилась как предварительная возможность в Java 14.
11. Enum Class — класс, представляющий фиксированный набор констант.

👉 Java Portal

90% PostgreSQL в 2026 году сводится к этим 10 вещам. Всё остальное — в основном споры об расширениях.

1. MVCC + VACUUM
Обновления создают мёртвые строки. Если autovacuum настроен плохо, таблицы и индексы раздуваются, а задержки постепенно растут неделями.

2. Индексы под реальные сценарии запросов
Порядок колонок в составных индексах важен. Нужно понимать частичные и покрывающие индексы, а также почему ORM иногда незаметно приводит к полному сканированию таблицы.

3. Блокировки и DDL
ALTER TABLE может заблокировать запись. Важно понимать режимы блокировок, очереди и безопасные приёмы вроде CREATE INDEX CONCURRENTLY и обновления данных небольшими партиями.

4. Уровни изоляции и аномалии
Read Committed, Repeatable Read, Serializable. Пропавшие или дублирующиеся строки часто нужно разбирать через конкурентные транзакции, а не искать проблему только в коде.

5. Управление соединениями
Слишком много соединений убивает CPU и память. Нужны PgBouncer, адекватные размеры пулов и контроль долгих транзакций в состоянии idle in transaction.

6. WAL, checkpoints и репликация
Объём WAL напрямую влияет на ввод-вывод. Плохие настройки checkpoints вызывают скачки задержек, а отставание реплик ломает чтение с реплик и делает переключение при сбое рискованным.

7. Основы планировщика запросов
EXPLAIN (ANALYZE, BUFFERS) — ваш отладчик. Нужно понимать оценки количества строк, типы JOIN и когда требуется ANALYZE или расширенная статистика.

8. Наблюдаемость, привязанная к реальным сбоям
Следите за p95 задержкой, ожиданием блокировок, временными файлами, попаданиями в кэш, отставанием autovacuum и реплик. Добавьте журнал медленных запросов с нормальными порогами.

9. Резервные копии и проверка восстановления
Базовые бэкапы плюс архивирование WAL — минимум. Главная ошибка — никогда не проверять восстановление и уже во время аварии выяснить, что не хватает ролей, расширений или восстановление занимает слишком долго.

10. Безопасность и права
Минимально необходимые права, отдельные владельцы объектов, никакого superuser у приложения, регулярная смена учётных данных, ограничение сетевого доступа и закрытая на запись схема public в production.

👉 Java Portal

Ещё один отличный плейлист по структурам данных и алгоритмам от pmavrin.

https://youtube.com/playlist?list=PLrS21S1jm43igE57Ye_edwds_iL7ZOAG4&si=4mS5lXn3uxI-V2LM

👉 Java Portal

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

У BitLemonSw как раз вышло новое видео о том, как работает предсказание ветвлений в современных процессорах.

Суть простая. В коде постоянно встречаются ветвления: циклы, if, switch/case, вызовы функций и возвраты.

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

Поэтому процессор заранее угадывает результат ветвления и продолжает загружать инструкции по предполагаемому пути. Если прогноз оказался верным — всё быстро. Если нет — часть работы приходится выбросить и начать заново.

https://youtu.be/UbDIoNY9E0w

👉 Java Portal

Сопоставление с образцом для instanceof: переменную можно объявить прямо в проверке.

Старый подход: сначала instanceof, затем отдельное приведение типа.

Новый подход: if (obj instanceof Dog d) — переменная d сразу готова к использованию.

При этом d существует только там, где условие проверки истинно.

#Java #PatternMatching

👉 Java Portal

Интеграционное тестирование базы данных с помощью Testcontainers

https://vladmihalcea.com/testcontainers-database-integration-testing/

👉 Java Portal

Переименование поля в API изнутри кажется безобидным. Снаружи оно может положить каждый дашборд, который рассчитывал на старое имя.

Любое изменение API попадает в одну из двух категорий, и от этого зависит всё.

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

Безопасные изменения можно выпускать без новой версии: добавлять необязательные поля, новые эндпоинты или просто ускорять работу.

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

Несколько простых правил помогают держать баланс:

— Показывайте версию явно, например /v1/ в URL, как это делают Stripe и GitHub.
— Используйте семантическое версионирование, чтобы смена мажорной версии сразу означала необходимость изменений в клиентском коде.
— Если версия выводится из эксплуатации, говорите об этом прямо в ответе через заголовок Sunset и давайте 6–12 месяцев на миграцию.

Версия API — это обещание о том, что не изменится.

Нарушать его нужно редко и громко. Никогда — молча.

Какую ошибку вы встречали чаще?

👉 Java Portal

Валидатор загрузки связей в JPA

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

Проблема особенно заметна с FetchType.EAGER. Например, @ManyToOne и @OneToOne используют его по умолчанию, из-за чего Hibernate может незаметно генерировать дополнительные запросы и приводить к классической проблеме N+1.

Автор строит собственный валидатор поверх механизмов Hibernate Statistics и Event Listeners. Он позволяет прямо в тестах определить

→ какие связанные сущности были загружены
→ какие пришли через дополнительные SQL-запросы
→ какие были получены через JOIN

Например, можно проверить, что запрос неожиданно загрузил две PostComment отдельными запросами и ещё один Post через JOIN. После замены запроса на JOIN FETCH валидатор подтверждает, что дополнительные SQL-запросы исчезли.

По сути, это способ ловить проблемы со стратегией загрузки и N+1 ещё на уровне тестов, до того как они попадут в продакшен.

https://vladmihalcea.com/jpa-association-fetching-validator/

👉 Java Portal

11 принципов разработки ПО, которые стоило понять гораздо раньше.

1. SOLID — более качественное объектно-ориентированное проектирование
2. DRY — не повторяйся
3. KISS — не усложняй
4. YAGNI — не реализуй то, что пока не нужно
5. SRP — одна ответственность
6. Open/Closed — расширяй, не ломая существующее
7. Dependency Inversion — уменьшай связанность
8. Composition — собирай систему из гибких компонентов
9. Separation of Concerns — разделяй ответственность между частями системы
10. Fail Fast — обнаруживай проблемы как можно раньше
11. Measure First — оптимизируй только то, что действительно имеет значение

👉 Java Portal