事件起因

事情起因于公司一位同事在內(nèi)部郵件組中post了一個問題，一個使用了go1.8.3寫的業(yè)務(wù)程序跑了一段時間后出現(xiàn)部分goroutine卡在等待一個鎖ForkLock的現(xiàn)象，同事認(rèn)為這是go1.8.3的bug，升級到go1.10后沒有再重現(xiàn)。為了搞清楚這個事情，同事在github上發(fā)了issue https://github.com/golang/go/issues/26836，期間也做了很多重現(xiàn)的嘗試，但并未重現(xiàn)。

我瀏覽了一下出現(xiàn)該問題的業(yè)務(wù)代碼，大概的使用方式是父進程調(diào)用os/exec下的Command開子進程執(zhí)行shell命令。Command后面會調(diào)用golang封裝的forkExec來開子進程并執(zhí)行命令，forkExec使用了ForkLock。

問題分析

ForkLock 的存在是為了避免下面的情況：在有多個goroutine同時fork exec的情況下, 為了子進程只繼承它需要的文件描述符，需要在父進程在創(chuàng)建這些文件描述符的時候加上O_CLOEXEC標(biāo)志，這樣在子進程中這些描述符是關(guān)閉的，子進程按需把自己需要繼承的描述符打開即可。

Linux在2.6.27之后，打開文件或者管道，和設(shè)置O_CLOEXEC是一個原子操作，因此問題不大，但golang對內(nèi)核版本的要求是2.6.23及以上，另外Unix系統(tǒng)中，open和設(shè)置O_CLOEXEC是兩個操作，如果在兩個操作之間發(fā)生fork, 子進程就可能繼承它不需要的文件描述符，因此需要加鎖。重點看下forkExec時候的源代碼：

從問題的現(xiàn)象看，肯定是某goroutine在forkExecPipe或者forkAndExecInChild這兩步卡住了，鎖沒釋放，因此有些goroutine一直拿不到鎖，饑餓致死。forkExecPipe***調(diào)用的是內(nèi)核pipe2, forkAndExecInChild***調(diào)用的是內(nèi)核clone和exec。

原因猜測

pipe2是一個快速系統(tǒng)調(diào)用，因此可能block的系統(tǒng)調(diào)用是clone和exec, 加上在go1.10上這個問題沒有重現(xiàn)，對比go1.8代碼和go1.9在forkAndExecInChild函數(shù)上的差異:

go1.8

go1.9

go1.9增加了CLONE_VFORK和CLONE_VM 。只帶SIGCHILD的clone可以認(rèn)為類似于fork(***都是調(diào)用do_fork), fork的問題是，在父進程占用內(nèi)存越大性能越差，具體可以看這個鏈接：https://bugzilla.redhat.com/show_bug.cgi?id=682922

這個case 2011年提出，今年7月還在更新，這個case反饋的問題是，盡管Linux kernel 引入copy-on-write機制，但fork的時候依然要拷貝頁表，進程虛擬內(nèi)存越大，需要拷貝的頁表項越多，因此fork越慢。Golang的討論組有人測試過，heap size在2G的情況下，fork耗時可以到毫秒級別, 正常是及幾十微秒，上千倍差距。

Go1.9加上這兩個參數(shù)是為了讓子進程和父進程共享內(nèi)存，相當(dāng)于調(diào)用vfork, 不需要拷貝頁表, 加快創(chuàng)建速度，從測試效果看，穩(wěn)定在幾十微妙。

所以一個合理的猜測是，在低于go1.9版寫的程序中，當(dāng)程序內(nèi)存占用足夠大，而且創(chuàng)建進程頻率足夠頻繁，會導(dǎo)致ForkLock長時間等待。

實驗論證

我用go1.8.3寫了一個測試程序，在2核4G的虛擬機(kernel 3.10.0-693.17.1.el7.x86_64)下測試。

在外部每隔10秒，給這個程序發(fā)SIGUSR1信號，打印運行時堆棧，運行一段時間后，部分goroutine獲取ForkLock的時間越來越長。見下面兩圖：

而在go1.9及以上版本上并未出現(xiàn)上述情況，這個結(jié)果我覺得已經(jīng)可以說明問題。升級版本到go1.9及以上版本可以解決該問題。

寫在***

vfork是為了解決fork拷貝頁表項導(dǎo)致的性能問題, 而且大部分場景fork之后是調(diào)用exec，exec要把所有頁表刪除重置新的頁表, 實在沒必要再拷貝頁表項。但由于vfork父子進程共享內(nèi)存，所以使用要很小心，如果子進程修改某個變量，會影響到父進程，而且kernel會掛起父進程，讓子進程先執(zhí)行，這些限制基本限制vfork只適合跟exec的場景，不如fork通用。

正因為vfork的使用需要小心，因此go1.9準(zhǔn)備加入vfork發(fā)布之前，有人提出代碼不夠健壯，因為rawVforkSyscall返回之后，在父進程段還執(zhí)行指令，這樣子進程有機會破壞雙方的共享棧，因此提了一個commit去讓rawVforkSyscall在返回后，在父進程段什么都不做直接return，解決這個互相影響，如圖所示：

如有興趣深入了解，可以看下這個commit 的review，Rob Pike等人都有發(fā)言。

https://go-review.googlesource.com/c/go/+/46173