多线程是为受虐狂准备的。：）

If you are concerned about an environment where you are constantly creating threads/forks, perhaps like a web server handling requests, you can pre-fork processes, hundreds if necessary. Since they are Copy on Write and use the same memory until a write occurs, it's very fast. They can all block, listening on the same socket and the first one to accept an incoming TCP connection gets to run with it. With g++ you can also assign functions and variables to be closely placed in memory (hot segments) to ensure when you do write to memory, and cause an entire page to be copied at least subsequent write activity will occur on the same page. You really have to use a profiler to verify that kind of stuff but if you are concerned about performance, you should be doing that anyway.

Development time of threaded apps is 3x to 10x times longer due to the subtle interaction on shared objects, threading "gotchas" you didn't think of, and very hard to debug because you cannot reproduce thread interaction problems at will. You may have to do all sort of performance killing checks like having invariants in all your classes that are checked before and after every function and you halt the process and load the debugger if something isn't right. Most often it's embarrassing crashes that occur during production and you have to pore through a core dump trying to figure out which threads did what. Frankly, it's not worth the headache when forking processes is just as fast and implicitly thread safe unless you explicitly share something. At least with explicit sharing you know exactly where to look if a threading style problem occurs.

如果性能如此重要，那就增加另一台计算机和负载平衡。对于开发人员调试一个多线程应用程序的成本，即使是由一个有经验的多线程程序编写的应用程序，你可能会买4块40核的英特尔主板，每块都有64g内存。

That being said, there are asymmetric cases where parallel processing isn't appropriate, like, you want a foreground thread to accept user input and show button presses immediately, without waiting for some clunky back end GUI to keep up. Sexy use of threads where multiprocessing isn't geometrically appropriate. Many things like that just variables or pointers. They aren't "handles" that can be shared in a fork. You have to use threads. Even if you did fork, you'd be sharing the same resource and subject to threading style issues.

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

如果您希望尽可能地创建一个纯a进程，您可以使用clone()并设置所有克隆标志。(或者调用fork()来节省打字的时间)

如果你想创建一个纯粹的线程，你可以使用clone()并清除所有的clone标志(或者节省你自己的输入工作并调用pthread_create())

有28个标志指示资源共享的级别。这意味着你可以创建超过2.68亿种类型的任务，这取决于你想分享什么。

这就是我们所说的Linux不区分进程和线程，而是指程序中的任何控制流都是任务的意思。不区分两者的理由是，嗯，并不是唯一定义了超过2.68亿种口味!

因此，做出是使用进程还是线程的“完美决定”实际上就是决定克隆28种资源中的哪一种。

其他人讨论了这些考虑因素。

也许重要的区别是，在Windows中，与线程相比，进程是沉重和昂贵的，而在Linux中，差异要小得多，所以等式在不同的点上平衡。

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.

线程/进程之间的决定取决于您将使用它来做什么。 进程的好处之一是它有一个PID，可以在不终止父进程的情况下被杀死。

对于一个真实世界的web服务器的例子，apache 1.3过去只支持多进程，但是在2.0中他们增加了一个抽象，这样你就可以在两者之间切换。评论似乎同意进程更健壮，但线程可以提供更好的性能(除了那些进程性能很差且您只想使用线程的窗口)。