Go 并发模型—Goroutines

前言

Goroutines 是 Go 语言主要的并发原语。它看起来非常像线程，但是相比于线程它的创建和管理成本很低。Go 在运行时将 goroutine 有效地调度到真实的线程上，以避免浪费资源，因此您可以轻松地创建大量的 goroutine（例如每个请求一个 goroutine），并且您可以编写简单的，命令式的阻塞代码。因此，Go 的网络代码往往比其它语言中的等效代码更直接，更容易理解（这点从下文中的示例代码可以看出）。

对我来说，goroutine 是将 Go 这门语言与其它语言区分开来的一个主要特征。这就是为什么大家更喜欢用 Go 来编写需要并发的代码。在下面讨论更多关于 goroutine 之前，我们先了解一些历史，这样你就能理解为什么你想要它们了。

基于 fork 和线程

高性能服务器需要同时处理来自多个客户端的请求。有很多方法可以设计一个服务端架构来处理这个问题。最容易想到的就是让一个主进程在循环中调用 accept，然后调用 fork 来创建一个处理请求的子进程。这篇 Beej’s Guide to Network Programming 指南中提到了这种方式。

在网络编程中，fork 是一个很好的模式，因为你可以专注于网络而不是服务器架构。但是它很难按照这种模式编写出一个高效的服务器，现在应该没有人在实践中使用这种方式了。

fork 同时也存在很多问题，首先第一个是成本: Linux 上的 fork 调用看起来很快，但它会将你所有的内存标记为 copy-on-write。每次写入 copy-on-write 页面都会导致一个小的页面错误，这是一个很难测量的小延迟，进程之间的上下文切换也很昂贵。

另一个问题是规模: 很难在大量子进程中协调共享资源（如 CPU、内存、数据库连接等）的使用。如果流量激增，并且创建了太多进程，那么它们将相互争夺 CPU。但是如果限制创建的进程数量，那么在 CPU 空闲时，大量缓慢的客户端可能会阻塞每个人的正常使用，这时使用超时机制会有所帮助（无论服务器架构如何，超时设置都是很必要的）。

通过使用线程而不是进程，上面这些问题在一定程度上能得到缓解。创建线程比创建进程更“便宜”，因为它共享内存和大多数其它资源。在共享地址空间中，线程之间的通信也相对容易，使用信号量和其它结构来管理共享资源，然而，线程仍然有很大的成本，如果你为每个连接创建一个新线程，你会遇到扩展问题。与进程一样，你此时需要限制正在运行的线程的数量，以避免严重的 CPU 争用，并且需要使慢速请求超时。创建一个新线程仍然需要时间，尽管可以通过使用线程池在请求之间回收线程来缓解这一问题。

无论你是使用进程还是线程，你仍然有一个难以回答的问题: **你应该创建多少个线程？**如果您允许无限数量的线程，客户端可能会用完所有的内存和 CPU，而流量