« 有关英语阅读 | 返回首页 | 顿悟？ »

极不和谐的 fork 多线程程序

继续前几天的话题。做梦幻西游服务器优化的事情。以往的代码，定期存盘的工作分两个步骤，把 VM 里的动态数据序列化，然后把序列化后的数据写盘。这两个步骤，序列化工作并没有独立在单独线程/进程里做，而是放在主线程的。IO 部分则在一个独立进程中。

序列化任务是个繁琐的过程。非常耗时（相对于 MMORPG 这个需要对用户请求快速反应的环境）。当玩家同时在线人数升高时，一个简便的优化方法是把整个序列化任务分步完成，分摊到多个心跳内。这里虽然有一些数据一致性问题，但也有不同的手段解决。

但是，在线人数达到一定后，序列化过程依然会对系统性能造成较大影响。在做定期存盘时，玩家的输入反应速度明显变大。表现得是游戏服务器周期性的卡。为了缓解这一点，我希望改造系统，把序列化任务分离到独立进程去做。

方法倒是很简单，在定期存盘一刻，调用 fork ，然后在子进程中慢慢的做序列化工作。（可以考虑使用 nice）做完后，再把数据交到 IO 进程写盘。不过鉴于我们前期设计的问题，具体实现中，我需要通过共享内存把序列化结果交还父进程，由父进程送去 IO 进程。

因为 fork 会产生一个内存快照，所以甚至没有数据一致性问题。这应该是一个网络游戏用到的常见模式。

可问题就出在于，经过历史变迁，我们的服务器已经使用了多线程，这使得 fork 子进程的做法变的不那么可靠，需要自己推敲一下。

多进程的多线程程序，听起来多不靠谱。真是闲得淡疼的人才会做此设计。但依旧可以使用万能的推辞：历史造成的。

在 POSIX 标准中，fork 的行为是这样的：复制整个用户空间的数据（通常使用 copy-on-write 的策略，所以可以实现的速度很快）以及所有系统对象，然后仅复制当前线程到子进程。这里：所有父进程中别的线程，到了子进程中都是突然蒸发掉的。

其它线程的突然消失，是一切问题的根源。

我之前从未写过多进程多线程程序，不过公司里有 David Xu 同学（他实现维护着 FreeBSD 的线程库）是这方面的专家，今天跟徐同学讨论了一下午，终于觉得自己搞明白了其中的纠结。嗯，写点东西整理一下思路。

可能产生的最严重的问题是锁的问题。

因为为了性能，大部分系统的锁是实现在用户空间的。所以锁对象会因为 fork 复制到子进程中。

对于锁来说，从 OS 看，每个锁有一个所有者，即最后一次 lock 它的线程。

假设这么一个环境，在 fork 之前，有一个子线程 lock 了某个锁，获得了对锁的所有权。fork 以后，在子进程中，所有的额外线程都人间蒸发了。而锁却被正常复制了，在子进程看来，这个锁没有主人，所以没有任何人可以对它解锁。

当子进程想 lock 这个锁时，不再有任何手段可以解开了。程序发生死锁。

为何，POSIX 指定标准时，会定下这么一个显然不靠谱的规则？允许复制一个完全死掉的锁？答案是历史和性能。因为历史上，把锁实现在用户态是最方便的（今天依旧如此）。背后可能只需要一条原子操作指令即可。大多数 CPU 都支持的。fork 只管用户空间的复制，不会涉及其中的对象细节。

一般的惯例，多线程程序 fork 前，应该由发起 fork 的线程 lock 所有子进程可能用到的锁，fork 后，把它们一一 unlock 。当然，这样的做法就隐含了锁的次序。如果次序和平时不同，那么就会死锁。

不光是显式的使用锁，许多 CRT 函数也会间接的使用。比如 fprintf 这些文件操作。因为对 FILE * 的操作是依靠锁来达到线程安全的。最常见的问题是在子线程里调用 fprintf 写 log 。

