Java 为什么在单独的线程池中从非阻塞操作中分离阻塞比在一个线程池中执行所有操作更好？

我一直在阅读Play框架关于Play中线程池（）的文档，但不知怎么的，我在某些事情上无法计算。也许，你可以帮我

文档说，在阻塞调用和非阻塞调用之间维护peach的最佳实践是拥有多个线程池，并为每种特定类型的操作使用一个线程池。在非阻塞操作的情况下，理想的线程池将为每个核心执行1个线程，因此线程的最大数量将非常低。对于阻塞操作（如重关系数据库调用），更好的方法是拥有一个大线程池，允许每个核心有许多可用线程

我看不到的是，如果我们设想在4核机器上运行应用程序，那么活动运行线程的最大数量是4。这意味着，如果4个线程被耗时的DB操作占用，我的非阻塞操作也将很难执行，直到阻塞操作消失

---

因此，我的问题是运行两个独立线程池的真正好处是什么，而不是拥有一个适度大的线程池。我缺少什么？

阻塞的线程不会阻塞内核

当一个线程被阻塞时，它会放弃正在运行的内核，使该内核可以运行另一个线程。因此，如果有一个线程可用，您的非阻塞操作可以在另一个线程上继续

---

使用单独的线程池的原因是，阻塞操作可能会耗尽池中的所有可用线程，因此没有可用于非阻塞操作的线程。通过为非阻塞操作使用单独的池，您可以帮助确保有线程可以利用阻塞操作未持续使用的内核。

这排除了线程执行本地耗时CPU操作的情况，对吗？在这种情况下，线程确实会被阻塞，但其各自的CPU内核也会被阻塞。术语可能有点混乱。的确，这不包括这种情况，但这里线程本身并没有被阻塞，而是在运行，换句话说，它只是忙或长时间运行。调用方可能会被阻止，直到操作完成，但线程本身不会被阻止。这些类型的操作可能与其他非阻塞操作一样在同一个线程池中处理，因为它确实占用了内核和线程。实际上被阻塞的线程通常在等待某种类型的I/O，如前面提到的DB操作，而不是消耗CPU——数据库本身通常在其他机器上运行，或者至少在其他进程中运行。。。即使使用“嵌入式”DB，DB本身通常也会阻塞磁盘I/O，这将立即释放内核以运行另一个线程。