Multithreading 通过scala单例对象进行并发处理

我尝试在功能测试中构建一个简单的编排引擎，如下所示：

object Engine {
  def orchestrate(apiSequence : Seq[Any]) {
    val execUnitList = getExecutionUnits(apiSequence) // build a specific list
    schedule(execUnitList) // call multiple APIs
  }

在下面调用的方法（getExecutionUnits和schedule）中，我应用的模式是增量构建列表（因此，不是val而是var），迭代列表并调用sepcific API，并对每个API运行一些自定义验证

我知道scala中的一个对象相当于一个单例（所以在我的例子中，引擎只有一个实例）。如果我希望同时调用orchestrate方法100次，我想知道这是否是一种合适的模式。我没有管理引擎对象中的任何其他内部变量，我只是对方法中提供的参数进行操作。假设调度方法最多需要10秒，我担心并发访问时的行为。如果client1、client2和client3同时调用此方法，是否会有2个客户端排队并被当前正在处理的客户端阻止

是否有一种更安全的惯用方法来处理用例？您是否建议使用actors包装“orchestrate”方法来处理并发请求

Edit：为了澄清，这两个方法（getExecutionUnits和schedule）并按顺序调用是绝对必要的。此外，schedule方法依次调用多个API（1到10之间的任意位置），它们也必须按顺序执行。到目前为止，我有一个简单的for循环，它一次处理1个Api，等待响应，然后在适当的情况下转到下一个

我没有管理Engine对象中的任何其他内部变量，我只是根据方法中提供的参数进行操作

如果您在引擎中使用任何VAR，这将不起作用。但是，从您的描述来看，似乎您没有：您在

getExecutionUnits

方法中有一个本地变量，并且（可能）在

计划中有一个本地变量，该变量使用
getExecutionUnits
的返回值初始化。这个案子应该没问题

如果client1、client2和client3同时调用此方法，是否会有2个客户端排队并被当前正在处理的客户端阻止

不，如果不添加任何同步（如果引擎本身没有状态，则不应该添加）

您是否建议使用actors包装“orchestrate”方法来处理并发请求

如果将其包装在一个参与者中，那么当引擎处理一个请求时，客户端将被阻止等待
 我使用的惟一变量是方法的本地变量，以便增量地构建列表或在from处理之后分配值（引擎本身中没有用于管理任何全局状态的变量）。我的理解是，当有超过1个参与者时，参与者会发光（因此，通过消息传递处理更快）。我不是想过度设计，但是如果我将这个“引擎”提取到它自己的restful web服务中，我是否可以利用actors来实现更高的吞吐量和并发性？@BSJ在所描述的例子中，不是。只要使用类似Netty的东西（如果你想异步处理请求，还可以使用Java的线程池）。参与者只会增加开销而没有任何好处（据我所知，在没有看到实际代码的情况下）。如果您需要管理引擎的某些内部状态，或者在不同的请求之间进行交互，那么答案会有所不同。