除此之外，就是要小心一些不依赖锁的数据一致性问题了。比如若在父进程里另一个线程中操作一个链表，fork 发生时，因为其它线程的突然消失，这个链表就可能会因为只操作了一半而是不完整的数据。不过这一般不会是问题，或者可以归咎于对锁的处理。（多个线程，访问同一块数据。比如一条链表。就是需要加锁的）

最后引用讨论中， David Xu 的话 “POSIX这个问题一直是讨论的热门话题。而且双方立场很清楚，一方是使用者，另外一方是实现者，双方互相指责”

突然想到，lua / java 这些 VM 的实现，是不是可以利用 fork 来缓解 gc 造成的停滞呢？只需要在 gc 时，fork 一份出来做扫描。找到不被引用的垃圾，

云风 提交于 January 26, 2011 05:49 PM |

Comments

这么多年过去了，不知道博主是否有解决这个问题的方案了？我目前也遇到这种问题，想从一个可能是多线程环境的进程中dump出内存快照，打算采用fork的方式。

Posted by: zzy | (15) June 21, 2020 04:05 PM

Thank you for your sharing

Posted by: ed hardy clothing | (14) May 15, 2012 02:27 PM

序列化任务是个繁琐的过程

Posted by: Anonymous | (13) April 18, 2012 04:47 PM

I met this situation too. After fork(), all thread were disappeard and the thread condition led hang. This blog is very helpful for me to understand the issue. Thanks.

Posted by: patric | (12) July 26, 2011 05:48 PM

1.主线程将增量数据交给新线程（swap，不是复制哦，前提是增量） 2.新线程处理序列化任务 3.新线程将处理结果交给主线程（同样不是复制） 4.主线程提交io操作

Posted by: ralph lauren polo | (11) February 21, 2011 11:15 AM

在多线程程序里使用fork是比较郁闷的事情； 不只是应用层的锁的问题； 很多C库里的函数调用也会出现死锁线程； 最好的办法是在多线程进程里不是用fork； 如果非使用不可，尽量fork完毕后直接exec，不调用任何其他除了fork之外的函数； exec可以覆盖内存空间，可以解决所有关于锁的问题；

Posted by: heyingstar [TypeKey Profile Page] | (10) February 14, 2011 09:17 PM

先fork()后再用pthread，唯一的可移植用法。

Posted by: Jordan Fung | (9) January 28, 2011 11:23 AM

考虑再开个线程做序列化

Posted by: bristol | (8) January 27, 2011 08:13 PM

jvm的gc有多线程的策略，而且就是需要在多cpu的条件下，性能能提高

Posted by: Anonymous | (7) January 27, 2011 05:39 PM

你是想仿redis的策略？

Posted by: snnn | (6) January 27, 2011 01:57 PM

忘了，只有一个进程了，应该可以由新线程提交io操作吧 1.主线程将增量数据交给新线程（swap，不是复制哦，前提是增量） 2.新线程处理序列化任务 3.新线程提交io操作

Posted by: zcpro | (5) January 27, 2011 10:20 AM

如果要序列化的数据是按增量记录的，是否可考虑再开个线程做序列化。多线程加多进程想想就恐怖。 1.主线程将增量数据交给新线程（swap，不是复制哦，前提是增量） 2.新线程处理序列化任务 3.新线程将处理结果交给主线程（同样不是复制） 4.主线程提交io操作

Posted by: zcpro | (4) January 27, 2011 10:16 AM

可以在子进程的serialize代码中避免使用lock。

Posted by: middleware | (3) January 27, 2011 10:16 AM

为啥不用Erlang/OTP

Posted by: Anonymous | (2) January 26, 2011 07:52 PM

如果使用MMAP有帮助吗？或者共享内存，有另外一个进程来做持续化。

Posted by: Anonymous | (1) January 26, 2011 07:02 PM

Post a comment

非这个主题相关的留言请到：留言本