Go 是一个开源的编程语言，它能让构造简单、可靠且高效的软件变得容易。
Go是从2007年末由Robert Griesemer, Rob Pike, Ken Thompson主持开发，后来还加入了Ian Lance Taylor, Russ Cox等人，并最终于2009年11月开源，在2012年早些时候发布了Go 1稳定版本。现在Go的开发已经是完全开放的，并且拥有一个活跃的社区。
Go 语言特色
简洁、快速、安全
并行、有趣、开源
内存管理、数组安全、编译迅速
事件起因
事情起因于公司一位同事在内部邮件组中 post 了一个问题，一个使用了 go1.8.3 写的业务程序跑了一段时间后出现部分 goroutine 卡在等待一个锁 ForkLock 的现象，同事认为这是 go1.8.3 的 bug，升级到 go1.10 后没有再重现。为了搞清楚这个事情，同事在 github 上发了 issue：
期间也做了很多重现的尝试，但并未重现。
Go 语言用途
Go 语言被设计成一门应用于搭载 Web 服务器，存储集群或类似用途的巨型中央服务器的系统编程语言。
对于高性能分布式系统领域而言，Go 语言无疑比大多数其它语言有着更高的开发效率。它提供了海量并行的支持，这对于游戏服务端的开发而言是再好不过了。
我浏览了一下出现该问题的业务代码，大概的使用方式是父进程调用 os/exec 下的 Command 开子进程执行 shell 命令。Command 后面会调用 golang 封装的 forkExec 来开子进程并执行命令，forkExec 使用了 ForkLock。
问题分析
ForkLock 的存在是为了避免下面的情况：在有多个 goroutine 同时 fork exec 的情况下, 为了子进程只继承它需要的文件描述符，需要在父进程在创建这些文件描述符的时候加上 O_CLOEXEC 标志，这样在子进程中这些描述符是关闭的，子进程按需把自己需要继承的描述符打开即可。
Linux 在 2.6.27 之后，打开文件或者管道，和设置 O_CLOEXEC 是一个原子操作，因此问题不大，但 golang 对内核版本的要求是 2.6.23 及以上，另外 Unix 系统中，open 和设置 O_CLOEXEC 是两个操作，如果在两个操作之间发生 fork, 子进程就可能继承它不需要的文件描述符，因此需要加锁。重点看下 forkExec 时候的源代码：
从问题的现象看，肯定是某 goroutine 在 forkExecPipe 或者 forkAndExecInChild 这两步卡住了，锁没释放，因此有些 goroutine 一直拿不到锁，饥饿致死。forkExecPipe 最后调用的是内核 pipe2,forkAndExecInChild 最后调用的是内核 clone 和 exec。
原因猜测
pipe2 是一个快速系统调用，因此可能 block 的系统调用是 clone 和 exec, 加上在 go1.10 上这个问题没有重现，对比 go1.8 代码和 go1.9 在 forkAndExecInChild 函数上的差异:
go1.8
go1.9
go1.9 增加了 CLONE_VFORK 和 CLONE_VM。只带 SIGCHILD 的 clone 可以认为类似于 fork(最后都是调用 do_fork), fork 的问题是，在父进程占用内存越大性能越差，具体可以看这个链接：
https://bugzilla.redhat.com/show_bug.cgi?id=682922
这个 case 2011 年提出，今年 7 月还在更新，这个 case 反馈的问题是，尽管 Linux kernel 引入 copy-on-write 机制，但 fork 的时候依然要拷贝页表项，进程虚拟内存越大，需要拷贝的页表项越多，因此 fork 越慢。Golang 的讨论组有人测试过，heap size 在 2G 的情况下，fork 耗时可以到毫秒级别, 正常是及几十微秒，上千倍差距。
Go1.9 加上这两个参数是为了让子进程和父进程共享内存，相当于调用 vfork, 不需要拷贝页表项, 加快创建速度，从测试效果看，稳定在几十微妙。
所以一个合理的猜测是，在低于 go1.9 版写的程序中，当程序内存占用足够大，而且创建进程频率足够频繁，会导致 ForkLock 长时间等待。
实验论证
我用 go1.8.3 写了一个测试程序，在 2 核 4G 的虚拟机(kernel 3.10.0-693.17.1.el7.x86_64)下测试。
在外部每隔 10 秒，给这个程序发 SIGUSR1 信号，打印运行时堆栈，运行一段时间后，部分 goroutine 获取 ForkLock 的时间越来越长。见下面两图：
而在 go1.9 及以上版本上并未出现上述情况，这个结果我觉得已经可以说明问题。升级版本到 go1.9 及以上版本可以解决该问题。
写在最后
vfork 是为了解决 fork 拷贝页表项导致的性能问题, 而且大部分场景 fork 之后是调用 exec，exec 要把所有页表删除重置新的页表, 实在没必要再拷贝页表项。但由于 vfork 父子进程共享内存，所以使用要很小心，如果子进程修改某个变量，会影响到父进程，而且 kernel 会挂起父进程，让子进程先执行，这些限制基本限制 vfork 只适合跟 exec 的场景，不如 fork 通用。
正因为 vfork 的使用需要小心，因此 go1.9 准备加入 vfork 发布之前，有人提出代码不够健壮，因为 rawVforkSyscall 返回之后，在父进程段还执行指令，这样子进程有机会破坏双方的共享栈，因此提了一个 commit 去让 rawVforkSyscall 在返回后，在父进程段什么都不做直接 return，解决这个互相影响，如图所示：
如有兴趣深入了解，可以看下这个 commit 的 review，Rob Pike 等人都有发言。
https://go-review.googlesource.com/c/go/+/46173
fork函数为了创建新的子进程，fork函数被执行一次，但是返回值有两个，一个在父进程中返回，一个在子进程中返回，返回值在子进程中是0， 在父进程中是创建的子进程的PID， 在父进程中返回子进程的PID的原因是， 一个父进程可以有多个子进程， 然而没有方法通过其他方式获取子进程的PID， 为了对子进程有控制权， 所以在父进程中返回子进程的PID， fork出来的子进程会拷贝父进程的内存， 但是代码段这部分不会被拷贝到子进程， 因为子进程和父进程的代码段都相同， 且不会又修改， 现在的操作系统为了提高效率， 采用了COW(copy on write)， 即在写入的时候， 为了保持父进程和子进程的内存独立性， 会拷贝即将要写入的内存， 比如父进程要修改自己内存的某一个值， 此时就会将这个值所在的内存提前拷贝到子进程的内存空间， 这样父进程修改内存数据就不会对子进程的内存产生影响， 保证了fork出来的子进程内存和父进程内存的独立。
原文出处:ucloudtech
