Иван Углянский - Thread Wars: проект Loom наносит ответный удар
ฝัง
- เผยแพร่เมื่อ 22 ส.ค. 2024
- Ближайшая конференция - Joker 2024, 9 октября (Online), 15-16 октября (Санкт-Петербург + трансляция).
Подробности и билеты: jrg.su/Ypf1HW
- -
На фоне приближающегося к релизу проекта Loom в Java-мире только и разговоров, что о корутинах да о легковесной многопоточности!
Но ведь Java на этом поле далеко не первая, скорее наоборот: это один из последних современных языков, где добавляют корутины. Так что же, мы просто получаем в точности то, что уже есть у соседей? Отличаются ли чем-нибудь корутины в Java от корутин в Kotlin? А от горутин в Go? Наши корутины будут лучше или хуже? И почему их так долго делают, раз в других языках все уже давно есть?
В этом докладе осознаем место наших корутин в мире, для чего разберемся в истории вопроса. Обсудим, как решение о реализации одной фичи может повлиять на облик всего языка программирования, сравним реализации корутин в разных языках и, конечно, закопаемся в кишочки проекта Loom.
Скачать презентацию: squidex.jugru....
![ทางเดินชีวิต - ธีเดช ทองอภิชาติ x อ.ไข่ มาลีฮวนน่า [Official MV]](http://i.ytimg.com/vi/1f3wcG16dd4/mqdefault.jpg)
Лучший доклад по луму
Отличный доклад, спасибо!
Я человек простой: вижу Углянского выступление - ставлю лайк.
Мощный доклад
Большое спасибо за отличный доклад! Очень просто и понятно)
Спасибо!
Reactor красивее чем Future, ахахаха.
Особенно круто, что большие цепочки map сказываются на перформансе.
Синки это бомба!
А еще круто с пустыми Mono.
Очень интуитивно, что не происходит ничего, и вообще к сложно отлавлавлемым багам не приводит.
switchIfEmty для throe ошибок в случае тоже огонь
Ну и невозможность нормально залогировать тела запрос/ответов тоже бомба!
Классный доклад!
gc - garbage collector, КЦ - из фильма кин дза дза
epoll na windows net tolko na linux
Прям так сильно отличается от сишарпа )
кто понял какая цена ошибки если ЦПУ интенсив задачу поручить виртуальному потоку и можно ли сделать ковеер, чтоб незаконченные задачи витруал автоматом делегировались в не-виртуал. спасибо
Цена ошибки -- производительность. ЦПУ интенсив таска надолго забирает себе один из воркеров, и тогда получается, что оставшиеся таски будут выполняться другими воркерами. Пример из жизни: это почти тоже самое, что и выполнение большой задачи-ебошки, на которую изначально отправили 4 человек, но потом одного отправили хер пойми куда делать че т другое. И вот остались 3 грустных чела с почти тем же объемом работы.
Вопрос - зачем cpu intensive code пытается пытаться параллелить? Какая цель?
Можно ошибочно допускать такой код к исполнению на виртуальных потоках. В идеале хочется, чтобы рантайм помог в такой ситуации и сам снял поток с исполнения.
Технически такая приостановка виртуального потока мало чем отличается от приостановки для сборки мусора и ее сделать должно быть просто. Но, видимо, есть места, например, в недрах рантайма, где вытесняться совсем не хочется, а определить такие места достаточно трудно.
По-хорошему, надо было делать async/await и выкинуть постепенно все легаси, но переписывать килотонны энтерепрайза слишком дорого, поэтому мы обложимся теперь костылями, будет что спрашивать на собесах!
Че хорошего в async/await?
вам же первую часть доклада рассказывали почему async/await плохая идея, собственно я прочувствовал это на себе, когда сел писать на ts. сидишь и правшь код по стеку вызова. и тогда надо дублировать методы стандартной библиотеки и старый код не получит никаких преимуществ новой jvm. Костыли, которые дорого и красиво продали, раз вы тут не первый с таким странным предложением…
Async/await это и есть костыль. В Java все правильно сделали
Я писал и на джаве и на сишарпе и на тайпскрипте, никаких особо проблем с асинком нет, он явный и понятный, работает предсказуемо. Переводил проект на асинки и это была рутина, минимум проблем и что важно, это можно делать постепенно, не надо переключать рантаймв какой-то режим и переписывать все сразу. Будь джава новым языком я бы согласился и с новым подходом. Существующие приложения не смогут получить никаких плюсов, их все равно придется переписывать и это нереально по затратам и сложности, понадобится еще поддержка в серверах, фреймворках, либах, драйверах баз - ждите вечность. И то и другое в случае джавы костыли, которые навсегда останутся в джвм. Отдельно скажу про именование классов и методов - в джаве это делают максимально неинтуитивно, че стоит только калька с линкью.
@@bananasbaв спринге вы одной пропертей включаете обработку запросов через виртуальные потоки, о каком переключении режимов рантайма вы говорите? о какой долгой миграции? существующие приложения получают плюсы, вам это показали и объяснили, вы или ничего не делаете и сетапите проперти, или на самом верху в коде инициализации потока меняете код. а не правите пол проекта async-await раком. я вот писал на ts и мне async await именно по этой причине не понравился совсем и не знаю кому это может нравиться. и чтобы не сломать существующий код надо на каждый старый блокирующий метод завести рядом новый - асинхронный. В общем это в сумме полностью бредовая идея, которая не имеет ни одного плюса по сравнению с loom, кроме того, что вам лично удобно из-за привычки ;) драйвера вам перепишут, не волнуйтесь, заменить synchronized задача для джуна. отдельно скажу, что понятия не имею о каком правильном именовании классов и методов вы говорите.
Интересно, виртуальные потоки можно привязать к конкретному физическому потоку? или loom-овский планировщик раскидывает их как захочет и повлиять на это в настоящей реализации никак нельзя?
Нет, привязать никак нельзя. Более того, вы даже не можете узнать, на каком потоке-носителе запущен текущий виртуальный поток: The identity of the carrier is unavailable to the virtual thread (JEP 444). Виртуальные потоки и потоки-носители логически независимы.
@@ZhekaKozlov ((VirtualThread) Thread.currentThread()).carrierThread ?
Отличный доклад. В rust async-await читается намного короче.
чем короче? тут вы лишней буквы не пишете, кроме кода создания пула, который может быть вообще внутри потрохов фреймворка, типа спринга. В go короче, но в java не любят добавлять новые ключевые слова ну и хочется все же как-то случай ошибки обработать
а если как в расте?