c# - 在 WCF 方法中使用 Task.WaitAll

Question

我有一个 .NET 4.5.1 WCF 服务，用于处理来自将被成千上万用户使用的应用程序的同步。我目前使用 Task.WaitAll 如下所示，它工作正常，但我读到这很糟糕，可能导致死锁等。我相信我过去尝试过 WhenAll 但它没有用，我不记得这些问题是我将再次回到这里进行审查，以确保我做对了。我关心的是在这种使用中是否需要和首选阻塞，这是一种 WCF 服务方法，因此 WaitAll 似乎可以正常工作的原因。

我有大约十几种方法，每种方法都更新 Entity Framework 6 中的实体，使用现有数据处理传入数据并进行必要的更改。这些方法中的每一个都可能很昂贵，所以我想主要使用并行性来让所有方法在这个强大的 24 核服务器上同时工作。每个方法都作为 Task 返回，因为将其内容包装在 Task.Run 中。 DoSync 方法创建了一个新的 List 并将这些同步方法中的每一个添加到列表中。然后我调用 Task.WaitAll(taskList.ToArray()) 并且一切正常。

这是正确的做法吗？我想确保此方法可以很好地扩展，不会导致问题，并且可以在 WCF 服务场景中正常工作。

Answer 1

在大规模服务中，使用异步 IO 通常是个好主意(你不是 - 你使用 Task.Run)。 “高规模”的定义非常松散。服务器上异步 IO 的好处是它不会阻塞线程。这导致更少的内存使用和更少的上下文切换。仅此而已。

如果您不需要这些好处，您可以使用同步 IO 和阻塞所有你喜欢的。不会有什么不好的事情发生。请理解，在后台线程上运行 10 个查询并等待它们会暂时阻塞 11 个线程。这可能很好，也可能不好，具体取决于您期望的并发操作数。

我建议您稍微研究一下异步 IO 的可伸缩性优势，以便更好地理解何时使用它。请记住，使用异步是有代价的:更慢的开发和更多的并发错误。

了解，异步 IO 与仅使用线程池 (Task.Run) 不同。线程池不是无线程的，而异步 IO 根本不使用任何线程。甚至没有由运行时管理的“隐形”线程。

我经常发现的是:如果你不得不问，你就不需要了。