Я немного искал сайт, чтобы понять его, но не нашел ничего очень ясного, поэтому решил опубликовать свой вариант использования и посмотреть, сможет ли кто-нибудь пролить свет.

У меня есть вопрос о масштабировании потоков jvm против потоков os при использовании в akka для операций io. С сайта Акка:

Akka поддерживает диспетчеры как для облегченных потоков, управляемых событиями, что позволяет создавать миллионы потоков на одной рабочей станции, так и для субъектов на основе потоков, где каждый диспетчер связан с выделенным потоком ОС.

Актеры, основанные на событиях, в настоящее время потребляют ~ 600 байт на каждого актера, что означает, что вы можете создать более 6,5 миллионов акторов в 4 ГБ ОЗУ.

В этом контексте вы можете помочь мне понять, как это работает на рабочей станции с одним процессором (для простоты). Итак, для моего примера использования я хочу взять список, скажем, 1000 «Пользователи», а затем перейти к базе данных (или нескольким) для получения различной информации о каждом пользователе. Так что, если бы я отправил каждую из этих задач 'get' актеру, и этот актер будет выполнять IO, разве этот блок актора не будет основан на ограничении потока os для рабочей станции?

Как модель актера Акка помогает мне в таком сценарии? Я знаю, что я, вероятно, что-то упускаю, потому что я не очень разбираюсь во взаимодействии потоков vm с потоками os, поэтому, если бы один из умных людей здесь мог объяснить это мне, это было бы здорово.

Если я использую Futures, не нужно ли использовать await () или get (), чтобы заблокировать и ждать ответа?

В моем случае использования, независимо от действующих лиц, получилось бы просто «ощущение», будто я делаю 1000 последовательных запросов к базе данных?

Если фрагменты кода полезны, чтобы помочь мне понять это, предпочтение будет отдано Java, так как я все еще быстро разбираюсь в синтаксисе scala - но хорошее четкое текстовое объяснение того, как эти миллионы потоков могут взаимодействовать на однопроцессорной машине при выполнении ввода-вывода базы данных было бы тоже хорошо.