🔎 Java-приложение тормозит. Кто виноват: код, GC или Python?

Когда сервис начинает активно есть память или отвечать медленнее обычного, не всегда хочется сразу раскручивать полноценный профайлер. Стоит сначала заглянуть внутрь JVM и понять, где вообще искать проблему.

Для этого команда Axiom JDK сделала Profiling Tools — плагин для OpenIDE.

🖥 Прямо внутри среды разработки можно подключиться к локальному Java-процессу и посмотреть:

— CPU JVM и общую загрузку процессора;
— heap, non-heap и GC Load;
— потоки, их состояния, CPU Load и выделенную память;
— стектрейсы, а для процессов, запущенных из OpenIDE, перейти к нужной строке кода.

Как заметить подозрительный рост heap и проверить работу GC, найти внешний процесс, который отъедает CPU у Java, и понять, действительно ли тормозит сервис или ему просто почти не прилетают запросы?

🔷 Какие метрики смотреть в каждом случае и как по ним сузить поиск проблемы — разобрали на Хабре.

❗️ Jackson пропустил Comparable: патчи уже вышли, проверяем конфиг

В jackson-databind раскрыли CVE-2026-83557 с оценкой CVSS 5,6. Причина: java.lang.Comparable не попал в список потенциально опасных типов DefaultBaseTypeLimitingValidator.

Уязвимость проявляется при сочетании трёх условий: @JsonTypeInfo, базовый тип Comparable и отсутствие строгого PolymorphicTypeValidator.

В таком случае входные данные могут заставить Jackson создать объект неожиданного класса. В proof of concept исследователи получили java.io.File с произвольным путём. Само по себе это не RCE: последствия зависят от того, как приложение использует объект дальше.

Патчи уже выпустили: Для Jackson 2 — версии 2.18.10, 2.21.6 и 2.22.2; для Jackson 3 — 3.1.6 и 3.2.2.

Сейчас стоит:

1. Обновить jackson-databind до исправленной версии.
2. Найти места, где @JsonTypeInfo используется вместе с Comparable.
3. Проверить настройки PolymorphicTypeValidator.

🔷 Источник: GitHub Security Advisory — CVE-2026-83557

🎊 Java 27 вышла: G1 везде, объекты компактнее, TLS смотрит в постквантовое будущее

Внутри — девять JEP

G1 теперь выбирается по умолчанию даже в окружениях с одним CPU или небольшим объёмом памяти. Compact Object Headers сжимают заголовок объекта с 96 до 64 бит на 64-битном HotSpot; в SPECjbb2015 это дало до 22% экономии heap. TLS 1.3 получил гибридный постквантовый обмен ключами, а JFR теперь редактирует типичные секреты ещё до записи диагностических данных.

Не только рантайм

Lazy Constants откладывают вычисление до первого обращения, выполняют его не больше одного раза и безопасно работают при конкурентном доступе. Structured Concurrency вышла в седьмое preview, а примитивные типы в pattern matching, instanceof и switch — в пятое.

Но релиз не из серии «поставил и забыл». В небольших окружениях стоит проверить переход с Serial GC на G1; Compact Object Headers при проблемах можно отключить флагом -XX:-UseCompactObjectHeaders; а вручную ограниченный список TLS named groups не даст включиться гибридному обмену. Перед обновлением стоит проверить контейнерные лимиты, JVM-флаги и TLS-настройки. 

И главное: Java 27 — не LTS. Четыре JEP остаются в preview, а Vector API — в incubator. Поэтому релиз скорее подходит для проверки совместимости и новых API, чем на роль новой опорной production-ветки. 

🔷 Если хочется пройтись по каждому JEP с примерами, флагами и тем, что проверить при обновлении, у нас вышел подробный разбор Java 27 на Хабре. А ранний обзор девяти JEP — найдете Блоге Axiom JDK.

🐘 Команда Gradle выпустила 9.8 RC2

Главное для Java-команд — заявленная поддержка Java 27. В релиз-кандидат также вошли повторное использование настроек Maven mirror и связанные с исходниками позиции ошибок в выводе сборки.

RC — это не сигнал немедленно обновлять рабочий wrapper. Это приглашение проверить новый стек до финального релиза. Особенно внимательно стоит прогнать плагины, convention plugins, configuration cache, корпоративные зеркала и сборки, где toolchain отличается от JVM, на которой работает сам Gradle.

