在加载 WPF 应用程序时存储/缓存从 TaskScheduler.FromCurrentSynchronizationContext 返回的 TaskScheduler 并从此以后使用它是否有意义？这种用法有什么缺点吗？
我所说的缓存的意思是在单例中存储对 TaskScheduler 的引用，并使其可用于我的应用程序的所有部分，可能需要借助 DI/IoC 容器或在裸露的单例中实现最坏的情况。
最佳答案
正如 Drew 所说，这样做对性能没有任何好处。但可能还有其他原因需要保留 TaskScheduler。
您可能想要这样做的一个原因是，当您需要 TaskScheduler 时，调用 FromCurrentSynchronizationContext 可能已经太晚了，因为您可能不再能够确保您处于正确的环境中。 (例如，也许您可以保证您的构造函数在正确的上下文中运行，但您无法保证何时调用您的类的任何其他方法。)
由于获取 SynchronizationContext 的 TaskScheduler 的唯一方法是通过 FromCurrentSynchronizationContext 方法，因此您需要存储对TaskScheduler 本身，而不是仅仅在构造函数期间获取 SynchronizationContext.Current。但我可能会避免将其称为“缓存”，因为该词意味着您这样做是出于性能原因，而实际上您这样做是出于必要。
另一种可能性是，您的代码可能不知道它正在使用哪个特定的 TaskScheduler，但仍然需要使用调度程序，因为它会触发新任务。 (如果您开始新任务，即使您没有意识到，您也会选择一个调度程序。如果您没有明确选择要使用的调度程序，您将使用默认的调度程序，这并不总是正确的)我已经编写了这种情况的代码:我已经编写了接受 TaskScheduler 对象作为参数的方法，并将使用它。因此，这是您可能希望保留对调度程序的引用的另一种情况。 (我使用它是因为我希望某些 IO 操作发生在特定线程上，所以我使用了自定义调度程序。)
话虽如此，应用程序范围的单例对我来说听起来并不是一个好主意，因为它往往会使测试变得更加困难。这还意味着获取共享调度程序的代码正在假设它应该使用哪个调度程序，这可能是一种代码味道。
关于wpf - 缓存 TaskScheduler 在 WPF 应用程序中检索 FromCurrentSynchronizationContext，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/5060381/