通过 C# 2.0 读取 CLR（我目前没有 3.0）
是否仍然如此：
如果一台计算机中只有一个 CPU，那么任何时候都只能运行一个线程。Windows 必须跟踪线程对象，并且每隔一段时间，Windows 必须决定接下来调度哪个线程以进入 CPU。这是必须每 20 毫秒左右执行一次的附加代码。当 Windows 使 CPU 停止执行一个线程的代码并开始执行另一个线程的代码时，我们称之为上下文切换。上下文切换相当昂贵，因为操作系统必须：
所以通过 C# 2.0 的 CLR 可以说我们在 Pentium 4 2.4ghz 1 core non-HT, XP 上。每 20 毫秒？在 CLR 线程或 Java 线程映射到 OS 线程的情况下，每秒最多只有 50 个线程可能有机会运行？
我已经读到在 SO 上的上下文切换在微秒内非常快，但是大致（大小风格的猜测）多久会说一个适度的 5 岁服务器 Windows 2003 Pentium Xeon 单核给操作系统提供上下文切换的机会？20ms 在正确的区域？
我不需要确切的数字我只是想确保它在正确的区域，对我来说似乎相当长。
所谓的 Quantum 取决于一些事情，包括操作系统在运行过程中所做的性能调整；例如，前台进程被赋予更高的优先级，并且可以被赋予[比默认值长 3 倍的时间量。服务器和客户端 SKU 之间也存在差异，通常客户端的默认时间间隔为 30 毫秒，而服务器为 180 毫秒。
因此，需要尽可能多的 CPU 的前台进程可能会在上下文切换之前获得 90 毫秒的时间片......然后操作系统可能会决定它不需要切换并让 Quantum 继续。
您的“一次 50 个线程”数学是错误的。您假设每个线程都处于 100% CPU 状态。大多数线程实际上在等待 IO 或其他事件时处于休眠状态。即便如此，大多数线程在进入 IO 模式或以其他方式放弃其切片之前不会使用它们的整个 20 毫秒。
试试这个。编写一个无限循环的应用程序（吃掉它的整个 CPU 窗口）。运行它的 50 个实例。看看 Windows 是如何反应的。
我刚刚做了一个测试，我有 43 个线程在一秒钟内看到它的份额（在预热之后），这使得 Richter 语句非常准确（有开销）我说。四核/Win7/64位。是的，这些都是 100% cpu 线程，所以很明显它们在 20 毫秒之前没有被收回。有趣的