Virtual Threads vs Goroutines: как две платформы решили одну задачу по-разному

Виртуальные потоки — одна из самых громких фич Java за последние годы. О них много говорят на уровне «включите spring.threads.virtual.enabled=true, и всё полетит». Но что происходит под капотом? Почему реализация получилась именно такой? И главное — как она соотносится с goroutines в Go, где похожую задачу решали с другой стороны?

В этом докладе мы разберем виртуальные потоки Java не как feature, а как инженерное решение. Посмотрим, как устроен планировщик на базе ForkJoinPool, что такое continuations и как работает механизм freeze/thaw, почему synchronized до Java 24 был проклятием и что изменил JEP 491. Я покажу реальные места в исходниках OpenJDK — и Java-часть в VirtualThread.java, и нативную в continuationFreezeThaw.cpp — чтобы стало понятно, где заканчивается магия и начинается обычный код.

Параллельно будем сравнивать с Go'шной моделью GMP: где сходства, где принципиальные отличия и какие компромиссы выбрали обе платформы. Я разберу, почему в Go goroutine стартует за сотни наносекунд, а Virtual Thread — за микросекунды, и что это значит для реальных приложений. Покажу сценарии, где виртуальные потоки дают выигрыш, и антипаттерны, которые всё сломают. Доклад для тех, кому мало «смотрите, как удобно» — кто хочет понять, как это реально работает, какие ограничения остались в Java 25, и стоит ли переписывать production-код прямо сейчас.