Телеграм канал «Чашечка Java»

Почему копирование HashMap стало быстрее в JDK 27

При вызове putAll() карта раньше читала элементы источника через интерфейс Map: создавала итератор, получала ключи и значения, снова вычисляла хеши. Несколько реализаций Map в одном месте вызова усложняли оптимизацию для JIT.

В JDK 27 добавили отдельный путь для источника, который является именно HashMap, и для неизменяемой обёртки над такой картой. Реализация обходит внутреннюю таблицу напрямую и использует хеш, уже сохранённый в узле. Это касается и конструктора HashMap(Map).

В разборе оптимизаций JDK 27 приведены JMH-замеры на AWS Graviton: в выбранных сценариях время операции сократилось на 61–86%. Это результаты конкретных микробенчмарков.

Для других типов исходной Map остаётся общий путь. При обновлении сервиса полезно проверить копирование карт на своих данных: размеры коллекций и типы источников влияют на результат.

#java #производительность

Spring Boot и PostgreSQL: дедлок может быть в транзакциях

Приложение получило ошибку 40P01? Это PostgreSQL обнаружил цикл ожидания блокировок, а не доказательство взаимной блокировки Java-потоков.

Достаточно двух строк: транзакция A обновила первую и ждёт вторую, B — наоборот. Такие дедлоки возможны даже без явного LOCK TABLE, потому что обновление строки тоже берёт блокировку.

PostgreSQL прервёт одну транзакцию, чтобы остальные продолжили работу. Какая станет жертвой, заранее полагаться нельзя. В локальной проверке двух сессий получен именно deadlock detected с SQLSTATE 40P01.

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

Дедлоки и порядок блокировок

#spring #java

Развёрнутое пояснение:

1. Создаётся session, реализующий AutoCloseable: при закрытии он выбрасывает исключение с сообщением close.

2. Внутри блока try возникает исключение с сообщением send, поэтому выполнение блока прерывается.

3. Перед переходом к catch конструкция try с ресурсами автоматически закрывает session; закрытие тоже завершается исключением.

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

5. Обработчик catch получает основное исключение: первая строка вывода — send, вторая — 1, поскольку список подавленных исключений содержит один элемент.

Почему это важно

Задача проверяет обработку исключений и управление ресурсами в Java SE. При работе с соединениями и потоками данных ошибка закрытия может сопровождать исходный сбой. Если журналировать только сообщение основного исключения, дополнительная причина останется незаметной; для диагностики нужно учитывать и подавленные исключения.

Showboat и Rodney помогают показать работу ИИ-агента

Саймон Уиллисон собирает демонстрации кода с помощью двух своих инструментов. Showboat выполняет команды и записывает их вывод в документ. Rodney управляет Chrome из командной строки и делает скриншоты интерфейса.

uvx showboat --help

Эту команду автор предлагает дать агенту: в справке есть всё необходимое, чтобы тот создал документ с демонстрацией новой функции.

Уиллисон замечал и обход механизма: агент напрямую правит текст отчёта. Тогда записанный вывод может расходиться с реальным запуском. Содержимое демонстрации тоже требует проверки.

#ии #инструменты

Spring Boot Actuator: свои проверки здоровья и доступ к диагностике

В Spring Boot 4 проверки liveness и readiness включены по умолчанию. Первая показывает, нужен ли приложению перезапуск; вторая определяет, готово ли оно принимать трафик. По умолчанию они учитывают состояние запуска и остановки приложения, а дополнительные проверки можно включить в их группы.

В руководстве по настройке Actuator показано, как создать свой HealthIndicator, объединить проверки в группу и разрешить просмотр деталей только пользователям с ролью admin. Случайный статус в примере служит учебной демонстрацией, а не проверкой для рабочего сервиса.

Детали проверок могут раскрывать чувствительные сведения, например название используемой СУБД. Автор показывает, как скрыть их или ограничить доступ авторизованными пользователями.

#spring #java