# Почему Kotlin возвращает статику и как баг в OpenJDK роняет JVM

Источник: https://youtu.be/65JKrJXw6YI?si=CQw4S7cBnitEaj-I
Канал: Spring АйО
Опубликовано: 21.10.2026

---

В 76-м выпуске подкаста «Spring АйО» ведущие Павел Кислов и Михаил Поливаха разбирают ключевые события индустрии разработки ПО: от засилья искусственного интеллекта на международных IT-конференциях до неожиданных архитектурных разворотов языка Kotlin. Собеседники также погружаются в глубокий JVM-хардкор, обсуждая опасности статического состояния в памяти, проблемы проекта Ktor и свежий баг в OpenJDK, приводивший к падению виртуальной машины из-за инструкций процессора AVX-512.

## 🍁 Осенний сезон конференций и экспансия AI
[[JUMP:00:33]]

Осень ознаменовалась стартом крупного сезона технических конференций как в России, так и за рубежом [00:33]. Михаил Поливаха, регулярно выступающий на международных и локальных площадках, отметил радикальное изменение контента мероприятий под давлением хайпа вокруг нейросетей [01:57]. Если раньше программы Joker, JPoint или зарубежных конференций практически полностью посвящались чистому стеку Java, то теперь даже классические мероприятия делят программы пополам: один день отводится на Java, а второй — на рассуждения о будущем профессии разработчика под влиянием AI [02:52].

По оценке Поливахи, подобная трансформация в мировом масштабе выражена даже острее, чем в РФ:

*   Российский IT-рынок достаточно компактный и обособленный, здесь мероприятия вроде JVM Day пытаются удерживать строгий фокус на Java [03:57].
*   Европейский и международный рынок (Devoxx, Voxxed Days, J-Fall, Jfokus, JavaZone, Devnexus) в десятки раз масштабнее, но практически все крупные игроки переводят существенную часть треков на искусственный интеллект [04:39].

Как передает Поливаха слова Серджи Алмара (Sergi Almar), организатора Spring I/O в Барселоне, интерес к докладам об AI исходит главным образом от самих разработчиков, жаждущих услышать о новых инструментах [05:45]. Однако этот тренд среди инженеров уже начинает угасать: невозможно сделать полтора десятка конференций с одинаковыми темами про интеграцию LLM в процесс разработки без того, чтобы контент не стал повторяться [05:58].

## 🏢 Медленная адаптация в энтерпрайзе и реалии бизнеса
[[JUMP:06:14]]

В то время как интерес аудитории к поверхностным темам об AI падает, в корпоративном секторе внедрение технологий идет стабильно, но медленно [06:27]. Михаил Поливаха подчеркнул распространенную ошибку восприятия: ленты соцсетей и медиа создают иллюзию тотальной революции, показывая лишь самый передовой край индустрии [06:57]. На практике IT-сектор крайне неоднороден, а распределение технологических бумов происходит неравномерно [07:35]. 

В качестве примера Поливаха привел бюрократические процедуры в странах Европы и США, где государственные институты до сих пор во многом полагаются на бумажные визы и физические печати в паспортах, несмотря на разговоры о цифровизации [08:02]. Разговаривая на Devoxx с директором по развитию компании Vaadin, Поливаха выяснил, что разговоры о крахе классических вендоров из-за генеративного AI пока никак не отражаются на их реальных бизнес-метриках: европейский банковский сектор и бэкенд-решения продолжают стабильно работать со старыми проверенными инструментами [08:43].

Павел Кислов, комментируя ситуацию вокруг продуктов вроде JetBrains и OpenIDE, отметил, что на практике за громкими презентациями часто скрывается «Confidence Driven Development» — концепция, работающая со сцены, но с трудом применимая в продакшене [10:45]:

*   Разговоры о росте продуктивности в 10 раз благодаря генеративным моделям разбиваются о реальность: из тысячи разработчиков реальное ускорение получают единицы, остальные работают в прежнем темпе [12:46].
*   Выигрывают динамичные команды, способные быстро разворачиваться на 180 градусов и проверять гипотезы, тогда как для основной массы внедрение LLM остается поверхностной надстройкой [12:04].

## 📉 Кризис посещаемости: почему Devoxx теряет солдауты
[[JUMP:12:36]]

На крупнейшей европейской конференции Devoxx Belgium (рассчитанной на 3200–3500 участников в кинокомплексе Kinepolis в Антверпене) около 60% докладов из 6–8 параллельных треков были посвящены AI-агентам и инструментарию, и лишь 40% — классической разработке [13:27]. При этом мероприятие впервые за долгое время столкнулось с отсутствием традиционного молниеносного солдаута [14:08].

По данным Поливахи, организаторы Devoxx продали лишь около 2700 билетов, зафиксировав спад продаж примерно на 15% [15:55]. Похожая картина наблюдалась и на Spring I/O: если раньше все 1300 мест выкупались за 4–5 месяцев до старта, то теперь закрытие продаж произошло буквально в последние дни перед событием [17:41]. 

