我知道 Scala Future 变得更好的很多原因。有什么理由改用 Twitter Future 吗?除了 Finagle 使用它的事实。
2 回答
免责声明:我曾在 Twitter 从事 Future 的实施工作。一点上下文,我们在 Scala 有一个“好的”实现之前就开始了我们自己的实现Future
。
以下是 Twitter 的功能Future
:
- 一些方法名称不同,Twitter 的
Future
配套中有一些新的辅助方法。
例如,仅举一个例子:Future.join(f1, f2)
可以处理异构的 Future 类型。
Future.join(
Future.value(new Object), Future.value(1)
).map {
case (o: Object, i: Int) => println(o, i)
}
o
并i
保留它们的类型,它们不会被强制转换为最不常见的超类型Any
。
保证按顺序执行一系列 onSuccess:例如:
f.onSuccess { println(1) // #1 } onSuccess { println(2) // #2 }
#1 保证在 #2 之前执行
线程模型有点不同。没有 ExecutionContext 的概念,在 Promise(未来的可变实现)中设置值的线程是执行未来图中所有计算的线程。例如:
val f1 = new Promise[Int] f1.map(_ * 2).map(_ + 1) f1.setValue(2) // <- this thread also executes *2 and +1
有一个中断/取消的概念。使用 Scala 的 Futures,信息只向一个方向流动,使用 Twitter 的 Future,您可以通知生产者一些信息(不一定是取消)。在实践中,它在 Finagle 中用于传播 RPC 的取消。因为 Finagle 还通过网络传播取消,并且因为 Twitter 有大量的请求,这实际上节省了很多工作。
class MyMessage extends Exception val p = new Promise[Int] p.setInterruptHandler { case ex: MyMessage => println("Receive MyMessage") } val f = p.map(_ + 1).map(_ * 2) f.raise(new MyMessage) // print "Receive MyMessage"
直到最近,Twitter 的 Future 是唯一实现高效尾递归的(即你可以有一个递归函数调用自身而不会炸毁你的调用堆栈)。它已在 Scala 2.11+ 中实现(我相信)。
据我所知,支持使用 Twitter 的主要区别在于Future
它可以被取消,这与 scala 的Future
.
此外,曾经有一些对跟踪调用链的支持(您可能知道在使用 Futures 时,普通的堆栈跟踪几乎是无用的)。换句话说,你可以拿一个 Future 并告诉它是由哪个链map
/flatMap
产生的。但如果我理解正确,这个想法就被放弃了。