为什么操作系统进程似乎比java中的线程快

我开发了一个多线程java应用程序，它使用线程处理一批工作。我有一个主线程，它将工作分配到不同的线程。一切正常

现在我已经更改了应用程序，允许它在多个java进程中运行，每个进程都像以前一样执行多线程处理。例如，我过去在一个java进程中有8个线程来处理8个作业，现在我可以有2个java进程，每个进程有4个线程来处理8个作业

应用程序是这样建模的：调度器将获取需要完成的工作，然后将它们分派到线程池。线程之间没有同步或通信

---

在后面的方法中，我注意到了相当大的性能提升，我想知道为什么。有人能对这一点有一些见解吗？操作系统进程调度是否比java线程更有效？当我真的需要性能提升时，是否应该将此作为一般经验法则？谢谢。

这取决于很多因素。首先，您是否查看了这两种情况下的CPU和内存负载水平？我希望在这两个过程中，系统的负载更大，因此工作速度更快

另一个原因可能是，您只是有两个不同的内存堆，由两个单独的垃圾收集器清理

---

进程之间如何通信（文件、管道、队列、套接字等）？在多进程情况下，您不能共享内存（除非您调用一些操作系统调用，这是有代价的）。在测量时间时，您是否考虑了此通信时间？

如果没有您的代码，这个问题几乎无法回答（线程之间的同步和通信会产生开销），即使忽略线程与进程在调度优先级方面的关系，也会因平台而异。与两个进程相比，您是否只测试了一个4线程进程的性能（吞吐量）？还是两个进程有8个线程还是2个线程？有多少核？正在进行什么样的处理以及如何进行处理？最有可能的情况是，您有一个资源瓶颈，通过使用两个进程，您的资源瓶颈增加了一倍。通常情况下，当一个进程被很好地调整时，通过使用它来节省开销。听起来不错。具有相同设置的两个JVM相当于两倍的内存。有更多的内存可用于处理。它可能会完全避免完全gc。很多时候，使用较少的线程似乎会减慢速度，而不是加快速度。垃圾收集可能不是加速因素，因为可能有两倍的内存用于收集。此外，每个过程都必须进行两次JIT。这听起来很合理。该应用程序不是CPU密集型的，但需要大量内存。