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

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

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

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.

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.

这取决于很多因素。进程比线程更重，启动和关闭成本更高。进程间通信(IPC)也比线程间通信更困难、更慢。

相反，进程比线程更安全，因为每个进程都运行在自己的虚拟地址空间中。如果一个进程崩溃或缓冲区溢出，它根本不会影响任何其他进程，而如果一个线程崩溃，它会关闭进程中的所有其他线程，如果一个线程缓冲区溢出，它会在所有线程中打开一个安全漏洞。

因此，如果应用程序的模块可以在很少通信的情况下独立运行，那么如果能够负担得起启动和关闭成本，则可能应该使用进程。IPC对性能的影响将是最小的，并且您在漏洞和安全漏洞方面会稍微安全一些。如果您需要获得或拥有大量共享数据(例如复杂的数据结构)，那么请使用线程。

在我最近的LINUX工作中，需要注意的一件事是库。如果您正在使用线程，请确保跨线程使用的所有库都是线程安全的。这让我疼了好几次。值得注意的是，libxml2并不是开箱即用的线程安全的。它可以用线程安全编译，但这不是你用aptitude install得到的。