在WPF应用程序中缓存从CurrentSynchronizationContext检索到的TaskScheduler

加载WPF应用程序时，存储/缓存从TaskScheduler.FromCurrentSynchronizationContext返回的TaskScheduler是否有意义，并从那时起每隔一天使用一次？这种用法有什么缺点吗

---

缓存的意思是在单例中存储对TaskScheduler的引用，并使其可用于我应用程序的所有部分，可能是在DI/IoC容器的帮助下，或者在最坏的情况下，在一个简单的ol'singleton中。

FromCurrentSynchronizationContext的底层实现只是实例化了一个名为

SynchronizationContextTaskScheduler

的内部类的实例，该类非常轻量级。它所做的只是缓存在构造时找到的

SynchronizationContext

，然后

QueueTask

实现只需对该

SynchronizationContext

执行

任务

因此，尽管如此，我根本不需要缓存这些实例。
正如Drew所说，这样做对性能没有好处。但是，可能还有其他原因需要保留
任务调度器

您可能希望这样做的一个原因是，当您需要
任务调度器时，从CurrentSynchronizationContext
调用
可能已经太晚了，因为您可能无法再确定自己处于正确的上下文中。（例如，也许您可以保证构造函数在正确的上下文中运行，但您无法保证何时调用类的任何其他方法。）

由于获得
SynchronizationContext
的
TaskScheduler
的唯一方法是通过
FromCurrentSynchronizationContext
方法，因此您需要存储对
TaskScheduler
本身的引用，而不仅仅是在构造函数期间获取
SynchronizationContext.Current
。但我可能会避免称之为“缓存”，因为这个词意味着您这样做是出于性能原因，而实际上您这样做是出于必要

另一种可能性是，您可能有一些代码不需要知道它正在使用哪个特定的
TaskScheduler
，但仍然需要使用调度器，因为它会触发新任务。（如果启动新任务，即使您没有意识到，您也在选择一个计划程序。如果您没有明确选择要使用的计划程序，您将使用默认的计划程序，这并不总是正确的做法。）在这种情况下，我编写了代码：我编写了接受
TaskScheduler
对象作为参数的方法，并将使用它。这是另一个场景，您可能希望保留对调度程序的引用。（我之所以使用它，是因为我希望特定的IO操作发生在特定的线程上，所以我使用了一个定制的调度程序。）

话虽如此，应用程序范围的单例对我来说并不是一个好主意，因为它会使测试更加困难。这还意味着，共享调度器的代码捕获是在假设它应该使用哪个调度器，这可能是一种代码味道。
感谢对这种情况的深入分析！