Spring АйО
Русскоязычное сообщество Spring-разработчиков. Habr: bit.ly/433IK46 YouTube: bit.ly/4h3Ci0x VK: bit.ly/4hF0OG8 Rutube: bit.ly/4b4UeX6 Яндекс Музыка: bit.ly/3EIizWy Чат для общения: @spring_aio_chat По вопросам сотрудничества: @befayer
Show more📈 Analytical overview of Telegram channel Spring АйО
Channel Spring АйО (@spring_aio) is an active participant. Currently, the community unites 10 943 subscribers, ranking 11 249 in the Technologies & Applications category and 58 243 in the Russia region.
📊 Audience metrics and dynamics
Since its creation on невідомо, the project has demonstrated rapid growth, gathering an audience of 10 943 subscribers.
According to the latest data from 30 October, 2026, the channel demonstrates stable activity. Although there has been a change in the number of participants by 56 over the last 30 days and by -6 over the last 24 hours, overall reach remains high.
- Verification status: Not verified
- Engagement rate (ER): The average audience engagement rate is 52.86%. Within the first 24 hours after publication, content typically collects 22.38% reactions from the total number of subscribers.
- Post reach: On average, each post receives 5 785 views. Within the first day, a publication typically gains 2 449 views.
- Reactions and interaction: The audience actively supports content: the average number of reactions per post is 43.
- Thematic interests: Content is focused on key topics such as айо, хабр, api, jep, amplicode.
📝 Description and content policy
The author describes the resource as a platform for expressing subjective opinions:
“Русскоязычное сообщество Spring-разработчиков.
Habr: bit.ly/433IK46
YouTube: bit.ly/4h3Ci0x
VK: bit.ly/4hF0OG8
Rutube: bit.ly/4b4UeX6
Яндекс Музыка: bit.ly/3EIizWy
Чат для общения: @spring_aio_chat
По вопросам сотрудничества: @befayer”
Thanks to the high frequency of updates (latest data received on 31 October, 2026), the channel maintains relevance and a high level of publication reach. Analytics show that the audience actively interacts with content, making it an important point of influence in the Technologies & Applications category.
SIGILL.
В статье разбираем путь от ~AdapterBlob в крэш-логе до бага в OpenJDK. А ещё показываем, как собрать переносимый multi-arch образ, сохранить ускорение старта и не играть в лотерею с процессорами CI-раннеров.
🔗 Статья на Хабр: https://habr.com/ru/companies/spring_aio/articles/1100616/- кто кого видит в иерархии контекстов и почему parent не знает о своих детях; - почему «видеть бин» не значит «использовать его»; - что на самом деле меняет management.server.port; - как Axelix закрыл уязвимость.⚠️ Полезно всем, кто выносит Actuator на отдельный порт или пишет свои стартеры 🔗 Статья на Хабр: https://habr.com/ru/companies/spring_aio/articles/1099408/
Arena.ofConfined() получит пулы для небольших сегментов. Вместо постоянных вызовов malloc и free JDK сможет повторно использовать блоки памяти.
В микробенчмарках выделение 5–20 байт ускорилось в 6,8–18,9 раза. Код менять не придётся, а прежние гарантии безопасности сохранятся.
В новом переводе разбираемся, как устроена оптимизация и кому она принесёт пользу.
🔗 Статья на Хабр: https://habr.com/ru/companies/spring_aio/articles/1098450/«Преждевременная оптимизация — корень всех зол».Но обычно цитату обрывают слишком рано. Кнут предлагал забыть о небольшом выигрыше в 97% случаев, но не упускать возможности в оставшихся критически важных 3%. Иногда для них не нужны профилировщик и чёрная магия. Достаточно не компилировать регулярку при каждом вызове, не искать постоянно по
List, когда нужен Set, и не создавать новые строки ради сравнения без учёта регистра.
В статье разобрали простые приёмы для строк, коллекций, enum и инициализации объектов. Код становится не только быстрее, но и понятнее. Редкое и приятное совпадение.
🔗 Статья на Хабр: https://habr.com/ru/companies/spring_aio/articles/1097566/Главная новинка – комментарии для AI: можно выделить фрагмент кода или ответа агента, написать, что нужно изменить, и собрать замечания в одну пачку либо сразу отправить правку в выбранный или новый чат.В коротком видео показываем, как это работает прямо в IDE. Скачивайте свежий релиз OpenIDE Pro и два месяца пользуйтесь всеми её возможностями бесплатно и без ограничений. https://openide.ru/download
pom.xml может быть недостаточно.
На JDK 25 могут перестать запускаться процессоры аннотаций, сломаться старые параметры JVM и измениться разбор дат. Иногда приложение упадёт сразу. Иногда проблема всплывёт позже, что даже веселее.
В новом переводе собрали реальные несовместимости и проверки, которые стоит выполнить до переезда.
🔗 Статья на Хабр: https://habr.com/ru/companies/spring_aio/articles/1096850/@SpringBootApplication: создание собственных экосистем поверх Spring Boot СМОТРЕТЬ НА YOUTUBE
📈 Рустам Курамшин — Мониторь это. Как писать свои метрики для Micrometer и Grafana СМОТРЕТЬ НА YOUTUBE
🗄 Артемий Дегтярев — Spring Data JDBC: где мы находимся сейчас СМОТРЕТЬ НА YOUTUBE
👀 Пять докладов - от безопасной работы с секретами до собственных экосистем поверх Spring Boot. Хватит на пару вечеров.
💬 Какой доклад зашёл больше всего? Пишите в комментариях
data class Vector(val x: Double, val y: Double) {
companion {
val ZERO = Vector(0.0, 0.0)
}
}
Выглядит как companion object, только без object. На JVM содержимое такого блока компилируется в статические члены. Никакого отдельного объекта и меньше церемоний при работе с Java.
Ещё интереснее companion extensions. Они позволяют добавить член любому Kotlin- или Java-классу, даже если у него нет собственного компаньона.
companion fun Vector.unit(angle: Double) =
Vector(cos(angle), sin(angle))
Вызывать можно привычно через Vector.unit(...).
Существующие companion object никуда не исчезают. Они по-прежнему нужны, если компаньон должен реализовать интерфейс или обладать собственной идентичностью.
Для экспериментов нужен флаг -Xcompanion-blocks-and-extensions. Только учитывайте, что расширения-компаньоны пока создают pre-release-бинарники. Тащить их в публичную библиотеку рановато. 🙅♂️
🔗 Наш перевод на Хабр
🔗 Анонс JetBrains
🔗 KEEPEnvironmentPostProcessor побудила довольно большое обсуждение вокруг темы того:
- Как Spring грузит конфигурацию в целом?
- При чём тут bootstrap.yaml и BootstrapContext?
- Что кардинально поменялось?
- И в чём же такая особенность spring.config.import и почему она требует особого внимания?
⚠️ Полезно всем, кто хоть раз пытался понять, откуда Spring взял конкретное значение
🔗 Статья на Хабр: https://habr.com/ru/companies/spring_aio/articles/1091064/X25519MLKEM768. Она объединяет классический X25519 и постквантовый ML-KEM-768.
Секрет зависит от обоих алгоритмов. Даже если один из них когда-нибудь взломают, второй продолжит защищать соединение.
Клиент на JDK 27 по умолчанию предлагает серверу две схемы. Новую гибридную и обычную X25519. Если сервер поддерживает гибридную, используется она. Если нет, TLS продолжает работать по старой схеме.
Для нас, как для Spring-разработчиков приятно то, что при использовании стандартного javax.net.ssl защита включается по умолчанию. На код никак не влияет, если приложение не переопределяет список TLS-групп.
👀 Получается редкий апгрейд безопасности, который можно получить простым обновлением JDK. Правда, защищает он не от квантового компьютера сегодня, а от слишком -XX:AOTCacheOutput при обучении, -XX:AOTCache в проде. Включать ничего не нужно.
Код из кэша остаётся обычным кодом HotSpot. Если рабочая нагрузка ушла в сторону от обучающей, метод деоптимизируется и перекомпилируется JIT-ом, как любой другой. Профили из JEP 515 при этом продолжают работать: по ним JVM выбирает порядок загрузки кода и пересобирает методы.
Чем AOT-код хуже JIT-кода
JIT компилирует метод, когда нужные классы давно инициализированы. Он подставляет значения static final полей как константы и выбрасывает проверки инициализации. Код из кэша начинает работать раньше, чем классы успели инициализироваться, а значение static final может отличаться от запуска к запуску. Поле приходится читать по-настоящему.
Для методов, которые обращаются к статике других классов, C2 собирает две версии: медленную с проверками инициализации и быструю без них.
Поэтому JIT никуда не уходит. AOT-код даёт быстрый старт, до пика доводит перекомпиляция.
Когда кэш не сработает
Обучающий и рабочий запуски должны совпадать по архитектуре процессора, набору инструкций и сборщику мусора: барьеры GC вшиты в машинный код. Собрали образ на хотсе с AVX-512, pod уехал на узел без него - код из кэша не загрузится. Ошибки не будет, JVM молча перейдёт на интерпретатор и JIT. В кластере с разнородными узлами это легко пропустить.
Поддерживаются x64 и AArch64, из сборщиков - Serial, Parallel, G1 и ZGC.
Цифры
По данным JEP, AOT-кэш без кода сокращает время старта на 50-70%, с кодом - на 65-80%. Основную часть выигрыша на старте дают уже вышедшие JDK 24-26, новый JEP добавляет 10-15 п.п.
Заметнее эффект на прогреве. В PR есть замер на Quarkus-сервисе с двумя ядрами: обычная JVM начинает отвечать быстрее 1 мс после 420 запросов, JDK 26 с AOT-кэшем - примерно после 200, сборка с JEP 544 - чуть позже сотого.
Второй эффект касается CPU. JIT на старте перестаёт отбирать ядра у приложения, и сильнее всего это видно на контейнерах с лимитом в 1-2 CPU. Там, где запас по CPU закладывали под прогрев, его можно будет пересмотреть.
Оценить вклад кода на своём сервисе можно диагностическим флагом:
-XX:+UnlockDiagnosticVMOptions -XX:-AOTCodeCaching
Заодно станет видно, насколько вырос файл кэша.
Что остаётся неудобным
Обучающий запуск. Кэш хорош настолько, насколько нагрузка при сборке похожа на боевую, а готового инструмента для этого нет. Spring Boot и Quarkus умеют записывать кэш при сборке, но прогон реальных сценариев остаётся на вашей стороне. Упрощение этого процесса авторы JEP прямо вынесли за рамки.
JEP: https://openjdk.org/jeps/544