Комментарии 6
NioSocketHandler внутри как раз использует synchronized, тут все преимущества Loom теряются. Интересно, можно ли переключить Tomcat из режима nio на обычные сокеты, вроде же Loom как раз хотел именно их случай оптимизировать?
А вообще, отсутствие поддержки synchronized убивает преимущества Loom. Хотели же сделать нечто что будет ускорять старый код автоматически, а в итоге его всё равно надо переписывать.
Это означает, что мы сможем легко мигрировать наш блокирующий код на Loom
К сожалению, он далеко не всегда "наш". Поэтому легко не выйдет. Ну так, для примера — вот у меня маленький проект, три разработчика. Но при этом скажем 200 внедрений, и обрабатывает кучу данных. Но основан он на Apache Spark, который имеет под 2000 контрибьюторов. То есть, фреймворк что мы применяем, где-нибудь так на два-три порядка больше, чем наше приложение. И смигрировать его нашими силами — совершенно нереально. И такая ситуация с переиспользованием кода, когда вы чужого кода используете больше, чем сами пишете — она сегодня совершенно типична.
Практически уверен, что после релиза Loom серьезно возьмутся за перформанс и в конечном счете доведут его до близких к асинк библиотекам значений, так было например с parallel streams, когда при появлении в Jdk8, они работали примерно в 2 раза медленнее, чем уже в Jdk11.
Мне кажется самое важное - это не перформанс в моменте, а то, насколько Loom в принципе способен поменять ландшафт современного девелопмента. Ни у одной другой платформы нет такой фичи, которая бы не требовала от программиста специальных приседаний на уровне кода для оптимального использования железа, а у Jdk появится.
Project Loom и Spring Boot: тесты производительности