Блокирующий код, заключенный внутри Akka Future, также блокирует поток, поддерживаемый Future, тогда как будущее полезно в этом случае

Question

Философия, лежащая в основе Akka/Scala Future, заключается в том, что когда мы находим блокирующую часть кода, такую ​​как вызов IO, сетевой вызов и т. д. мы должны завершить его в будущем и асинхронно получить результат через некоторый момент времени. Но блокирующая часть кода, которая ранее блокировала основной поток, теперь блокирует в отдельном потоке, в котором поддерживается будущее. то, что Akka/Scala Future покупали нас.

val blockingCallResult: Result = block() //blocks the thread of execution. 

now let's use Akka/Scala future and wrap the blocking call with Future 


val future = Future[Result] { 

    val blockingCallResult: Result = block() //also blocks on some thread in thread pool 

    blockingCallResult 

} 

Как мы получаем выгоду от использования будущего.

Answer 1

Если у вас есть только один контекст выполнения, и вы используете только фьючерсы, которые выполняют блокирующий код, и только по одному, то, действительно, нет никакого преимущества от использования будущего. Преимущества фьючерсов:

• Параллельность - на многоядерной машине одновременно могут выполняться несколько потоков. Использование фьючерсов с контекстом выполнения позволяет избежать накладных расходов на создание нового потока для каждого действия или повторное использование потоков вручную, а контекст выполнения дает вам контроль над размером пула.
• Разделение ввода-вывода и вычисление потоков с использованием различных контекстов выполнения. Это позволяет ядру планировать интерактивные ответы на ввод-вывод перед долговременными вычислительными задачами, улучшая латентность.
• Истинный асинхронный ввод-вывод, например. scala-redis-nb (или Netty или ReactiveMongo (?)). Вместо того, чтобы будущее было потоком, который блокируется, можно выставить асинхронный API (тип, который в противном случае мог бы использовать обратные вызовы) с использованием Futures (например, через Promises), а затем вы можете написать действительно асинхронный код, который позволяет избежать блокировки любых потоков I/O и с гораздо более удобным API, чем напрямую с помощью API-интерфейса, основанного на обратном вызове.