我在此链接http://msdn.microsoft.com/en-us/library/ms750441.aspx上阅读了有关 System.Threading.DispatcherObject 类型的信息
文章提到了逻辑线程和物理线程之间的一对一关系。这是文章的片段：
在 WPF 的设计阶段，目标是转移到单线程执行，但非线程“关联”模型。当组件使用执行线程的标识来存储某种类型的状态时，就会发生线程关联。最常见的形式是使用线程本地存储（TLS）来存储状态。线程亲和性要求每个执行的逻辑线程仅由操作系统中的一个物理线程拥有，这可能会占用大量内存。
有人可以请。解释逻辑线程与物理线程有什么区别？
本地线程是运行时中的线程。该线程比成熟的物理线程更轻量级，适用于更轻量级的进程。物理线程是处理器上下文切换到并处理的线程。当操作系统跟踪它时，它有更多与之关联的元数据。涉及更多细节，但这是一个快速概述。
在这种情况下，物理线程将在内部包含这些逻辑“虚拟线程”。
.NET 2.0 的 CLR 确实计划将光纤支持作为SQL CLR 的 .NET 线程。它从未进入产品中，但在遥远的将来，CLR 可能会支持它。因此，这个大红线亲和力警告。
操作系统本身确实支持光纤，但它们很难正确使用，因为您在用户模式下切换堆栈以让其他代码在同一物理线程上运行。这确实消除了昂贵的上下文切换，这在某些高性能场景中是有意义的。将纤程用作抽象并不是一个好主意，因为您无法调用任何第三方库，因为您不知道 api 是否确实假设了线程亲和性。
当今多核机器中上下文切换的成本远低于之前的几个 Windows 版本和处理器世代。我怀疑在现实世界的应用中你会从纤维中获得很多好处。除此之外，芯片制造商正在努力降低上下文切换的成本。讨论了一些设计，使其与一个 CPU 周期一样便宜。
使长话短说：
如果您自己托管 CLR 并使用 CLR 托管 API 的（尚不）现有功能，则 CLR 线程对象可能不是物理操作系统线程。
据我所知，即使在 Windows 8 中，Window 消息泵系统也将保留在那里，其中每个窗口都与创建线程具有线程关联性，该线程也必须泵送窗口消息。