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
Ko'proq ko'rsatish📈 Telegram kanali Spring АйО analitikasi
Spring АйО (@spring_aio) kanali faol ishtirokchi. Hozirda hamjamiyat 10 943 obunachidan iborat bo'lib, Texnologiyalar & Aralashmalar toifasida 11 249-o'rinni va Rossiya mintaqasida 58 243-o'rinni egallagan.
📊 Auditoriya ko‘rsatkichlari va dinamika
невідомо sanasidan buyon loyiha tez o‘sib, 10 943 obunachiga ega bo‘ldi.
30 Oktabr, 2026 dagi oxirgi ma’lumotlarga ko‘ra kanal barqaror faollikka ega. Oxirgi 30 kunda obunachilar soni 56 ga, so‘nggi 24 soatda esa -6 ga o‘zgardi va umumiy qamrov yuqori darajada qolmoqda.
- Tasdiqlash holati: Tasdiqlanmagan
- Jalb etish (ER): Auditoriya o‘rtacha 52.86% darajada jalb etiladi. Nashrdan keyingi dastlabki 24 soatda kontent odatda umumiy obunachilar sonining 22.38% ini tashkil etuvchi reaksiyalarni to‘playdi.
- Post qamrovi: Har bir post o‘rtacha 5 785 marta ko‘riladi; birinchi sutkada odatda 2 449 ta ko‘rish yig‘iladi.
- Reaksiyalar va o‘zaro ta’sir: Auditoriya faol: har bir postga o‘rtacha 43 ta reaksiya keladi.
- Tematik yo‘nalishlar: Kontent айо, хабр, api, jep, amplicode kabi asosiy mavzularga jamlangan.
📝 Tavsif va kontent siyosati
Muallif resursni shaxsiy fikrni ifoda etish maydoni sifatida ta’riflaydi:
“Русскоязычное сообщество Spring-разработчиков.
Habr: bit.ly/433IK46
YouTube: bit.ly/4h3Ci0x
VK: bit.ly/4hF0OG8
Rutube: bit.ly/4b4UeX6
Яндекс Музыка: bit.ly/3EIizWy
Чат для общения: @spring_aio_chat
По вопросам сотрудничества: @befayer”
Yuqori yangilanish chastotasi (oxirgi ma’lumot 31 Oktabr, 2026 da olingan) sababli kanal doimo dolzarb va katta qamrovli bo‘lib qoladi. Analitika auditoriya kontent bilan faol hamkorlik qilishini, uni Texnologiyalar & Aralashmalar toifasidagi muhim ta’sir nuqtasiga aylantirishini ko‘rsatadi.
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