В кулуарном разговоре организаторы Devoxx подтвердили Поливахе свои опасения: падение посещаемости уже затронуло Devoxx Poland, Devoxx UK и Devoxx France [19:56]. Главный вопрос индустрии: зачем специалисты покупают билеты сегодня?

*   Большая часть посетителей европейских конференций не оплачивает поездки из своего кармана — расходы покрывают компании вроде амстердамских банков в рамках бюджета на обучение [22:31].
*   Такие делегаты часто бесцельно ходят по стендам и залам, поскольку не имеют четкой рабочей задачи или образовательного фокуса [22:58].

## ⭐ Джош Лонг, Брайан Гетц и шоу талантов
[[JUMP:23:39]]

Михаил Поливаха убежден, что главным незаменимым преимуществом офлайн-мероприятий остаются звездные спикеры и атмосфера шоу, которые невозможно эмулировать алгоритмами [23:26]:

> «Джош Лонг — это Джош Лонг с нейросетями или без них. Брайан Гетц — это Брайан Гетц». [24:33]

В Европе известность спикеров колоссальна: на выступления признанных звезд Java-сообщества (Джош Лонг, Брайан Гетц, Виктор Рентей, Торбен Янсен) собираются полные залы даже в тех случаях, когда темы докладов банальны или уже неоднократно освещались на YouTube [24:46]. Джош Лонг превращает рассказ о Spring в фееричное шоу с юмором, ради чего люди и приходят в зал [27:01].

Павел Кислов противопоставил этому российский опыт: в отечественном комьюнити слушатели традиционно более требовательны к технической новизне [27:40]. Если спикер в РФ начнет пересказывать документацию релизов Spring Boot 3 или 4, публика на Joker или JPoint немедленно раскритикует доклад за отсутствие практической ценности, тогда как на западных площадках комфортное повторение базовых истин в исполнении харизматичного лектора воспринимается позитивно [29:36].

## 📚 ChatGPT против бумажных учебников
[[JUMP:29:36]]

Обсуждая ценность получения информации, Кислов поделился личным опытом: сублимированное знание, полученное через быстрый поиск или готовый ответ от ChatGPT, перестало приносить удовлетворение [30:31]. Из-за этого ведущий вернулся к штудированию бумажных учебников по физике за 8–11 классы и задачников по математике Прасолова, находя особое удовольствие в самостоятельном прохождении всех этапов решения [30:59]:

*   Готовый ответ от ИИ Кислов сравнил с «пережеванной пищей», лишенной индивидуального вкуса [31:55].
*   Посещение конференций ценно проживаемым опытом, а не сухой выжимкой фактов.

Поливаха парировал с менеджерской точки зрения: абстрактное чувство «вкуса» трудно оцифровать в корпоративные метрики [32:24]. Инженерам стоит учиться применять «мышление из первых принципов» по методу Илона Маска, четко формулируя, почему именно фундаментальный подход к получению знаний дает измеримое профессиональное преимущество [33:40]. Иронизируя над тягой бизнеса к оптимизации всего подряд, Кислов пошутил, что излишнее погружение в метрики приводит к идеям «отменить больничные, потому что из-за них падают графики» [34:22].

## 🧱 Kotlin возвращает статику: companion blocks и ловушки памяти
[[JUMP:34:39]]

Одной из центральных технических тем выпуска стало намерение разработчиков Kotlin ввести так называемые *companion blocks* — фактически возвращение концепции статических блоков без создания объектов, от которых создатели языка ранее осознанно отказывались в пользу `companion object` [35:29].

Михаил Поливаха подробно разобрал, почему ключевое слово `static` в Java является источником архитектурных проблем [35:40]:

1.  **Неопределенный жизненный цикл.** Любое состояние, привязанное к статическому полю, живет в приложении неопределенно долго. Выгрузка классов загрузчиком (*class unloading*) в типичной JVM происходит крайне редко [38:16].
2.  **Утечки ресурсов.** В качестве свежего примера Поливаха привел баг с утечкой потоков, обнаруженный в их проекте: встроенный HTTP-клиент JDK использует пул соединений (с виртуальными потоками в Java 21+), и попытка вынести клиента в статическую область приводит к зависанию ресурсов при перезапусках контекста (например, в Spring Boot DevTools или тестах) [36:29].
3.  **Жесткая связанность (*tight coupling*).** Статические вызовы невозможно переопределить, параметризовать или чисто замокать без инструментов вроде PowerMock [39:14].

Утверждение о том, что состояние должно жить всё время работы программы — опасное заблуждение из мира C/C++, где подобный подход порождает дыры в безопасности и тяжелые утечки памяти [40:48]. Даже создатели Rust построили модель владения вокруг строгих границ жизненного цикла ресурсов [41:13].

