我试图了解操作系统如何处理不同模型中的上下文切换，以更好地理解为什么在请求数量出现大峰值的情况下NIO性能更好。除了线程数量可能有限制之外，我很好奇在大量请求中执行的阻塞操作会如何影响资源利用率。
在一个每线程一个请求的模型中，比如一个基于servlet 2.5的web应用程序，如果499个线程正在等待数据库IO，而只有一个线程需要工作，那么操作系统上下文是否会在试图找到需要工作的500个线程之间切换？要执行上下文切换，操作系统必须存储当前线程的状态，并恢复下一个线程的状态。这样做之后，操作系统会发现它不需要任何CPU时间，并会保持上下文切换，直到找到需要工作的线程。此外，就服务器利用率而言，这看起来是什么样子的？CPU是否很低，因为它主要受输入和输出上下文交换的IO成本的限制，而不是实际计算任何东西？
提前感谢您的帮助。如果你能给我指书、课本等的方向，我也会非常感激。
如果499个线程正在等待数据库IO，并且只需要一个线程操作系统上下文是否在这500个线程之间切换试图找到一个需要工作的人？
如果操作系统的调度器设计合理，则不会；一直在系统的所有线程上迭代会非常低效。
相反，大多数调度程序实现都保留一个休眠/阻塞线程列表和一个单独的"准备运行"线程列表。当发生本应唤醒线程的事件时（例如，套接字或文件句柄上的传入数据变为可用，或者线程被阻止的互斥体被释放），操作系统会将该线程从休眠/阻止线程列表移动到就绪线程列表。然后，当需要执行上下文切换时，操作系统会从就绪线程列表中选择一个线程，加载到该线程的上下文中，并开始运行它。在任何现代/流行的操作系统中，休眠/阻止线程列表的大小对调度程序从就绪线程中选择要运行的线程所花费的时间都没有任何影响。（在某些操作系统下，就绪线程列表的大小可能会产生影响，但一些调度器的设计是为了即使有许多就绪线程的系统也不会导致调度器的效率降低）
CPU是否较低，因为它主要受交换IO成本的限制上下文输入和输出，而不是实际计算任何内容？
假设您还没有用完RAM，那么在切换线程上下文时就不会涉及I/O；上下文切换仅涉及CPU和RAM。如果CPU使用率较低，最有可能的原因是线程的算法本身受I/O限制（例如，大多数情况下，所有东西都在网卡或硬盘上等待读取或写入数据）。如果您的线程实际上没有执行任何I/O，并且您仍然受I/O限制，那么这可能表明您的计算机已经用完了所有可用的RAM，并且正在颠簸——这不是一个好的状态。