Есть carrier-threads(настоящий поток ОС), в котором может быть много виртуальных потоков. Виртуальные потоки не держат стек в памяти ОС, их стек хранится в куче и выделяется динамически.
На уровне JVM есть планировщик виртуальных потоков. Он управляет тем, какой виртуальный поток монтировать на какой carrier-thread. Планировщик использует FIFO-очередь (First-In-First-Out) для ожидания выполнения задач на carrier-thread. Также же еще весь сок в том, что виртуальные потоки полностью совместимы со старым апи, то есть как раз и экзекуторы, симафоры и т.д)
Спасибо за комментарий, рад, что вам понравилась статья)
Да, дублирование возможно, но это не баг кода, а ограничение стандартного outbox-подхода без Kafka transactions. Понятно, что такое может случится и мы действительно пошлем сообщение 2 раза. Я писал, что показал самую дефолтную реализацию. Но про питание и OOM можно много где написать, что нет защиты. Но как часто у вас были такие примеры, что выдернули шнур? OOM можно стабилизировать кол-вом записей, которые мы достаем. Есть еще практика выделять шедулеры или консюмеры в отдельные инстансы, чтобы они работали независимо.
Как по мне подход к решению проблем, которые вы описали это больше комплексный подход всего проекта, а не конкретного стартера)
Все собесы разные, у меня был такой, бывают, конечно, собесы гораздо сложнее.
Зачастую все основные вопросы и понимание у собеседуего приходит на систем дизайне, как по мне, там и доп вопросы и почему так и зачем, вот там и раскрывается человек)
Примерно 0 в моей практике)) обычно ты приходишь и за тебя уже все настроено, а именно выбор GC стоит очень редко, обычно дефолтный покрывает все, что нужно, за редким исключением
Можно просто скопировать откуда угодно)) я так делаю, пишешь в гугле имодзи, и сейчас можно просто тыкнуть правой кнопкой и там будут эмодзи, на винде 11 + Яндекс браузере работает)
Привет, рад, что вам понравилось)
LookUp правильный и гарантированный способ получать новый prototype каждый раз)
/
Рад, что вам понравилось)
Если я не ошибаюсь основная причина, почему их назвали виртуальными потоками: обеспечить полную совместимость с существующим API потоков в Java)
Есть carrier-threads(настоящий поток ОС), в котором может быть много виртуальных потоков.
Виртуальные потоки не держат стек в памяти ОС, их стек хранится в куче и выделяется динамически.
На уровне JVM есть планировщик виртуальных потоков. Он управляет тем, какой виртуальный поток монтировать на какой carrier-thread.
Планировщик использует FIFO-очередь (First-In-First-Out) для ожидания выполнения задач на carrier-thread.
Также же еще весь сок в том, что виртуальные потоки полностью совместимы со старым апи, то есть как раз и экзекуторы, симафоры и т.д)
Спасибо за комментарий, рад, что вам понравилась статья)
Да, дублирование возможно, но это не баг кода, а ограничение стандартного outbox-подхода без Kafka transactions. Понятно, что такое может случится и мы действительно пошлем сообщение 2 раза. Я писал, что показал самую дефолтную реализацию.
Но про питание и OOM можно много где написать, что нет защиты. Но как часто у вас были такие примеры, что выдернули шнур?
OOM можно стабилизировать кол-вом записей, которые мы достаем. Есть еще практика выделять шедулеры или консюмеры в отдельные инстансы, чтобы они работали независимо.
Как по мне подход к решению проблем, которые вы описали это больше комплексный подход всего проекта, а не конкретного стартера)
Спасибо за комментарий)
Раньше бывало по 2 собеса в день, сейчас же, из-за ситуации на рынке, такое редкость)
А у нас всегда называли так, у всех свое, видимо))
Что-то я не могу найти где это в статье, вроде и прошелся еще раз))
Возможно вы и правы, спасибо вам за комментарий)
Ваше мнение
Если будут одинаковые имена, то группировка по айди не даст 1 запись, а несколько, по каждому клиенту)
Мне доказывать нечего, да и не нужно, я просто делюсь своим опытом))
Вам же спасибо, что следите за мной, мне очень приятно)))
Все собесы разные, у меня был такой, бывают, конечно, собесы гораздо сложнее.
Зачастую все основные вопросы и понимание у собеседуего приходит на систем дизайне, как по мне, там и доп вопросы и почему так и зачем, вот там и раскрывается человек)
Я же рассказал свой реальный опыт)
У меня в профиле есть разбор целого собеса)
Но сейчас рынок очень тухлый, зовут редко куда-то (
Это была опечатка, спасибо большое, так да, там count
Спасибо, да, вы правы, я не совсем корректно выразился, спасибо)
Примерно 0 в моей практике)) обычно ты приходишь и за тебя уже все настроено, а именно выбор GC стоит очень редко, обычно дефолтный покрывает все, что нужно, за редким исключением
Профайлер вообще имба, выручал не один раз))
Наверное как и большинство разработчиков, пока не будет с ними проблем - никто не задумывается)))
Можно просто скопировать откуда угодно)) я так делаю, пишешь в гугле имодзи, и сейчас можно просто тыкнуть правой кнопкой и там будут эмодзи, на винде 11 + Яндекс браузере работает)
Согласен с вами, тут самый частый вариант это именно битье)