当然可以在 Future 主体的第一行收集系统时间。但:
是否有可能在没有访问未来代码的情况下知道那个时间。(在我的情况下,返回未来的方法将由“框架”的用户提供。)
def f: Future[Int] = ...
def magicTimePeak: Long = ???
当然可以在 Future 主体的第一行收集系统时间。但:
是否有可能在没有访问未来代码的情况下知道那个时间。(在我的情况下,返回未来的方法将由“框架”的用户提供。)
def f: Future[Int] = ...
def magicTimePeak: Long = ???
它Future
本身并不真正知道这一点(也不是为了关心而设计的)。当代码真正被执行时,这一切都取决于执行者。这取决于线程是否立即可用,如果没有,何时可用。
我想你可以 wrapFuture
来跟踪它。这将涉及创建一个Future
带有闭包的底层,该闭包会更改包装类中的可变变量。由于您只需要 a Long
,因此如果Future
尚未开始执行,它必须默认为零,尽管将其更改为Option[Date]
或其他东西是微不足道的。
class WrappedFuture[A](thunk: => A)(implicit ec: ExecutionContext) {
var started: Long = 0L
val underlying = Future {
started = System.nanoTime / 1000000 // milliseconds
thunk
}
}
为了证明它有效,用一个线程创建一个固定的线程池,然后给它一个阻塞任务,比如说 5 秒。然后,创建一个WrappedFuture
,started
稍后检查它的值。请注意记录时间的差异。
import java.util.concurrent.Executors
import scala.concurrent._
val executorService = Executors.newFixedThreadPool(1)
implicit val ec = ExecutionContext.fromExecutorService(executorService)
scala> println("Before blocked: " + System.nanoTime / 1000000)
Before blocked: 13131636
scala> val blocker = Future(Thread.sleep(5000))
blocker: scala.concurrent.Future[Unit] = scala.concurrent.impl.Promise$DefaultPromise@7e5d9a50
scala> val f = new WrappedFuture(1)
f: WrappedFuture[Int] = WrappedFuture@4c4748bf
scala> f.started
res13: Long = 13136779 // note the difference in time of about 5000 ms from earlier
但是,如果您不控制 的创建,Future
则无法确定它何时开始。