在使用从任务并行库派生的 API 和类时，开发人员何时需要关注垃圾回收的影响？
Can .NET Task instances go out of scope during run? ，似乎给人一种安全感，您不必担心将任务限制在范围内。然而，这个问题似乎仅限于在 ThreadPool 上运行的任务，然后由 ThreadPool root。但是，如果我理解 this MSDN blog post正确地，来自该 SO 问题的建议并不普遍适用，因为来自 TaskCompletionSource 的任务并非同样 root。
直接使用 TaskCompletionSource 是唯一值得关注的时候吗？
但是，在使用 API 时，您不知道任务来自何处。如果提供的 Task 来自 TaskCompletionSource 或其他一些非根源，您是否需要担心存储对延续的引用？
由于需要考虑任务是否有根(异步 I/O 任务是否有根？)，这似乎很快变得不方便和复杂。我正在努力寻找有关该主题的很多信息，但它是一个足够受欢迎的库我觉得我不需要阅读反编译的源代码来确定我是否需要担心垃圾收集器的竞争条件，所以我想我必须是遗漏或误解了某些东西。
最佳答案
当你有未完成的TaskCompletionSource时，总是有两个选择:
将来可能会完成该 TCS。这意味着某些东西持有对 TCS 的引用，这意味着它无法进行 GC。
常规规则仍然适用于该内容，因此您可能需要担心如何让其 Root 。
没有任何东西可以完成那个 TCS。这意味着 TCS 及其任务可能很快就会被 GC，但不存在工作未完成的风险(因为没有工作)。
关于c# - 任务和垃圾收集存在哪些问题？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/18091002/