Контекст у виртуального потока есть, но он не системный. JVM сама хранит его как continuation — то есть просто состояние выполнения и стек в heap. Под него не создается отдельный поток или стек в ядре.
Спасибо за вдумчивый комментарий — вопрос действительно важный.
Вы правы: когда поток ОС блокируется на I/O, он действительно спит и не тратит CPU. Проблема не в расходе вычислительных ресурсов, а в количестве таких потоков.
ОС-поток — это дорогая вещь: для каждого нужно создать стек (обычно мегабайт), сохранить контекст, управлять переключениями, синхронизацией и т.д. Если у нас тысячи одновременных запросов, ожидающих ответ от БД или сети, то тысячи потоков ОС будут находиться в спящем состоянии, занимая память и ресурсы ядра. JVM, в свою очередь, вынуждена держать эти структуры и выполнять переключения при каждом пробуждении. Это и создает накладные расходы.
Виртуальные потоки решают не задачу "ожидания байтиков", а проблему масштабирования, то есть они позволяют иметь миллионы задач, ожидающих I/O, при этом переиспользуя ограниченное количество настоящих (carrier) потоков ОС. Планирование действительно реализовано в JVM, но оно легковесное: это просто привязка контекста задачи к системному потоку, без выделения отдельного стека в ядре.
То есть это не "костыль поверх ОС", а второй уровень планирования, можно сказать надстройка, оптимизированная под модель массовой конкурентности без активных вычислений, когда тысячи задач делают что-то простое и ждут I/O.
По сути, виртуальные потоки это не попытка обойти ОС, а инструмент, чтобы JVM могла эффективно использовать ОС-потоки там, где обычная модель 1:1 перестает масштабироваться.
Спасибо за такой развернутый комментарий! Статья ориентирована на начинающих разработчиков, поэтому мы сознательно сильно не углублялись в технические детали и нюансы.
Отдельное спасибо за ссылки и дополнения — все по делу. Моменты, которые ты выделил жирным, абсолютно точные и, по сути, хорошо резюмируют главный посыл материала.
Пока — нет. И Log4j 2, и Logback остаются ThreadLocal-based для MDC/ThreadContext. «Новое» сегодня — контекст-пропагация (напр., Reactor 3.5 + Micrometer), которая переносит и поднимает MDC на время логирования. Это уменьшает боль, но не отменяет ограничения ThreadLocal. Параллельно в сообществах Log4j/SLF4J уже идут обсуждения перехода к ScopedValue/ScopedContext, но стабильных релизов «без ThreadLocal» пока нет.
Спасибо большое за отклик — особенно ценно услышать мнение от коллеги с похожим опытом из другой области.
С джунами действительно важно удерживать баланс: мягкость помогает выстроить доверие, но если ошибки повторяются или нарушаются договоренности — я стараюсь говорить строже, но при этом сохранять открытый диалог.
Спасибо, что подсветили тему развития — очень важная и точно достойна отдельного разговора.
Спасибо за интерес к статье и нашей команде :) Можешь отправить резюме на job@naumen.ru — мы сохраним твои контакты и свяжемся, как только появится подходящая вакансия.
Спасибо за вопрос! Это была задача от заказчика по ручному анализу и очистке входящих данных в Excel. Тогда автоматизировать подобные процессы не получалось, поэтому задача относилась к зоне ответственности бизнеса — нужно было хорошо разбираться в специфике данных в их сфере. Мне же нужно было работать уже с актуальными данными.
Оба подхода обладают своими плюсами и минусами, серебряной пули, к сожалению, не существует. EAV использовался в проектном решении этой задачи, но таблица разрастается довольно быстро, и это может начать создавать проблемы производительности.
Что касается JSONB, то под капотом в случае с Postgres используется именно он — как более эффективный.
Привет! Спасибо, что высказал интересную мысль :) Мы всегда открыты к новым идеям, так что ты можешь написать нам в Telegram @naumen_connect, сможем подробнее обсудить формат, который тебе кажется перспективным.
Добрый день! Конечно, посчитать точно возможности нет, всегда есть приближенные расчеты.
Мы считаем, что повлияли именно изменения в продукте, так как «соседний» продукт для внутренней поддержки не вырос настолько же в тех же условиях рынка, когда началось импортозамещение. При этом исторически видели, что оба продукта примерно одинаково реагировали на волнения на рынке.
Я не встречал методик по определению уровня неопределенности. Существуют методы оценки риска, да. Но это другое. Суть mindmap, о котором идет речь в статье (можно посмотреть здесь: https://miro.com/app/board/uXjVNEOGewU=/), чтобы иметь инструмент для определения составляющих (аспектов), по которым мы, возможно, не учли какие-то требования. И далее, что делать, чтобы выявить и формализовать эти требования.
Проблема в статье рассматривается не с точки зрения менеджмента, а с точки зрения результативности команды. Конечно, это более актуально, когда формат договора предполагает обоюдную ответственность для заказчика и исполнителя, как, например, в fixed price & fixed scope. А еще более значимо во внутренней разработке.
Оценить рамки неопределенности как раз и помогает mindmap. Чтобы было понятнее, вот ссылка: https://miro.com/app/board/uXjVNEOGewU=/. Чем раньше с его помощью получится понять, что есть «слепые зоны», тем лучше для всех.
Если кратко, то: первое — наши хорошо отлаженные процессы позволяют проводить подобные обновления, второе — как отметил в статье, каждое обновление приносит с собой и улучшение языка, и повышение безопасности и перформанса продукта из коробки.
Клиентоориентированность — общая тенденция. Сейчас она применяется почти везде. В проектном подходе мы ориентируемся на конкретного клиента, для которого реализуем проект. А в продуктовом — на большинство клиентов, имеющих схожие потребности.
Процессный подход относится к другой категории. То есть его некорректно сравнивать или противопоставлять продуктовому подходу, о котором говорим в статье.
Когда собеседник не знает/не понимает конечную цель или не может ее сформулировать, он отвечает простыми и понятными ему вещами — рутинными действиями. Я это называю «Я работаю, чтобы делать свою работу».
Для того, чтобы копнуть глубже, использую метод «5 почему». Приведу пример из жизни, который рассказывал своим коллегам:
— Я хочу купить машину.
— Зачем?
— Чтобы ездить.
— Куда ты собираешься на ней ездить?
— Я хочу ездить на ней на работу.
— Ты можешь добираться на автобусе или на метро, это быстрее и без пробок. Для чего машина?
— Утром я хочу выезжать пораньше, чтобы успевать отвозить детей в детский сад, который находится на другом конце города. Потом добираться до офиса. После работы забирать детей из детского сада и возвращаться пораньше, чтобы успеть к ужину, который приготовила жена, после провести время с ней. А еще вспомнил, что хочу иногда ездить на базу отдыха за городом и не быть привязанным к расписанию электричек.
В этом примере мы натыкаемся на умение формулировать цель действия — покупки машины. Мы получили ответ «действие». Затем задали второй уточняющий вопрос и все равно получили ответ в виде действия. Лишь на третьем вопросе, копнув глубже, мы получили развернутый ответ и узнали те цели, которые преследует собеседник.
В проектах автоматизации мы натыкаемся на аналогичные случаи. Например, заказчик просит сделать в задаче даты планового и фактического выполнения. Его мотивация на поверхности — хочу видеть, какие сотрудники вовремя выполняют задачи. Если начать копать зачем, почему, когда — мы выясним: что он хочет каждый день видеть, какие сотрудники не укладываются в срок и по каким задачам. В ходе диалога мы понимаем, что ему нужна не просто дата, а еще и ежедневный удобный отчет. Пользователь не знал, что мы можем быстро настроить ему выгрузку, поэтому опирался на свой прошлый опыт — визуально бы сравнивал в экселе.
Решили выделить роль администратора из-за большой нагрузки на РП. В ответственность РП входит все вами перечисленное.
Мы ведем как записи встреч, если это возможно, так и протоколы, которые чаще пишут администраторы. В протоколах фиксируем, какие вопросы обсуждали и какие решения приняли. Поэтому нить проекта РП не упускает. К тому же, РП сам может зафиксировать важные для себя моменты.
Подборку инструментов подготовили Катя и Арина — тестировщики из команды релизного тестирования SMRM.
Спасибо, что подметил! Все так, но в данном случае пример для демонстрации вложенности.
Контекст у виртуального потока есть, но он не системный. JVM сама хранит его как continuation — то есть просто состояние выполнения и стек в heap. Под него не создается отдельный поток или стек в ядре.
Спасибо за вдумчивый комментарий — вопрос действительно важный.
Вы правы: когда поток ОС блокируется на I/O, он действительно спит и не тратит CPU. Проблема не в расходе вычислительных ресурсов, а в количестве таких потоков.
ОС-поток — это дорогая вещь: для каждого нужно создать стек (обычно мегабайт), сохранить контекст, управлять переключениями, синхронизацией и т.д. Если у нас тысячи одновременных запросов, ожидающих ответ от БД или сети, то тысячи потоков ОС будут находиться в спящем состоянии, занимая память и ресурсы ядра. JVM, в свою очередь, вынуждена держать эти структуры и выполнять переключения при каждом пробуждении. Это и создает накладные расходы.
Виртуальные потоки решают не задачу "ожидания байтиков", а проблему масштабирования, то есть они позволяют иметь миллионы задач, ожидающих I/O, при этом переиспользуя ограниченное количество настоящих (carrier) потоков ОС. Планирование действительно реализовано в JVM, но оно легковесное: это просто привязка контекста задачи к системному потоку, без выделения отдельного стека в ядре.
То есть это не "костыль поверх ОС", а второй уровень планирования, можно сказать надстройка, оптимизированная под модель массовой конкурентности без активных вычислений, когда тысячи задач делают что-то простое и ждут I/O.
По сути, виртуальные потоки это не попытка обойти ОС, а инструмент, чтобы JVM могла эффективно использовать ОС-потоки там, где обычная модель 1:1 перестает масштабироваться.
Под "полноценный поток операционной системы" подразумевается "объект Thread отображается один к одному на поток операционной системы"
Спасибо за такой развернутый комментарий! Статья ориентирована на начинающих разработчиков, поэтому мы сознательно сильно не углублялись в технические детали и нюансы.
Отдельное спасибо за ссылки и дополнения — все по делу. Моменты, которые ты выделил жирным, абсолютно точные и, по сути, хорошо резюмируют главный посыл материала.
Пока — нет. И Log4j 2, и Logback остаются ThreadLocal-based для MDC/ThreadContext. «Новое» сегодня — контекст-пропагация (напр., Reactor 3.5 + Micrometer), которая переносит и поднимает MDC на время логирования. Это уменьшает боль, но не отменяет ограничения ThreadLocal. Параллельно в сообществах Log4j/SLF4J уже идут обсуждения перехода к ScopedValue/ScopedContext, но стабильных релизов «без ThreadLocal» пока нет.
Спасибо большое за отклик — особенно ценно услышать мнение от коллеги с похожим опытом из другой области.
С джунами действительно важно удерживать баланс: мягкость помогает выстроить доверие, но если ошибки повторяются или нарушаются договоренности — я стараюсь говорить строже, но при этом сохранять открытый диалог.
Спасибо, что подсветили тему развития — очень важная и точно достойна отдельного разговора.
Спасибо за интерес к статье и нашей команде :) Можешь отправить резюме на job@naumen.ru — мы сохраним твои контакты и свяжемся, как только появится подходящая вакансия.
Спасибо за вопрос! Это была задача от заказчика по ручному анализу и очистке входящих данных в Excel. Тогда автоматизировать подобные процессы не получалось, поэтому задача относилась к зоне ответственности бизнеса — нужно было хорошо разбираться в специфике данных в их сфере. Мне же нужно было работать уже с актуальными данными.
Оба подхода обладают своими плюсами и минусами, серебряной пули, к сожалению, не существует. EAV использовался в проектном решении этой задачи, но таблица разрастается довольно быстро, и это может начать создавать проблемы производительности.
Что касается JSONB, то под капотом в случае с Postgres используется именно он — как более эффективный.
Привет! Спасибо, что высказал интересную мысль :) Мы всегда открыты к новым идеям, так что ты можешь написать нам в Telegram @naumen_connect, сможем подробнее обсудить формат, который тебе кажется перспективным.
Добрый день! Конечно, посчитать точно возможности нет, всегда есть приближенные расчеты.
Мы считаем, что повлияли именно изменения в продукте, так как «соседний» продукт для внутренней поддержки не вырос настолько же в тех же условиях рынка, когда началось импортозамещение. При этом исторически видели, что оба продукта примерно одинаково реагировали на волнения на рынке.
Я не встречал методик по определению уровня неопределенности. Существуют методы оценки риска, да. Но это другое. Суть mindmap, о котором идет речь в статье (можно посмотреть здесь: https://miro.com/app/board/uXjVNEOGewU=/), чтобы иметь инструмент для определения составляющих (аспектов), по которым мы, возможно, не учли какие-то требования. И далее, что делать, чтобы выявить и формализовать эти требования.
Проблема в статье рассматривается не с точки зрения менеджмента, а с точки зрения результативности команды. Конечно, это более актуально, когда формат договора предполагает обоюдную ответственность для заказчика и исполнителя, как, например, в fixed price & fixed scope. А еще более значимо во внутренней разработке.
Оценить рамки неопределенности как раз и помогает mindmap. Чтобы было понятнее, вот ссылка: https://miro.com/app/board/uXjVNEOGewU=/. Чем раньше с его помощью получится понять, что есть «слепые зоны», тем лучше для всех.
Да, верно, изначально в коде этой строки не было, видимо, при публикации что-то слетело. Спасибо за внимательность, поправили!
Если кратко, то: первое — наши хорошо отлаженные процессы позволяют проводить подобные обновления, второе — как отметил в статье, каждое обновление приносит с собой и улучшение языка, и повышение безопасности и перформанса продукта из коробки.
В финальной части доклада на ютубе более подробно рассказал, почему полезно обновление.
Клиентоориентированность — общая тенденция. Сейчас она применяется почти везде. В проектном подходе мы ориентируемся на конкретного клиента, для которого реализуем проект. А в продуктовом — на большинство клиентов, имеющих схожие потребности.
Процессный подход относится к другой категории. То есть его некорректно сравнивать или противопоставлять продуктовому подходу, о котором говорим в статье.
Когда собеседник не знает/не понимает конечную цель или не может ее сформулировать, он отвечает простыми и понятными ему вещами — рутинными действиями. Я это называю «Я работаю, чтобы делать свою работу».
Для того, чтобы копнуть глубже, использую метод «5 почему». Приведу пример из жизни, который рассказывал своим коллегам:
— Я хочу купить машину.
— Зачем?
— Чтобы ездить.
— Куда ты собираешься на ней ездить?
— Я хочу ездить на ней на работу.
— Ты можешь добираться на автобусе или на метро, это быстрее и без пробок. Для чего машина?
— Утром я хочу выезжать пораньше, чтобы успевать отвозить детей в детский сад, который находится на другом конце города. Потом добираться до офиса. После работы забирать детей из детского сада и возвращаться пораньше, чтобы успеть к ужину, который приготовила жена, после провести время с ней. А еще вспомнил, что хочу иногда ездить на базу отдыха за городом и не быть привязанным к расписанию электричек.
В этом примере мы натыкаемся на умение формулировать цель действия — покупки машины. Мы получили ответ «действие». Затем задали второй уточняющий вопрос и все равно получили ответ в виде действия. Лишь на третьем вопросе, копнув глубже, мы получили развернутый ответ и узнали те цели, которые преследует собеседник.
В проектах автоматизации мы натыкаемся на аналогичные случаи. Например, заказчик просит сделать в задаче даты планового и фактического выполнения. Его мотивация на поверхности — хочу видеть, какие сотрудники вовремя выполняют задачи. Если начать копать зачем, почему, когда — мы выясним: что он хочет каждый день видеть, какие сотрудники не укладываются в срок и по каким задачам. В ходе диалога мы понимаем, что ему нужна не просто дата, а еще и ежедневный удобный отчет. Пользователь не знал, что мы можем быстро настроить ему выгрузку, поэтому опирался на свой прошлый опыт — визуально бы сравнивал в экселе.
Решили выделить роль администратора из-за большой нагрузки на РП. В ответственность РП входит все вами перечисленное.
Мы ведем как записи встреч, если это возможно, так и протоколы, которые чаще пишут администраторы. В протоколах фиксируем, какие вопросы обсуждали и какие решения приняли. Поэтому нить проекта РП не упускает. К тому же, РП сам может зафиксировать важные для себя моменты.