FlatMap与For-Comprehension性能对比：Play Actor方法阻塞性及性能疑问

嘿，我来帮你把这些疑问理清楚！

首先：for-comprehension 完全不是阻塞的！ #

你听到的“for-comprehension是阻塞的”说法完全是误解——Scala里针对Future的for推导式只是flatMap、map等异步方法的语法糖而已。你写的两段代码：

// for推导式版本
onSomething(): Future[Unit] = { 
  for { 
    a <- somethingThatReturnsFuture 
    b <- anotherThingThatReturnsFuture 
  } yield ()
}

和

// flatMap/map嵌套版本
onSomething(): Future[Unit] = { 
  somethingThatReturnsFuture.flatMap(res1 => { 
    anotherThingThatReturnsFuture.map(res2 => { 
      //whatever 
    }) 
  }) 
}

编译后是完全等价的，编译器会自动把for推导式转换成嵌套的flatMap和map调用。两者在异步逻辑、性能上没有任何区别，唯一的差异只是代码可读性——for推导式在处理多步异步操作时，比嵌套的flatMap/map更清爽易读。

关于Akka Actor的定时调用逻辑 #

你的Actor每2秒触发一次onSomething()，这里要明确：Akka在调用这个方法时，根本不会等待返回的Future完成。

因为onSomething()方法本身只是创建并返回一个Future对象（这个过程是瞬间完成的，非阻塞），Actor的线程在执行完onSomething()并拿到Future后，就会立刻释放，去处理下一次的定时触发或者其他消息。哪怕somethingThatReturnsFuture和anotherThingThatReturnsFuture需要很长时间才能完成，也不会影响Actor的下一次定时调用——这些异步操作是在Akka的线程池里独立执行的，和Actor的消息处理线程是解耦的。

所以哪怕你运行16个实例，每个Actor的定时任务都会按每2秒一次正常触发，不会因为之前的Future还在执行就被卡住。

为什么会有“for推导式阻塞”的误解？ #

这种误解大概率是把Scala的for推导式和传统的阻塞式循环（比如Java里的for循环处理同步阻塞操作）搞混了。但针对Future的for推导式本质是异步操作的串联：它会等待第一个Future完成后，再触发第二个Future，整个过程都是非阻塞的——不会占用线程原地等待结果，而是通过回调机制在结果就绪时继续执行后续逻辑。

总结一下 #

• for推导式不是阻塞的，是flatMap/map的语法糖，和手动写flatMap/map完全等价
• Akka调用返回Future的方法时，不会等待Future完成，定时触发会正常按间隔执行
• 两种写法性能无差异，优先选择for推导式提升代码可读性

内容的提问来源于stack exchange，提问作者JohnBigs