我不得不同意你所听到的。当我们对我们的集群(xhpl等)进行基准测试时，我们总是通过进程而不是线程获得明显更好的性能。< /轶事>

Threads -- > Threads shares a memory space,it is an abstraction of the CPU,it is lightweight. Processes --> Processes have their own memory space,it is an abstraction of a computer. To parallelise task you need to abstract a CPU. However the advantages of using a process over a thread is security,stability while a thread uses lesser memory than process and offers lesser latency. An example in terms of web would be chrome and firefox. In case of Chrome each tab is a new process hence memory usage of chrome is higher than firefox ,while the security and stability provided is better than firefox. The security here provided by chrome is better,since each tab is a new process different tab cannot snoop into the memory space of a given process.

我不得不同意你所听到的。当我们对我们的集群(xhpl等)进行基准测试时，我们总是通过进程而不是线程获得明显更好的性能。< /轶事>

Linux(实际上还有Unix)为您提供了第三种选择。

选项1 -流程

创建一个独立的可执行文件来处理应用程序的某些部分(或所有部分)，并为每个进程分别调用它，例如，程序运行自己的副本来委托任务。

选项2 -线程

创建一个独立的可执行文件，它由一个线程启动，并创建额外的线程来执行一些任务

选项3 -分叉

仅在Linux/Unix下可用，这有点不同。fork进程实际上是拥有自己地址空间的进程——子进程(通常)无法影响其父进程或兄弟进程的地址空间(不像线程)——因此您获得了额外的健壮性。

但是，内存页不是复制的，它们是写时复制的，因此通常使用的内存比您想象的要少。

考虑一个web服务器程序，它包含两个步骤:

读取配置和运行时数据 服务页面请求

如果您使用线程，第1步将完成一次，第2步将在多个线程中完成。如果您使用“传统”流程，那么每个流程都需要重复步骤1和步骤2，存储配置和运行时数据的内存也需要重复。如果您使用fork()，那么您可以执行第1步，然后fork()，将运行时数据和配置保留在内存中，不受影响，不复制。

所以实际上有三种选择。

在大多数情况下，我更喜欢进程而不是线程。 当您有一个相对较小的任务(每个划分的任务单元占用的进程开销>>时间)，并且需要在它们之间共享内存时，线程可能会很有用。想象一个大数组。 另外(离题)，请注意，如果您的CPU利用率是100%或接近100%，那么多线程或处理将没有任何好处。(事实上情况会更糟)

如果你需要共享资源，你真的应该使用线程。

还要考虑这样一个事实:线程之间的上下文切换比进程之间的上下文切换代价要小得多。

我认为没有理由明确地使用单独的进程，除非你有一个很好的理由这样做(安全，经过验证的性能测试，等等……)