multithreading - 上下文在 sleep /等待线程上切换

Question

我试图了解操作系统如何处理不同模型中的上下文切换，以更好地理解为什么在请求数量出现大峰值的情况下 NIO 性能更好。除了线程数量可能存在限制这一事实之外，我很好奇在这些大量请求中执行的阻塞操作如何影响资源利用率。

在每个线程模型的一个请求中，假设一个基于 servlet 2.5 的 Web 应用程序，如果 499 个线程正在等待数据库 IO 并且只有一个线程需要工作，那么操作系统上下文是否在所有这 500 个线程之间切换，试图找到需要工作的线程?为了执行上下文切换，操作系统必须存储当前线程的状态，并恢复下一个线程的状态。这样做之后，操作系统会发现它不需要任何 CPU 时间，并会保持上下文切换，直到找到需要工作的线程。
另外，就服务器利用率而言，这看起来如何？ CPU 是否很低，因为它主要受交换上下文的 IO 成本的限制，而不是实际计算任何东西？

在此先感谢您的帮助。如果您能指出书籍、教科书等的方向，我也将不胜感激。

Answer 1

If 499 threads are waiting for database IO and only one thread needs work, does the OS context switch between all of those 500 threads trying to find the one that needs work?

如果操作系统的调度程序设计合理，则不会；一直迭代系统的所有线程会非常低效。

相反，大多数调度程序实现保留一个 sleep /阻塞线程列表和一个单独的“准备运行”线程列表。当发生应该唤醒线程的事件时(例如，传入数据在套接字或文件句柄上变得可用，或者线程被阻塞的互斥体被释放)，操作系统将该线程从 sleep /阻塞状态中移出-线程列表到就绪线程列表。然后，当需要执行上下文切换时，操作系统从就绪线程列表中选择一个线程，加载到该线程的上下文中，并开始运行它。在任何现代/流行的操作系统中， sleep /阻塞线程列表的大小对调度程序从就绪线程列表中选择一个线程运行所需的时间没有任何影响。 (在某些操作系统下，就绪线程列表的大小可能会产生影响，但 some schedulers 的设计目的是即使系统具有许多就绪线程也不会导致调度程序效率降低)

Is the CPU low as it's mostly bound by the IO cost of swapping contexts in and out instead of actually computing anything?

假设您没有用完 RAM，切换线程上下文不涉及 I/O；上下文切换仅涉及 CPU 和 RAM。如果 CPU 使用率低，最可能的原因是您的线程算法本身受 I/O 限制(例如，大多数情况下，大多数情况都在您的网卡或硬盘驱动器上等待读取或写入数据)。如果您的线程实际上不执行任何 I/O，而您仍然受 I/O 限制，这可能表明您的计算机已用完所有可用 RAM 并且是 thrashing - 不是一个好的状态。