fork在多线程下的使用

蔚落 2021-09-21 13:20 345阅读 0赞

## **多线程与多进程的选择** ##

关于多进程和多线程，教科书上最经典的一句话是“进程是资源分配的最小单位，线程是CPU调度的最小单位”，这句话应付考试基本上够了，但如果在工作中遇到类似的选择问题，那就没有这么简单了，选的不好，会让你深受其害。

经常在网络上看到有的XDJM问“多进程好还是多线程好？”、“Linux下用多进程还是多线程？”等等期望一劳永逸的问题，我只能说：没有最好，只有更好。根据实际情况来判断，哪个更加合适就是哪个好。

我们按照多个不同的维度，来看看多线程和多进程的对比（注：因为是感性的比较，因此都是相对的，不是说一个好得不得了，另外一个差的无法忍受）。

在这里插入图片描述  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTU2NjcwMA_size_16_color_FFFFFF_t_70]

1）需要频繁创建销毁的优先用线程

原因请看上面的对比。

这种原则最常见的应用就是Web服务器了，来一个连接建立一个线程，断了就销毁线程，要是用进程，创建和销毁的代价是很难承受的

2）需要进行大量计算的优先使用线程

所谓大量计算，当然就是要耗费很多CPU，切换频繁了，这种情况下线程是最合适的。

这种原则最常见的是图像处理、算法处理。

3）强相关的处理用线程，弱相关的处理用进程

什么叫强相关、弱相关？理论上很难定义，给个简单的例子就明白了。

一般的Server需要完成如下任务：消息收发、消息处理。“消息收发”和“消息处理”就是弱相关的任务，而“消息处理”里面可能又分为“消息解码”、“业务处理”，这两个任务相对来说相关性就要强多了。因此“消息收发”和“消息处理”可以分进程设计，“消息解码”、“业务处理”可以分线程设计。

当然这种划分方式不是一成不变的，也可以根据实际情况进行调整。

4）可能要扩展到多机分布的用进程，多核分布的用线程

原因请看上面对比。

5）都满足需求的情况下，用你最熟悉、最拿手的方式

至于“数据共享、同步”、“编程、调试”、“可靠性”这几个维度的所谓的“复杂、简单”应该怎么取舍，我只能说：没有明确的选择方法。但我可以告诉你一个选择原则：如果多进程和多线程都能够满足要求，那么选择你最熟悉、最拿手的那个。

需要提醒的是：虽然我给了这么多的选择原则，但实际应用中基本上都是“进程+线程”的结合方式，千万不要真的陷入一种非此即彼的误区。  
消耗资源：

从内核的观点看，进程的目的就是担当分配系统资源（CPU时间、内存等）的基本单位。线程是进程的一个执行流，是CPU调度和分派的基本单位，它是比进程更小的能独立运行的基本单位。

线程，它们彼此之间使用相同的地址空间，共享大部分数据，启动一个线程所花费的空间远远小于启动一个进程所花费的空间，而且，线程间彼此切换所需的时间也远远小于进程间切换所需要的时间。据统计，总的说来，一个进程的开销大约是一个线程开销的30倍左右，当然，在具体的系统上，这个数据可能会有较大的区别。

## [谨慎使用多线程中的fork][fork] ##

在单核时代，大家所编写的程序都是单进程/单线程程序。随着计算机硬件技术的发展，进入了多核时代后，为了降低响应时间，重复充分利用多核cpu的资源，使用多进程编程的手段逐渐被人们接受和掌握。然而因为创建一个进程代价比较大，多线程编程的手段也就逐渐被人们认可和喜爱了。

## 进程与线程模型 ##

进程的经典定义就是一个执行中的程序的实例。系统中的每个程序都是运行在某个进程的context中的。context是由程序正确运行所需的状态组成的，这个状态包括存放在存储器中的程序的代码和数据，它的栈、通用目的寄存器的内容、程序计数器（PC）、环境变量以及打开的文件描述符的集合。

进程主要提供给上层的应用程序两个抽象：

*  一个独立的逻辑控制流，它提供一个假象，好像我们程序独占的使用处理器。
 *  一个私有的虚拟地址空间，它提供一个假象，好像我们的程序独占的使用存储器系统。

