1) Не покидает ощущение, что статья была пропущена через чат гпт, эти формулировки в формате -> "Когда виртуальные потоки — must have, а когда лучше не надо" и т.д 2) Ничего не сказано про свич контекст, что это дорогая операция и изначально в этом и проблема, что треды платформы, которые скачут между собой это и есть дорогая операция, которая например с виртуальными не обходится так дорого (потому что поток создан - поток убит) 3) Часть которая описывает Netflix problem - интересная, но при этом в самом же java guide от Oracle, написано и объяснено поведение "pinning". Почему же, и не написать дефиницию его и поведение, чтобы люди понимали, что это ожидаемое поведение. 4) Не сказано, что виртуальные потоки нужны для асинхронищы и reactive streams в основном больше всего и выигрывают от этого. Quarkus летает за счет этого, ну и прочие Vert.X, Munity. 5) Последний скриншот с таблицей, которое сделало гпт (как будто) оставлю без комментариев.
P.S В общем если действительно разбирать virtual thread. Советую
2) P.S ну и ключевые 2 вещи, которые хотелось бы видеть, прям жирным шрифтом "Converting n platform threads to n virtual threads would yield little benefit; rather, it's tasks that need to be converted." "Virtual threads can significantly improve the throughput—not the latency—of servers written in the thread-per-request style."
P.S Read-Through - разве не является просто логической итерацией - Cache-Aside. Сложилось впечатление, что Read-Through это просто обертка поверх Cache-Aside, когда добавили 1 уровень абстракции. В целом стало интересно, а есть ли ещё какие-то паттерны чтения помимо этих двух (если это в целом не одно и тоже)
Тоже не понимаю тикет систему, помню как тестировщик из Индии, нашел баг - написал мне, я быстро исправил, там буквально 1 условие надо было подправить, я комитнул, пушнул, забилдил и т.д. Сказал все готово, а потом он сказал, что надо было мне создать тикет, описать баг (скопировать его описание) и сказать какой фикс и подвигать на канборде. Меня это так бесит. Я понимаю, когда тикеты про какую-ту серьезную часть кода или решение, но блин тикет ради исправление пару рядков кода.
Причем я не совсем понимаю, а какой толк от отчетности, идея же, чтобы продукт был лучше. Он им стал
Понял свою ошибку, исправлюсь, спасибо за фидбек
1) Не покидает ощущение, что статья была пропущена через чат гпт, эти формулировки в формате -> "Когда виртуальные потоки — must have, а когда лучше не надо" и т.д
2) Ничего не сказано про свич контекст, что это дорогая операция и изначально в этом и проблема, что треды платформы, которые скачут между собой это и есть дорогая операция, которая например с виртуальными не обходится так дорого (потому что поток создан - поток убит)
3) Часть которая описывает Netflix problem - интересная, но при этом в самом же java guide от Oracle, написано и объяснено поведение "pinning". Почему же, и не написать дефиницию его и поведение, чтобы люди понимали, что это ожидаемое поведение.
4) Не сказано, что виртуальные потоки нужны для асинхронищы и reactive streams в основном больше всего и выигрывают от этого. Quarkus летает за счет этого, ну и прочие Vert.X, Munity.
5) Последний скриншот с таблицей, которое сделало гпт (как будто) оставлю без комментариев.
P.S В общем если действительно разбирать virtual thread. Советую
Considerations for integrating virtual threads in a Java framework: a Quarkus example in a resource-constrained environment
Virtual Thread support reference - Quarkus
2) P.S ну и ключевые 2 вещи, которые хотелось бы видеть, прям жирным шрифтом
"Converting n platform threads to n virtual threads would yield little benefit; rather, it's tasks that need to be converted."
"Virtual threads can significantly improve the throughput—not the latency—of servers written in the thread-per-request style. "
Странно, что никто не скинул довольно старую, но очень важную статью
Toyota: 81 514 нарушений в коде / Хабр
То, что такие кейсы происходят не новость, их причина, лежит не в плоскости, что инженер плохой
Прекрасная статья, спасибо за полезные материалы
P.S
Read-Through - разве не является просто логической итерацией - Cache-Aside. Сложилось впечатление, что Read-Through это просто обертка поверх Cache-Aside, когда добавили 1 уровень абстракции. В целом стало интересно, а есть ли ещё какие-то паттерны чтения помимо этих двух (если это в целом не одно и тоже)
Тоже не понимаю тикет систему, помню как тестировщик из Индии, нашел баг - написал мне, я быстро исправил, там буквально 1 условие надо было подправить, я комитнул, пушнул, забилдил и т.д. Сказал все готово, а потом он сказал, что надо было мне создать тикет, описать баг (скопировать его описание) и сказать какой фикс и подвигать на канборде. Меня это так бесит. Я понимаю, когда тикеты про какую-ту серьезную часть кода или решение, но блин тикет ради исправление пару рядков кода.
Причем я не совсем понимаю, а какой толк от отчетности, идея же, чтобы продукт был лучше. Он им стал