Linux使用1-1线程模型，(对内核来说)没有进程和线程的区别——一切都只是一个可运行的任务。＊

在Linux上，系统调用clone克隆一个任务，共享级别可配置，其中包括:

CLONE_FILES:共享相同的文件描述符表(而不是创建一个副本) CLONE_PARENT:不要在新任务和旧任务之间建立父子关系(否则，child的getppid() = parent的getpid()) CLONE_VM:共享相同的内存空间(而不是创建COW副本)

Fork()调用clone(共享最少)，pthread_create()调用clone(共享最多)。**

fork的成本比pthread_creation略高，因为需要复制表并为内存创建COW映射，但是Linux内核开发人员已经尝试(并成功)将这些成本最小化。

如果任务共享相同的内存空间和不同的表，那么它们之间的切换将比不共享的任务稍微便宜一些，因为数据可能已经加载到缓存中了。然而，即使没有任何共享，切换任务仍然非常快——这是Linux内核开发人员试图确保(并成功确保)的另一件事。

事实上，如果您在多处理器系统上，不共享实际上可能有利于性能:如果每个任务都在不同的处理器上运行，同步共享内存的成本很高。

*简化。CLONE_THREAD导致信号传递被共享(这需要共享信号处理程序表的CLONE_SIGHAND)。

* *简化。SYS_fork和SYS_clone系统调用都存在，但是在内核中，SYS_fork和SYS_clone都是对同一个do_fork函数的非常薄的包装，而do_fork函数本身也是对copy_process的薄包装。是的，进程、线程和任务这三个术语在Linux内核中是可以互换使用的……

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

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

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

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

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

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

从前有Unix，在这个好的旧Unix中，进程有很多开销，所以一些聪明的人所做的是创建线程，这些线程将与父进程共享相同的地址空间，他们只需要减少上下文切换，这将使上下文切换更有效。

在当代的Linux (2.6.x)中，进程的上下文切换和线程的上下文切换在性能上没有太大的区别(只有MMU的东西对线程来说是额外的)。 共享地址空间存在问题，这意味着线程中的错误指针可能破坏同一地址空间中的父进程或另一个线程的内存。

一个进程受到MMU的保护，所以一个错误的指针只会导致一个信号11，而不会损坏。

我通常会使用进程(在Linux中没有太多的上下文切换开销，但是由于MMU的内存保护)，但是如果我需要一个实时调度器类，则会使用pthreads，这完全是另一回事。

为什么你认为线程在Linux上有这么大的性能提升?你有这方面的数据吗，还是说这只是一个神话?

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

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

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