Спасибо. Еще вопрос - при создании виртуальных потоков выделяется контекст? Навскидку - ну раньше выделялась память на контекст в ОС средствами процессора (или ОС?), сейчас память выделяется на каждую задачу в JVM.
Мне вот хочется объяснения у специалистов. Автор пишет
простаивает на долгих I/O‑операциях, например, при обращениях к базе данных, по сети: поток «ждет байтики», занимая OS‑поток и ничего не делая.
В чем проблема? Из книг Рихтера, Таненбаума я знаю, что работа с потоками организована на уровне процессора: поток выполняется, уходит в спящий режим, выводится из спящего режима. Когда код отправляет запрос на I/O, он средствами windows отправляет поток в спящий режим. При этом ставится семафор (или что-то подобное, если я не ошибаюсь). При этом процессор НЕ ВЫПОЛНЯЕТ команды в этом потоке, то есть, вычислительные ресурсы НЕ ТРАТЯТСЯ. Когда оборудование выполнит I/O и загрузит данные в память (если я не ошибаюсь, даже без участия процессора), оно дает сигнал прерывания. ОС ловит этот сигнал и возобновляет выполнение потока. Далее этот поток снова начинает участвовать в карусели и получает толику процессорного времени.
Читая статьи по виртуальным потокам и глядя на картиночки, складывается впечатление, что авторы полагают, что поток "ждет байтики и ничего не делает" следующим образом: впадает в цикл и бесконечно опрашивает какую-то переменную в памяти "когда-же, когда-же?". Но ведь это не так?
Организация с потоками ОС сделана на уровне процессора, то есть, по-идее - быстро, эффективно, чисто, надежно. Организация виртуальных потоков - на уровне кода JVM, то есть, это какая-то надстройка, прорва кода, планировщиков, то есть лишние затраты процессора, ненадежность, какие-то костыли. Разве не так?
Второе замечание.
Как правильно сделал вывод автор, практически единственная сфера деательности виртуальных потоков, где они показывают результат - это кейс сервера, обрабатывающего небольшие запросы от клиентов. Проанализировав этот кейс, приходишь к выводу, что фактически, система виртуальных потоков создает очередь запросов, отлавливает tcp-запросы, складывает в очередь, а затем планировщик виртуальных "потоков" натравливает два-четыре потока ОС для выполнения этих задач по порядку из очереди. И это работает, да. Вместо создания тысяч потоков работают четыре-восемь, без перегрузки ОС, без чудовищного разбухания карусели потоков, и соответственно, без голодания остальными потоками приложений и ОС, без возможных блокировок и гонок. Прекрасно. Но данная задача сервис-клиенты решена, скажем так, через ж..., имхо. Не лучше ли ЯВНО решить задачу обработки запросов, через слушатель, очередь запросов и несколько воркеров?
Если вы администратор бизнес-приложений, попробуйте двигаться в сторону аналитики и интегратора. Программистов-быдлокодеров много, а людей, понимающих как работает бизнес и приложения - очень мало.
Загрузка данных, связь приложений друг с другом - вот, что нужно.
Перескочите через этап быдлокодинга (есть шанс застрять там на всю жизнь), предложите услуги более высокого уровня.
А что, для всех убийц "not awailable"? Или некоторые убийцы кого надо убийцы?
Если вы покажете (и докажете), что для ВСЕХ убийц not awailable, а не так, что для некоторых - not awailable (мы все понимаем, для каких), а для некоторых - ок (мы все понимаем, для каких) - то тогда можно продолжать, если же нет (а мы все понимаем, что нет), то тогда вопрос в национальности, и этот тред можно преращать.
С определенной даты (мы все знаем, с какой) у вас нет морального права говорить про "убийц" в контектсе кидалова netflix (и прочих западных компаний) читателей Хабра.
Чем этот StableValue отличается от ломбокоской lazy? Если реализация - только еще один библиотечный класс, работающий на обычной java, то зачем все это?
Чем Jep-овская приблуда лучше этого кода?
public static class PetClientController {
@Getter(lazy = true)
private final JavaMailSender javaMailSender = new JavaMailSenderImpl();
public void adoptPet(SecurityProperties.User user, Object pet) {
//...
getJavaMailSender().send(new MimeMessage(...));
}
}
Теория игр говорит, что при выборе решения нужно выбирать решение, при котором возможный проигрыш минимальный, а не то решение, при котором выигрыш максимальный.
Если мы выберем запретить ИИ - какие возможные выигрыш и проигрыш - выигрыш - медленное развитие человечества, излечение от всех болезней, расселение по всем планетам через тысячи лет, проигрыш - медленное угасание человечества. Если выберем использовать ИИ, выигрыш - излечивание всех болезней, автоматизация, генетическое преобразование человека, возможно, расселение по планетам, причем за срок порядка столения. Проигрыш при этом - уничтожение человечества, причем за годы.
Я вчера Луну-то снять не мог во время лунного затмения. Глазами прекрасно видно, в бинокль отлично видно (кратеры разглядывал). В телефоне вообще ничего не видно.
Ночью темный объект, пусть с огнями или контуром, как у комментатора выше, просто не отобразится в телефоне.
То-ли пример неверный, то ли еще что. Интеграционные тесты предназначены только для одного - тестирования интеграции - сиречь для того, чтобы проверить, что вилка с розеткой правильно спроектированы и изготовлены.
Я вижу, что тестконтейнеры хороши, когда начинаешь писать тесты в унаследованный проект, где обращение к сторонним сервисам, вроде бд, производится прямо в нижних методах. Выбрали из базы - посчитали что-то - сохранили в базу - выбрали из базы - посчитали - сохранили в базу - закончили упражнение. Такие классы не проюнитишь без серьезного перелопачивания.
Правильное решение для такого кейса - сохранеие адреса выделяется в отдельный класс. В него инжектится датасурс к базе. userService.registerUser - такого быть не должно. Репозиторий должен делать только getUser и saveUser. getUser должен просто возвращать или null, или пользователя по верхнему регистру с идентификатором. saveUser - просто создавать или апдейтить пользователя. В базе должно быть два поля - как есть, и верхнем регистре (можно сделать индекс с верхним регистром и запрос делать UPPER(user) = :user). Никаких проверок и ошибок он не должен возвращать. Это simple объект. Проверка должна осуществляться в бизнес-классе (UserService). В нем из входа приводится к верхнему регистру, обращается к датасурсу, если есть - выбрасывается исключение, если нет - делается вызов saveUser. Этот класс и метод отлично юнит-тестится.
Тестконтейнеры приходится (ПРИХОДИТСЯ!) применять в случае унаследованной системы, также когда часть логики в процедурах или сторонних системах, и на нее завязана тестируемая функциональность.
Более того, я считаю, тестконтейнеры ВРЕДЯТ организации, поскольку вместо правильного разделения слоев, поощряют писать код-лапшу, в котором не применяется DI, не используется в полную мощь Spring, и обращения к сторонним сервисам производится на самых нижних уровнях. Такой бардак обязательно выйдет боком. Не говоря о том, что производительность тесконтейнеров, в отличии от юнит, ужасная - процесс разработки просто или встанет, потому что билд с тестами будет делаться по полчаса-час, либо их просто отключат.
Спасибо. Еще вопрос - при создании виртуальных потоков выделяется контекст? Навскидку - ну раньше выделялась память на контекст в ОС средствами процессора (или ОС?), сейчас память выделяется на каждую задачу в JVM.
Мне вот хочется объяснения у специалистов. Автор пишет
простаивает на долгих I/O‑операциях, например, при обращениях к базе данных, по сети: поток «ждет байтики», занимая OS‑поток и ничего не делая.
В чем проблема? Из книг Рихтера, Таненбаума я знаю, что работа с потоками организована на уровне процессора: поток выполняется, уходит в спящий режим, выводится из спящего режима. Когда код отправляет запрос на I/O, он средствами windows отправляет поток в спящий режим. При этом ставится семафор (или что-то подобное, если я не ошибаюсь). При этом процессор НЕ ВЫПОЛНЯЕТ команды в этом потоке, то есть, вычислительные ресурсы НЕ ТРАТЯТСЯ. Когда оборудование выполнит I/O и загрузит данные в память (если я не ошибаюсь, даже без участия процессора), оно дает сигнал прерывания. ОС ловит этот сигнал и возобновляет выполнение потока. Далее этот поток снова начинает участвовать в карусели и получает толику процессорного времени.
Читая статьи по виртуальным потокам и глядя на картиночки, складывается впечатление, что авторы полагают, что поток "ждет байтики и ничего не делает" следующим образом: впадает в цикл и бесконечно опрашивает какую-то переменную в памяти "когда-же, когда-же?". Но ведь это не так?
Организация с потоками ОС сделана на уровне процессора, то есть, по-идее - быстро, эффективно, чисто, надежно. Организация виртуальных потоков - на уровне кода JVM, то есть, это какая-то надстройка, прорва кода, планировщиков, то есть лишние затраты процессора, ненадежность, какие-то костыли. Разве не так?
Второе замечание.
Как правильно сделал вывод автор, практически единственная сфера деательности виртуальных потоков, где они показывают результат - это кейс сервера, обрабатывающего небольшие запросы от клиентов. Проанализировав этот кейс, приходишь к выводу, что фактически, система виртуальных потоков создает очередь запросов, отлавливает tcp-запросы, складывает в очередь, а затем планировщик виртуальных "потоков" натравливает два-четыре потока ОС для выполнения этих задач по порядку из очереди. И это работает, да. Вместо создания тысяч потоков работают четыре-восемь, без перегрузки ОС, без чудовищного разбухания карусели потоков, и соответственно, без голодания остальными потоками приложений и ОС, без возможных блокировок и гонок. Прекрасно. Но данная задача сервис-клиенты решена, скажем так, через ж..., имхо. Не лучше ли ЯВНО решить задачу обработки запросов, через слушатель, очередь запросов и несколько воркеров?
Слишком поспешно и оптимистично.
Если вы администратор бизнес-приложений, попробуйте двигаться в сторону аналитики и интегратора. Программистов-быдлокодеров много, а людей, понимающих как работает бизнес и приложения - очень мало.
Загрузка данных, связь приложений друг с другом - вот, что нужно.
Перескочите через этап быдлокодинга (есть шанс застрять там на всю жизнь), предложите услуги более высокого уровня.
А что, для всех убийц "not awailable"? Или некоторые убийцы кого надо убийцы?
Если вы покажете (и докажете), что для ВСЕХ убийц not awailable, а не так, что для некоторых - not awailable (мы все понимаем, для каких), а для некоторых - ок (мы все понимаем, для каких) - то тогда можно продолжать, если же нет (а мы все понимаем, что нет), то тогда вопрос в национальности, и этот тред можно преращать.
С определенной даты (мы все знаем, с какой) у вас нет морального права говорить про "убийц" в контектсе кидалова netflix (и прочих западных компаний) читателей Хабра.
Надо соблюдать Трудовое законодательство.
Они и в цехе любого производство мастера тем-же самым занимаются. Собачья работа.
Честно говоря, автор идеалист, и занимался чепухой.
Этот "Эффект манделы" разве что в головах зумеров.
Чем этот StableValue отличается от ломбокоской lazy? Если реализация - только еще один библиотечный класс, работающий на обычной java, то зачем все это?
Чем Jep-овская приблуда лучше этого кода?
Теория игр говорит, что при выборе решения нужно выбирать решение, при котором возможный проигрыш минимальный, а не то решение, при котором выигрыш максимальный.
Если мы выберем запретить ИИ - какие возможные выигрыш и проигрыш - выигрыш - медленное развитие человечества, излечение от всех болезней, расселение по всем планетам через тысячи лет, проигрыш - медленное угасание человечества. Если выберем использовать ИИ, выигрыш - излечивание всех болезней, автоматизация, генетическое преобразование человека, возможно, расселение по планетам, причем за срок порядка столения. Проигрыш при этом - уничтожение человечества, причем за годы.
Делайте выводы.
Больше всего удар по бойлерплейт нанес record. С ним почти все фичи ломбока можно запретить.
Годный материал.
"Эксперимент" - как пример того, когда неспециалист, психолог, биолог-недоучка, проектирует эксперимент над животными.
Пример: "Руководители часто винят регулирование или недостаточную производительность моделей ".
Если какая-то деятельность противоречит пусть даже всем мировым (кстати, какие еще есть?) религиям, это не делает ее пустой тратой времени и денег.
Россияне проголосовали за РФ, американцы бы проголосовали за США. Не вижу проблемы.
Я вчера Луну-то снять не мог во время лунного затмения. Глазами прекрасно видно, в бинокль отлично видно (кратеры разглядывал). В телефоне вообще ничего не видно.
Ночью темный объект, пусть с огнями или контуром, как у комментатора выше, просто не отобразится в телефоне.
Вы переоцениваете возможности телефонов.
То-ли пример неверный, то ли еще что. Интеграционные тесты предназначены только для одного - тестирования интеграции - сиречь для того, чтобы проверить, что вилка с розеткой правильно спроектированы и изготовлены.
Я вижу, что тестконтейнеры хороши, когда начинаешь писать тесты в унаследованный проект, где обращение к сторонним сервисам, вроде бд, производится прямо в нижних методах. Выбрали из базы - посчитали что-то - сохранили в базу - выбрали из базы - посчитали - сохранили в базу - закончили упражнение. Такие классы не проюнитишь без серьезного перелопачивания.
Правильное решение для такого кейса - сохранеие адреса выделяется в отдельный класс. В него инжектится датасурс к базе.
userService.registerUser - такого быть не должно. Репозиторий должен делать только getUser и saveUser. getUser должен просто возвращать или null, или пользователя по верхнему регистру с идентификатором. saveUser - просто создавать или апдейтить пользователя. В базе должно быть два поля - как есть, и верхнем регистре (можно сделать индекс с верхним регистром и запрос делать UPPER(user) = :user). Никаких проверок и ошибок он не должен возвращать. Это simple объект. Проверка должна осуществляться в бизнес-классе (UserService). В нем из входа приводится к верхнему регистру, обращается к датасурсу, если есть - выбрасывается исключение, если нет - делается вызов saveUser. Этот класс и метод отлично юнит-тестится.Тестконтейнеры приходится (ПРИХОДИТСЯ!) применять в случае унаследованной системы, также когда часть логики в процедурах или сторонних системах, и на нее завязана тестируемая функциональность.Более того, я считаю, тестконтейнеры ВРЕДЯТ организации, поскольку вместо правильного разделения слоев, поощряют писать код-лапшу, в котором не применяется DI, не используется в полную мощь Spring, и обращения к сторонним сервисам производится на самых нижних уровнях. Такой бардак обязательно выйдет боком. Не говоря о том, что производительность тесконтейнеров, в отличии от юнит, ужасная - процесс разработки просто или встанет, потому что билд с тестами будет делаться по полчаса-час, либо их просто отключат.Надо просто создать условия на Земле ХУЖЕ, чем... погодите-ка...
И у светодиодных ламп?
Какие открытия в фундаментальной науке сделал Китай за последние 50 лет?