线程，就是运行在进程context中的逻辑流。线程由内核自动调度。每个线程都有它自己的线程context，包括一个唯一的整数线程ID、栈、栈指针、程序计数器（PC）、通用目的寄存器和条件码。每个线程和运行在同一进程内的其他线程一起共享进程context的剩余部分。这包括整个用户虚拟地址空间，它是由只读文本（代码）、读/写数据、堆以及所有的共享库代码和数据区域组成。线程也同样共享打开文件的集合。

即进程是资源管理的最小单位，而线程是程序执行的最小单位。

在linux系统中，posix线程可以“看做”为一种轻量级的进程，pthread\_create创建线程和fork创建进程都是在内核中调用\_\_clone函数创建的，只不过创建线程或进程的时候选项不同，比如是否共享虚拟地址空间、文件描述符等。

## fork与多线程 ##

我们知道通过fork创建的一个子进程几乎但不完全与父进程相同。子进程得到与父进程用户级虚拟地址空间相同的（但是独立的）一份拷贝，包括文本、数据和bss段、堆以及用户栈等。子进程还获得与父进程任何打开文件描述符相同的拷贝，这就意味着子进程可以读写父进程中任何打开的文件，父进程和子进程之间最大的区别在于它们有着不同的PID。

但是有一点需要注意的是，在Linux中，fork的时候只复制当前线程到子进程，在[fork(2)-Linux Man Page][fork_2_-Linux Man Page]中有着这样一段相关的描述：

> The child process is created with a single thread--the one that called fork(). The entire virtual address space of the parent is replicated in the child, including the states of mutexes, condition variables, and other pthreads objects; the use of pthread\_atfork(3) may be helpful for dealing with problems that this can cause.

也就是说除了调用fork的线程外，其他线程在子进程中“蒸发”了。

这就是多线程中fork所带来的一切问题的根源所在了。

## 互斥锁 ##

互斥锁，就是多线程fork大部分问题的关键部分。

在大多数操作系统上，为了性能的因素，锁基本上都是实现在用户态的而非内核态（因为在用户态实现最方便，基本上就是通过原子操作或者之前文章中提到的memory barrier实现的），所以调用fork的时候，会复制父进程的所有锁到子进程中。

问题就出在这了。从操作系统的角度上看，对于每一个锁都有它的持有者，即对它进行lock操作的线程。假设在fork之前，一个线程对某个锁进行的lock操作，即持有了该锁，然后另外一个线程调用了fork创建子进程。可是在子进程中持有那个锁的线程却"消失"了，从子进程的角度来看，这个锁被“永久”的上锁了，因为它的持有者“蒸发”了。

那么如果子进程中的任何一个线程对这个已经被持有的锁进行lock操作话，就会发生死锁。

当然了有人会说可以在fork之前，让准备调用fork的线程获取所有的锁，然后再在fork出的子进程的中释放每一个锁。先不说现实中的业务逻辑以及其他因素允不允许这样做，这种做法会带来一个问题，那就是隐含了一种上锁的先后顺序，如果次序和平时不同，就会发生死锁。

如果你说自己一定可以按正确的顺序上锁而不出错的话，还有一个隐含的问题是你所不能控制的，那就是库函数。

因为你不能确定你所用到的所有库函数都不会使用共享数据，即他们都是完全线程安全的。有相当一部分线程安全的库函数都是在内部通过持有互斥锁的方式来实现的，比如几乎所有程序都会用到的C/C++标准库函数malloc、printf等等。

比如一个多线程程序在fork之前难免会分配动态内存，这就必然会用到malloc函数；而在fork之后的子进程中也难免要分配动态内存，这也同样要用到malloc，可这却是不安全的，因为有可能malloc内部的锁已经在fork之前被某一个线程所持有了，而那个线程却在子进程中消失了。

## exec与文件描述符 ##

按照上文的分析，似乎多线程中在fork出的子进程中立刻调用exec函数是唯一明智的选择了，其实即使这样做还是有一点不足。因为子进程会继承父进程中所有已打开的文件描述符，所以在执行exec之前子进程仍然可以读写父进程中的文件，但如果你不希望子进程能读写父进程里的某个已打开的文件该怎么办？

或许fcntl设置文件属性是一种办法：