При этом решение Kotlin с `companion object` Поливаха назвал спорным компромиссом. По его словам, сами создатели языка (включая Андрея Бреслава) впоследствии признавали внедрение синглтонов-компаньонов спорным шагом, сильно усложнившим интероп с Java-байткодом [44:10].

### Почему разработчикам нужны статические extension-функции?
[[JUMP:44:22]]

С другой стороны, Поливаха горячо поддержал идею появления статических extension-функций в Kotlin [45:12]. В качестве аргумента он сослался на классический труд Джошуа Блоха *Effective Java*, где подробно объясняются преимущества статических фабричных методов над конструкторами:

*   Конструкторы не имеют выразительных имен и не передают семантику намерений вызывающего кода (например, разница между созданием пустого заказа и готового: `Order.ready()`) [48:04].
*   В Java конструкторы не обязаны делегировать вызовы каноническому конструктору, что часто размывает архитектуру [46:58].
*   Статические extensions позволили бы инженерам дописывать удобные фабричные методы поверх сторонних Java API без необходимости писать громоздкие обертки [49:23].

## 🕊️ Раздвоение личности: JPA, Spring и судьба Ktor
[[JUMP:50:00]]

Ведущие сошлись во мнении, что Kotlin регулярно оказывается в положении «двойного агента» [50:16]. Изначально язык создавался не для Android, а как более совершенная замена Java на бэкенде [50:44]. Однако, выйдя на этот рынок 8–10 лет назад, авторы столкнулись с абсолютной монополией Hibernate и JPA [51:25]:

*   Kotlin проповедовал закрытость классов по умолчанию (*final by default*), но JPA требовал открытых сущностей для создания прокси [50:29].
*   Пришлось идти на компромиссы и создавать специальные плагины компилятора (`all-open`, `no-arg`), ломая изначальную пуританскую философию [50:29].

Аналогичный внутренний конфликт прослеживается в судьбе легковесного фреймворка Ktor от JetBrains [51:52]. Проект страдает от размытого позиционирования:

*   Ktor задумывался как чистая асинхронная Kotlin-альтернатива Spring, но в разы уступает ему по функциональности и размеру экосистемы [53:16].
*   Одновременно с разработкой Ktor компания JetBrains поддерживает стратегическое партнерство со Spring Boot, превращая развитие собственного фреймворка в басню «Лебедь, Рак и Щука» [53:29].

## 💥 Как проект Leyden и AVX-512 уронили виртуальную машину в продакшене
[[JUMP:53:29]]

Финальная часть беседы коснулась хардкорных оптимизаций JVM в рамках Project Leyden, направленных на максимальный перенос вычислений в стадию Ahead-of-Time (AOT) [54:42].

Эволюция сохранения данных между перезапусками JVM:

1.  **AppCDS (Application Class Data Sharing):** в бинарный архив сбрасывались разобранные метаданные классов, что уменьшало Startup Time и потребление памяти Metaspace [55:07].
2.  **AOT Cache:** к метаданным классов добавили сырые профилировочные данные для компиляторов C1 и C2 [55:22].
3.  **Сохранение машинного кода:** свежая инициатива предполагает прямое сохранение в кэш скомпилированных машинных инструкций (результатов работы C2), минуя фазу профилирования на старте [55:49].

По спецификации механизм AOT Cache обязан быть абсолютно безопасным: если кэш невалиден или поврежден, JVM должна штатно откатиться на медленную загрузку и обычную JIT-компиляцию через интерпретатор [56:57]. Однако команда Поливахи столкнулась с критическим сбоем [58:14].

При сборке релизного Docker-образа на виртуальной машине x86-64 с процессором, поддерживающим векторные инструкции **AVX-512**, сгенерированный AOT-кэш намертво ронял JVM с `core dump` при запуске на серверах с аналогичной ОС, но без поддержки блока инструкций AVX-512 [59:32].

Как выяснилось, в кодовой базе OpenJDK присутствовал баг [59:19]. Реакция мейнтейнеров оказалась противоречивой:

*   В ветку **Java 25 LTS** разработчики OpenJDK внесли быстрый бэкпорт, который фактически просто отключил генерацию кэша при использовании нестандартных инструкций процессора [1:00:23].
*   Полноценное исправление заложено лишь в **Java 27**, вышедшую в сентябре [1:01:02].
*   Однако Spring Boot еще не получил полноценную поддержку Java 27 (ожидается в версиях линейки 4.x), из-за чего эксплуатировать оптимизацию в полной мере пока невозможно [1:01:15].

Подводя итоги, Поливаха подчеркнул, что даже на глубоких аппаратных уровнях абсолютных гарантий не существует: ошибки регулярно встречаются как в OpenJDK, так и в микрокоде самих центральных процессоров [1:04:23]. Все заверения облачных вендоров и гарантии надежности в конечном счете упираются в суровые условия SLA, где любые фатальные падения нередко признаются «негарантийными случаями» [1:05:45].