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
إظهار المزيد📈 نظرة تحليلية على قناة تيليجرام Spring АйО
تُعد قناة Spring АйО (@spring_aio) لاعباً نشطاً. يضم المجتمع حالياً 10 943 مشتركاً، محتلاً المرتبة 11 249 في فئة التكنولوجيات والتطبيقات والمرتبة 58 243 في منطقة روسيا.
📊 مؤشرات الجمهور والحراك
منذ تأسيسه في невідомо، حقق المشروع نمواً سريعاً وجمع 10 943 مشتركاً.
بحسب آخر البيانات بتاريخ 30 أكتوبر, 2026، تحافظ القناة على نشاط مستقر. خلال آخر 30 يوماً تغيّر عدد الأعضاء بمقدار 56، وفي آخر 24 ساعة بمقدار -6، مع بقاء الوصول العام مرتفعاً.
- حالة التحقق: غير موثّقة
- معدل التفاعل (ER): يبلغ متوسط تفاعل الجمهور 52.86%. وخلال أول 24 ساعة من النشر يحصد المحتوى عادةً 22.38% من ردود الفعل نسبةً إلى إجمالي المشتركين.
- وصول المنشورات: يحصل كل منشور على متوسط 5 785 مشاهدة. وخلال اليوم الأول يجمع عادةً 2 449 مشاهدة.
- التفاعلات والاستجابة: يتفاعل الجمهور بانتظام؛ متوسط التفاعلات لكل منشور يبلغ 43.
- الاهتمامات الموضوعية: يركز المحتوى على مواضيع رئيسية مثل айо, хабр, api, jep, amplicode.
📝 الوصف وسياسة المحتوى
يصف المؤلف القناة بأنها مساحة للتعبير عن الآراء الذاتية:
“Русскоязычное сообщество Spring-разработчиков.
Habr: bit.ly/433IK46
YouTube: bit.ly/4h3Ci0x
VK: bit.ly/4hF0OG8
Rutube: bit.ly/4b4UeX6
Яндекс Музыка: bit.ly/3EIizWy
Чат для общения: @spring_aio_chat
По вопросам сотрудничества: @befayer”
بفضل وتيرة التحديث المرتفعة (أحدث البيانات بتاريخ 31 أكتوبر, 2026) تحافظ القناة على حداثتها ومستوى وصول مرتفع. وتُظهر التحليلات تفاعلاً نشطاً من الجمهور، ما يجعلها نقطة تأثير مهمة ضمن فئة التكنولوجيات والتطبيقات.
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