scala - 为什么阻止 future 被认为是一种不好的做法？

Question

我试图理解声明背后的理性
For cases where blocking is absolutely necessary, futures can be blocked on (although it is discouraged)

背后的想法ForkJoinPool是加入阻塞操作的进程，这是 future 和参与者的执行者上下文的主要实现。它应该对阻止连接有效。

我写了一个小基准，在这个非常简单的场景中，旧式 future (scala 2.9)似乎快了 2 倍。

@inline
  def futureResult[T](future: Future[T]) = Await.result(future, Duration.Inf)

  @inline
  def futureOld[T](body: => T)(implicit  ctx:ExecutionContext): () => T = {
    val f = future(body)
    () => futureResult(f)
  }

  def main(args: Array[String]) {
    @volatile

    var res = 0d
    CommonUtil.timer("res1") {
      (0 until 100000).foreach {  i =>
       val f1 = futureOld(math.exp(1))
        val f2 = futureOld(math.exp(2))
        val f3 = futureOld(math.exp(3))
        res = res + f1() + f2() + f3()
      }
    }
    println("res1 = "+res)
    res = 0

    res = 0
    CommonUtil.timer("res1") {
      (0 until 100000).foreach {  i =>
        val f1 = future(math.exp(1))
        val f2 = future(math.exp(2))
        val f3 = future(math.exp(3))
        val f4 = for(r1 <- f1; r2 <- f2 ; r3 <- f3) yield r1+r2+r3
        res = res + futureResult(f4)
      }
    }
    println("res2 = "+res)
  }



start:res1
res1 - 1.683 seconds
res1 = 3019287.4850644027
start:res1
res1 - 3.179 seconds
res2 = 3019287.485058338

Answer 1

Futures 的大部分要点在于，它们使您能够创建可以轻松并行执行的非阻塞并发代码。

好的，所以在 future 包装一个可能很长的函数会立即返回，这样您就可以推迟担心返回值，直到您真正对它感兴趣。但是，如果代码中关心值的部分只是在结果实际可用之前阻塞，那么您所获得的只是一种使代码更整洁的方法(而且您知道，您可以在没有 future 的情况下做到这一点 - 使用 future 来整理你的代码会是一种代码味道，我认为)。除非封装在 future 中的函数绝对是微不足道的，否则您的代码将比评估其他表达式花费更多的时间进行阻塞。

另一方面，如果您注册一个回调(例如使用 onComplete 或 onSuccess )并在该回调中放入关心结果的代码，那么您可以拥有可以被组织起来以非常有效地运行并很好地扩展。它变成了事件驱动，而不必坐等结果。

您的基准测试属于前一种类型，但由于您在那里有一些小函数，与按顺序执行它们相比，并行执行它们之间的 yield 很小。这意味着您主要评估创建和访问 future 的开销。恭喜:你表明在某些情况下 2.9 future 在做一些微不足道的事情上比 2.10 更快——一些微不足道的事情并不能真正发挥任何一个版本的概念的优势。

尝试一些更复杂和要求更高的事情。我的意思是，您几乎立即请求 future 值!至少，您可以构建一个包含 100000 个 future 的数组，然后在另一个循环中提取它们的结果。那将是测试一些稍微有意义的东西。哦，让他们根据 的值计算一些东西我 .

你可以从那里进步到

创建一个对象来存储结果。

向每个将结果插入对象的 future 注册一个回调。

启动您的 n 个计算

然后当您要求所有结果时，对实际结果到达所需的时间进行基准测试。那会更有意义。

编辑

顺便说一下，您的基准测试在其自身条件和对正确使用 future 的理解上都失败了。

首先，您计算的是检索每个 future 结果所需的时间，而不是计算 所需的实际时间。资源 一旦创建了所有 3 个 future ，也不是迭代循环所需的总时间。此外，您的数学计算是如此微不足道，以至于您实际上可能正在测试 a) 理解和 b) 包含前三个 future 的第四个 future 的第二个测试中的惩罚。

其次，这些总和可能与使用的总时间大致成正比的唯一原因正是因为这里确实没有并发。

我不是要打击你，只是基准测试中的这些缺陷有助于说明问题。不同 future 实现的性能的适当基准需要非常仔细的考虑。