<table> 
 <tbody> 
  <tr> 
   <td> <p>1</p> <p>2</p> <p>3</p> <p>4</p> <p>5</p> <p>6</p> </td> 
   <td> <p><code>int</code>&nbsp;<code>fd = open(</code><code>"file"</code><code>, O_RDWR | O_CREAT);</code></p> <p><code>if</code>&nbsp;<code>(fd &lt; 0)</code></p> <p><code>{ </code></p> <p><code>&nbsp;&nbsp;&nbsp;&nbsp;</code><code>perror</code><code>(</code><code>"open"</code><code>);</code></p> <p><code>}</code></p> <p><code>fcntl(fd, F_SETFD, FD_CLOEXEC);</code></p> </td> 
  </tr> 
 </tbody> 
</table>

但是如果在open打开file文件之后，调用fcntl设置CLOEXEC属性之前有其他线程fork出了子进程了的话，这个子进程仍然是可以读写file文件。如果用锁的话，就又回到了上文所讨论的情况了。

从Linux 2.6.23版本的内核开始，我们可以在open中设置O\_CLOEXEC标志了，相当于“打开文件再设置CLOEXEC”成为了一个原子操作。这样在fork出的子进程执行exec之前就不能读写父进程中已打开的文件了。

## pthread\_atfork ##

如果你不幸真的碰到了一个要解决多线程中fork的问题的时候，可以尝试使用pthread\_atfork：

<table> 
 <tbody> 
  <tr> 
   <td> <p>1</p> </td> 
   <td> <p><code>int</code>&nbsp;<code>pthread_atfork(</code><code>void</code>&nbsp;<code>(*prepare)(</code><code>void</code><code>),&nbsp;</code><code>void</code>&nbsp;<code>(*parent)</code><code>void</code><code>(),&nbsp;</code><code>void</code>&nbsp;<code>(*child)(</code><code>void</code><code>));</code></p> </td> 
  </tr> 
 </tbody> 
</table>

*  prepare处理函数由父进程在fork创建子进程前调用，这个函数的任务是获取父进程定义的所有锁。
 *  parent处理函数是在fork创建了子进程以后，但在fork返回之前在父进程环境中调用的。它的任务是对prepare获取的所有锁解锁。
 *  child处理函数在fork返回之前在子进程环境中调用，与parent处理函数一样，它也必须解锁所有prepare中所获取的锁。

因为子进程继承的是父进程的锁的拷贝，所有上述并不是解锁了两次，而是各自独自解锁。可以多次调用pthread\_atfork函数从而设置多套fork处理程序，但是使用多个处理程序的时候。处理程序的调用顺序并不相同。parent和child是以它们注册时的顺序调用的，而prepare的调用顺序与注册顺序相反。这样可以允许多个模块注册它们自己的处理程序并且保持锁的层次（类似于多个RAII对象的构造析构层次）。

需要注意的是pthread\_atfork只能清理锁，但不能清理条件变量。在有些系统的实现中条件变量不需要清理。但是在有的系统中，条件变量的实现中包含了锁，这种情况就需要清理。但是目前并没有清理条件变量的接口和方法。

## 结语 ##

*  在多线程程序中最好只用fork来执行exec函数，不要对fork出的子进程进行其他任何操作。
 *  如果确定要在多线程中通过fork出的子进程执行exec函数，那么在fork之前打开文件描述符时需要加上CLOEXEC标志。

## 参考文献 ##

1.  Randal E.Bryant, David O'Hallaron. [深入理解计算机系统(第2版). 机械工业出版社, 2010][2_. _ 2010]
2.  W.Richard Stevens. [UNIX环境高级编程(第3版), 人民邮电出版社, 2014][UNIX_3_ _ 2014]
3.  Linux Man Page. [fork(2)][fork_2_-Linux Man Page]
4.  Damian Pietras. [Threads and fork(): think twice before mixing them, 2009][Threads and fork_ think twice before mixing them_ 2009]
5.  云风. [极不和谐的 fork 多线程程序, 2011][fork _ 2011]

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTU2NjcwMA_size_16_color_FFFFFF_t_70]: /images/20210920/c06d2ce94a2649d4a04cb9f14d442c76.png
[fork]: https://www.cnblogs.com/liyuan989/p/4279210.html
[fork_2_-Linux Man Page]: http://linux.die.net/man/2/fork
[2_. _ 2010]: http://book.douban.com/subject/5333562/
[UNIX_3_ _ 2014]: http://book.douban.com/subject/25900403/
[Threads and fork_ think twice before mixing them_ 2009]: http://www.linuxprogrammingblog.com/threads-and-fork-think-twice-before-using-them
[fork _ 2011]: http://blog.codingnow.com/2011/01/fork_multi_thread.html