在数据库调用中调用Await.result有多危险 [英] How risky is it to call Await.result on db calls

问题描述

使用幻像时，在数据库调用中遵循此模式有多危险：

When using phantom how dangerous is it to be following this pattern in db calls:

Await.result(dbOperationFut, 30.seconds)

这并不是真正的幻象，但它是使用的scala驱动程序。

This isn't really phantom specific but it is the scala driver being used.

我对这种模式感到厌倦，因为潜在的GC暂停可能持续超过x秒。

I am weary of this pattern because of the potential GC pause that might last for over x seconds. How many seconds is safe given GC pauses?

我个人赞成使用for-comp而不是像这样阻塞，但是只是想知道这是否是真正的？

I am personally in favor of using for-comp and not blocking like this, but just want to know if this is a REALLY bad practice or it is fine.

上下文：这适用于基于akka的应用程序（akka，akka http）

Context: This would be for akka based applications (akka, akka http)

有想法吗？

推荐答案

请注意Await.result

请注意，这同时适用于Akka和Play应用程序

Await.result 仅在绝对必要时应非常谨慎地使用。

Await.result should be used very carefully only when it is absolutely necessary.

Await.result 阻塞运行该线程的线程，直到给定的持续时间。阻塞线程将浪费宝贵的计算资源，因为该线程将无法执行任何有用的计算，例如处理新请求或算法中的数字运算等等。

Await.result blocks the thread in which it is running until the given duration. Blocking the thread will waste the precious computation resource because that thread will not be able to do any useful computation like handling the new request or number crunching in an algorithm etc.

所以，请尽量避免使用 Await.result 。

So, Avoid using the Await.result as much as possible.

但是，什么时候使用它（Await.result）？

But, when do we use it (Await.result) ?

这是使用 Await.result 的典型用例之一。

Here is one of the typical use case for using Await.result.

假设您编写了一个包含主线程的程序，并且主线程内部的所有计算都是异步的。现在，一旦您在主线程中启动异步计算。有人必须停止存在的主线程，直到异步计算完成，否则程序将停止运行，并且您将看不到异步计算的结果。

Lets say you have written a program containing main thread and all the computation inside the main thread is asynchronous. Now once you start the asynchronous computation inside the main thread. Some one has to stop the main thread from existing till the asynchronous computation finishes, if not the program stops running and you cannot see the result of the asynchronous computation.

当应用程序开始运行时，有一个非守护进程线程，其任务是执行main（）。直到非守护程序线程完成，并且直到完成非守护程序线程，JVM才会自行退出。

When an application begins running, there is one non-daemon thread, whose job is to execute main(). JVM will not exit by itself until and unless non-daemon threads are completed.

object Main {
 def main(args: Array[String]): Unit = {
  import scala.concurrent.Future
  import scala.concurrent.duration._

  val f = Future { //do something }
  //stop main thread till f completes
  Await.result(f, 10 seconds)
 }
}

Future使用守护程序线程来运行。因此，守护程序线程无法阻止JVM关闭。因此，即使非守护线程正在运行，JVM也会关闭。

Future uses daemon threads for running. So daemon threads cannot stop the JVM from shutting down. So JVM shuts down even if non-daemon threads are running.

在上述情况下，没有其他方法可以期望停止（阻止）主线程直到计算 f 完成，如果没有主线程退出且计算停止。

In the above case there is no other way expect stopping (blocking) the main thread till the computation f completes if not main thread exits and computation stops.

在大多数情况下，您不需要使用 Await.result 和使用<$ c的简单 Future 组合$ c>地图和 flatMap 就足够了。

In most of the cases you do not need to use Await.result and simple Future composition using map and flatMap would suffice.

使用Await.result的风险（通常所有阻塞代码）

用完基于事件的模型中的线程

在基于事件的模型中，如果您有阻塞代码，则会很快用完线程很长的时间回来。在playframework中，任何阻塞调用都可能降低应用程序的性能，并且应用程序将在线程用完时变得非常缓慢。

In event based model you will quickly run out of threads if you have blocking code which takes long time to return. In playframework any blocking call could decrease the performance of the application and app will becomes dead slow as it runs out of threads.

在非基于事件的模型中内存不足

每个请求模型中的线程数。当您阻塞通话时，需要花费很长时间退出/返回。

In thread per request models. When you have blocking calls which take long time to exit/return.

情况1：如果您有固定的线程池，则应用程序可能会用完线程。

情况2：如果您具有动态增长的线程池，则您的应用程序将遭受过多的上下文切换开销，并且由于内存中阻塞的线程过多而将耗尽内存。

在所有情况下，期望等待一些IO或其他事件的工作都没有完成。

In all of the cases no useful work is done expect for waiting for some IO or some other event.

这篇关于在数据库调用中调用Await.result有多危险的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！