scala - 在单独的执行上下文中运行断言的安全性

标签 scala crash future assertion

不同的执行上下文之间的隔离度如何?假设我们有两个执行上下文ec1ec2都用于实现某些用户旅程的同一代码路径上。如果说饥饿和崩溃在ec2中开始发生,那么ec1会保持不受影响吗?

例如,考虑以下情形,我们要通过在Future中运行一个断言来确保仅向用户收费一次

chargeUserF andThen { case _ => 
  getNumberOfChargesF map { num => assert(num == 0) }
    .andThen { case Failure(e) => logger.error("User charged more than once! Fix ASAP!", e)  } 
}


这里getNumberOfChargesF并不是满足用户请求所必需的,它只是一个侧面问题,在数据库中被chargeUserF突变后,我们对数据库的预期状态进行断言。因为没有必要,我担心将其添加到主要业务逻辑中会感到不安,因为担心它会以某种方式破坏主要逻辑。如果我在与getNumberOfChargesF使用不同的执行上下文上运行chargeUserF,是否可以假设getNumberOfChargesF引起的饥饿,阻塞等问题不会影响主要业务逻辑?

最佳答案

每个执行上下文都有其自己的线程池,所以,有点。
从某种意义上说,它们是“独立的”,如果一个线程用完了,另一个线程可能仍会继续运行,但是,它们确实使用相同的资源(cpu),因此,如果一个线程用尽了资源,那么另一个显然会受到影响。

它们还受到彼此副作用的影响。例如,您的代码编写方式,chargeUsergetNumberOfCharges是并行发生的,并且没有说哪个先完成,因此,如果我猜对了语义,收费的数量可能最终为0或1个随机数,具体取决于先前的将来是否已完成。

关于scala - 在单独的执行上下文中运行断言的安全性,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/56194442/

相关文章:

scala - sbt 找不到由 Resolver.file() 定义的本地存储库

C# 4.0 编译器崩溃

Scala 方法来转换点数组

scala - 限制来自 Spark 执行程序的并发 HTTP 请求

c - 段错误,尽管代码从未执行?

rust - rust 铸就 future 的沉沦

list - 按顺序调用任意数量的 WS.url().get()

multithreading - Scala 中的异步 IO 与 future

java - Java 中的 Scala 对象

c++ - 崩溃转储的最佳标志