我有一个.NET 4.5.1 WCF服务，该服务处理来自将由成千上万个用户使用的应用程序的同步。我目前使用Task.WaitAll，如下所示，并且工作正常，但我读到这很糟糕，可能导致死锁等。我相信我过去曾尝试过WhenAll，但没有成功，我不记得这些问题了。我将再次返回此评论，以确保我做对了。我担心的是在此使用中是否需要阻塞并且它是首选阻塞，这是WCF服务方法，因此，为什么WaitAll似乎可以正常工作。
我有大约十二种方法，每种方法都会更新Entity Framework 6中的实体，以现有数据处理传入数据并进行必要的更改。这些方法中的每一个都可能是昂贵的，所以我想主要使用并行性来使所有方法在此强大的24核心服务器上同时工作。每个方法都以Task的形式返回，并将其内容包装在Task.Run中。DoSync方法创建了一个新的列表，并将每个同步方法添加到列表中。然后，我调用Task.WaitAll（taskList.ToArray（）），并且一切正常。
这是正确的方法吗？我想确保此方法可以很好地扩展，不会引起问题，并且可以在WCF服务方案中正常工作。
在大规模服务中，通常最好使用异步IO（不是，而是使用Task.Run）。“高等级”的定义非常宽松。服务器上的异步IO的好处是它不会阻塞线程。这导致更少的内存使用和更少的上下文切换。这就是全部。
如果您不需要这些好处，则可以使用同步IO并阻止所有需要的操作。不会有坏事发生。可以理解，在后台线程上运行10个查询并等待它们会暂时阻止11个线程。根据您期望的并发操作数，这可能很好，也可能不好。
我建议您对异步IO的可伸缩性优势进行一些研究，以便更好地了解何时使用它。请记住，进行异步操作需要付出一定的代价：开发速度较慢，并发错误更多。
可以理解，异步IO与仅使用线程池（Task.Run）不同。线程池不是无线程的，而异步IO根本不使用任何线程。甚至没有运行时管理的“不可见”线程。
我经常发现的是：如果需要询问，则不需要它。
本文收集自互联网，转载请注明来源。
如有侵权，请联系[email protected] 删除。
我来说两句