Практический сценарий простой: отдельная ветка, обновление wrapper, полный CI и сравнение времени и воспроизводимости сборки. Если тесты прошли, команда заранее снимает риск несовместимости с Java 27. Если нет — получает время сообщить о проблеме до GA, не затрагивая production-процесс.

🔷 Релиз Gradle 9.8.0 RC2

🫨 Java запрещает менять final? Разбираем JEP 500

Поле объявлено final, но через reflection его всё ещё можно изменить после создания объекта. Старый Java-компромисс, который годами помогал фреймворкам, теперь начинает мешать самой JVM.

В JDK 26 OpenJDK сделал первый шаг к тому, чтобы final действительно означал «неизменяемый»: пока такие мутации получают warning, а в будущем их планируют запрещать по умолчанию.

В новом видео Максим Лебедев, Developer Advocate Axiom JDK, разбирает:
— что меняет JEP 500 Prepare to Make Final Mean Final в JDK 26;
— кого могут затронуть изменения;
— как найти final-field mutation в своём проекте;
— что проверить уже сейчас, чтобы будущие обновления JDK не принесли сюрпризов.

🌐 YouTube | 🌍 VK Видео

А если вам удобнее читать — текстовая версия уже ждет вас на Хабр!

♻️ G1 за восемь версий JDK: что успели переделать

G1, или Garbage-First, — сборщик мусора в JVM, который делит heap на регионы и старается удерживать паузы под контролем за счёт поэтапной очистки памяти. Для многих Java-приложений это уже привычный GC по умолчанию.

Но за знакомым названием скрывается сборщик, который от JDK 17 до 25 успели заметно перекроить.

Дмитрий Соломенников разобрал на Хабр, как менялся G1 и какие реальные проблемы эксплуатации стояли за этими изменениями. Как:

— в JDK 17 улучшили работу с humongous objects, а в одном из сценариев Full GC стал проходить на 10–12% быстрее;
— в JDK 18 переработали remembered set и сократили потребление памяти почти на 25%;
— в JDK 20 переход на tri-color marking высвободил около 1,5% кучи;
— в JDK 21 G1 научился перемещать humongous objects во время Full GC, чтобы бороться с фрагментацией;
— в JDK 24–25 доработали настройку эвристик и сценарии, которые могли неожиданно растягивать паузы.

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

🔷 История G1 от JDK 17 до 25 — на Хабре

😀 Axiom JDK на Joker 2026: увидимся в Петербурге

14–15 октября традиционно поучаствуем в самой большой Java-конференции со стендом: заходите познакомиться, проверить знания в квизах, побороться за призы и обсудить технологии с командой Axiom JDK.

Что в программе?

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

14 октября — Современные практики: JVM и JDK, производительность и архитектура, Spring и Kotlin, базы данных и инфраструктура, инструменты разработчика и агенты.

15 октября — «Разработка будущего»: Инженеры, менеджеры, философы и ученые — о технологиях, работе, организациях и перераспределении ответственности.
До встречи в октябре!

🔷 Подробнее о Joker 2026

🍃 Spring после EOL: кто будет закрывать новые уязвимости?

Spring вместе с транзитивными зависимостями может составлять до 90% современного приложения.

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

20 октября будем разбираться, что на практике происходит после EOL, почему одного мониторинга CVE мало и как выстроить управляемую работу с уязвимостями, зависимостями и исправлениями.

Отдельно покажем, где в этой схеме помогает Axiom Spring и как поддерживать старые ветки без авральной major-миграции.

🎤 Спикеры:
• Дмитрий Карасовский — руководитель отдела по информационной безопасности Axiom JDK
• Алексей Захаров — директор по технологическому консалтингу Axiom JDK
• Максим Лебедев — Developer Advocate Axiom JDK
• Илья Сазонов — директор по продуктам направлений Axiom Spring и OpenIDE

🔷 Зарегистрироваться

🛠 Spring перестраивает расписание обновлений

Раньше патчи разных Spring-проектов выходили по очереди, и весь цикл растягивался примерно на две недели. Теперь вместо него появится Patch Thursday: плановые обновления и CVE-фиксы будут выпускать вместе, в четверг после третьего понедельника месяца.

❓ Почему так?

Поток security-репортов резко вырос:
• Раньше команда получала 6-7 сообщений в месяц, с марта — почти 80;
• Spring сам начал прогонять проекты через AI-модели: только в апреле они выдали 370 отчётов.

Хоть и не каждый отчёт становится CVE, их все равно нужно проверять. В старом графике обрабатывать такой поток и выпускать исправления становилось всё сложнее.

🗓 Первый полноценный Patch Thursday запланирован на 22 октября.

