Как тяжелые Java-потоки по сравнению с Scala/акками Akka? - программирование
Подтвердить что ты не робот

Как тяжелые Java-потоки по сравнению с Scala/акками Akka?

Я просто сравнивал производительность scala актеров против java-потоков.

Я был поражен, увидев разницу, я заметил, что с моей системой я смог создать максимум ~ 2000 потоков (только за один раз). Но с той же системой я смог создать ~ 500 000 участников scala,

Обе программы используют около 81 Мбайт кучной памяти JVM.

Можете ли вы объяснить, насколько поток java намного тяжелее, чем актеры scala/akka? Каков ключевой фактор, который сделал scala -актив этого очень легкого веса?

Если я хочу достичь наилучшей масштабируемости, должен ли я перейти на веб-сервер, основанный на актерах, вместо традиционного веб-сервера приложений или Java, например JBoss или Tomcat?

Спасибо.

4b9b3361

ОТВЕТЫ

Ответ 1

Scala актеры (включая сорт Akka) используют потоки Java. Там нет магии: более нескольких тысяч потоков, работающих одновременно, является проблемой для большинства настольных компьютеров.

Модель Actor позволяет актерам с активными действиями, которые не занимают нить, если у них нет работы. Некоторые проблемы могут быть эффективно смоделированы, так как многие спящие ждут, чтобы получить какую-то работу, кто сделает это относительно быстро, а затем снова заснет. В этом случае актеры - очень эффективный способ использовать потоки Java для выполнения вашей работы, особенно если у вас есть библиотека, такая как Akka, где производительность была высокоприоритетной.

Akka docs хорошо объясняют основы.

Все достаточно масштабируемые веб-серверы должны решать такую ​​проблему так или иначе; вы, вероятно, не должны основывать свое решение на веб-сервере в первую очередь на том, используются ли актеры под капотом, и независимо от того, что вы используете, вы всегда можете добавлять актеров самостоятельно.

Ответ 2

Акк Акка не эквивалентен нитке. Это больше похоже на Callable, который выполняется в threadpool.

Когда сообщение отправляется актеру, этот актер помещается в threadpool для обработки сообщения. Когда это будет сделано, объединенный поток может использоваться для выполнения других участников.