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

У 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