Большой плюс для команд: обновления Spring-стека теперь проще собирать в одно плановое окно. Проверили, что приехало, прогнали совместимость и тесты, обновились.

Если сервисы остаются на Spring Framework 5.3 или Spring Boot 2.7, Axiom Spring позволяет получать обновления безопасности и критические исправления без срочной major-миграции.

🔷 Подробности

🖥 JDK 27 меняет сразу два runtime-дефолта, которые могут повлиять на поведение сервиса даже без правок в коде

1. Compact Object Headers теперь включены по умолчанию. На типичной 64-битной HotSpot-конфигурации заголовок объекта уменьшается с 12 до 8 байт.

2. G1 теперь GC по умолчанию вообще везде, в том числе в небольших контейнерах и однопроцессорных средах, где раньше JVM могла выбрать Serial GC.

С компактными заголовками выигрыш особенно заметен там, где в heap много мелких объектов: в одном из замеров SPECjbb2015 расход памяти снизился на 22%, а CPU — на 8%. С G1 нюанс другой: на небольших конфигурациях могут сократиться паузы, нагрузка на CPU и потребление памяти.

Поэтому переход на JDK 27 лучше проверять не одним общим бенчмарком. Снимите базовые метрики на текущей версии, а затем отдельно сравните новые дефолты: Compact Object Headers можно временно отключить, а GC — выбрать явно. Так будет понятно, что именно изменило профиль приложения.

🔷 Источник

🔒 В Spring LDAP обнаружили CVE-2026-41720, из-за которой приложение при определённых условиях могло принять пустой пароль за успешную аутентификацию.

Но это не значит, что без пароля можно было войти в любой LDAP. Для эксплуатации требовалось совпадение ряда условий: 

• уязвимая версия Spring LDAP;
• атакующий знал существующее имя пользователя;
• пустой пароль или null;
• LDAP-сервер разрешил unauthenticated bind;
• приложение приняло ответ и создало пользовательскую сессию.

Фикс уже выпустили:
• Spring LDAP 4.0.0–4.0.3 → 4.0.4;
• Spring LDAP 3.3.0–3.3.7 → 3.3.8.

❓ Это все понятно. А что делать?

В первую очередь — обновиться.

Затем проверить саму конфигурацию: нужен ли вообще unauthenticated bind и отклоняет ли приложение пустые пароли до обращения к LDAP.

Если нельзя исключить, что уязвимость уже эксплуатировали, тогда начинается уже не патчинг, а расследование: стоит проверить журналы аутентификации и действий пользователей, завершить подозрительные сессии и при необходимости временно ограничить LDAP-вход.

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

🔷 Подробный разбор

🏎 Постквантовая криптография в JDK становится быстрее

В JDK уже есть ML-KEM и ML-DSA, но их базовая Java-реализация рассчитана прежде всего на переносимость. В JDK 28 HotSpot начинает точечно подменять самые тяжёлые операции оптимизированным машинным кодом под конкретную архитектуру.

📈 Существенный ли прирост? 

В опубликованных тестах ускорение местами доходит до 218% — то есть операция выполняется примерно в 3,18 раза быстрее Java-only версии. В этих алгоритмах много повторяющихся вычислений над полиномами, которые хорошо ложатся на векторные инструкции и аппаратное ускорение. 

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

Но магии нет: HotSpot использует такую оптимизацию только там, где её поддерживает платформа. Поэтому финальные цифры всё равно стоит замерять на своём железе.

🔷 Подробности

📄 Как проверить 7 000 000 строк JDK?

Мы внедрили Svace и платформу Svacer от ИСП РАН в процесс анализа кодовой базы Axiom JDK.

Задача была не просто добавить ещё один SAST. Кодовая база JDK огромная, а требования к безопасной разработке и сертификации растут. Поэтому нужен инструмент, который умеет глубоко разбирать межпроцедурные связи и нормально работает на таком масштабе.

📊 Результат 

Svace прогнал около 7 млн строк кода, а команда обнаружила и исправила примерно 1,2 тыс. дефектов.

При этом одним анализатором дело не ограничилось. Svace стал основным инструментом глубокого анализа, а другие SAST и open-source-линтеры дополняют его: разные движки находят разные классы проблем.

Отдельная история — разбор тысяч предупреждений. Для этого используем Svacer и ML-классификацию: сейчас один разработчик в среднем проверяет около 50 срабатываний в день.

🔷 О том, как статический анализ стал частью процесса разработки JDK, рассказали в Блоге.