golang：多进程、多线程与协程的引入

心已赠人 2022-12-03 09:51 212阅读 0赞

# 为什么需要并发编程 #

在原生 PHP 中并没有并发的概念，所有的操作都是串行执行的、同步阻塞的，这也是很多人诟病 PHP 性能的原因，但是不支持并发编程的好处也是显而易见的：保证了 PHP 的简单性，开发者不必考虑并发引入的线程安全，也不需要在编程时权衡是否需要通过加锁来保证某个操作的原子性，也没有线程间通信问题，鱼和熊掌不可得兼，你不可能既要上手简单又要高性能，实际上，90%以上的公司和业务场景根本对性能没有那么高的要求，传统的 Nginx + PHP-FPM 完全可以胜任了，如果非要在 PHP 中实现异步和并发编程，推荐使用 Swoole 扩展来解决（实际上，Swoole 实现并发编程的协程功能正是借鉴了 Go 语言的协程实现机制）。

下面，我们书归正传，来介绍 Go 语言中并发编程的概念和实现。

与并发相对的是串行，即代码按照顺序一行一行执行，当遇到某个耗时的 IO 操作时，比如发送邮件、查询数据库等，要等到该 IO 操作完成后才能继续执行下一行代码，这在一些要求高并发高性能的业务场景中，显然是不合适的，从整个操作系统层面来说，多个任务是可以并发执行的，因为 CPU 本身通常是多核的，而且即使是单核 CPU，也可以通过时间分片的方式在多个进程/线程之间切换执行，从用户角度来说，就好像它们在「同时发生」一样，比如说，当程序执行到 IO 操作时，我们可以挂起这个任务，把 CPU 时间片出让给其他任务，然后当这个 IO 操作完成时，通知 CPU 恢复后续代码的执行，实际上 CPU 大部分时间都是在做这种调度。所以并发编程可以最大限度榨取 CPU 的价值，提高程序的执行效率和性能。

# 并发编程的常见实现 #

目前，主流的并发编程实现有以下几种方式：

*  **多进程**：多进程是在操作系统层面进行并发的基本模式，同时也是开销最大的模式。在Linux平台上，很多工具正是采用这种模式在工作，比如PHP-FPM，他会有专门的主进程负责网络端口的监听和连接管理，还会有多个工作进程负责具体的请求处理。这种方式的好处在于简单、进程之间互不影响，坏处在于系统开销大，因为所有的进程但是内核管理的，而且不同进程的数据也是相互隔离的
 *  **多线程**：多线程在大部分OS上都属于系统层面的并发模式，也就是我们使用最多的一种模式。目前，常见的几乎所有工具等会使用这种模式，线程比进程轻量级，线程之间可以共享数据，开销比多进程小很多，但是依旧比较大，而且在高并发模式下，效率会有影响，比如 C10K 问题，即支持 1 万个并发连接需要一万个线程，这不但对系统资源有较高的要求，还对 CPU 管理这些线程带来巨大负担。
 *  **基于回调的非阻塞/异步 IO**。为了解决 C10K 问题，在很多高并发服务器开发实践中，都会通过事件驱动的方式使用异步 IO，在这种模式下，一个线程可以维护多个 Socket 连接，从而降低系统开销，保持服务器的持续运转，它目前在 Node.js 中得到了很好的实践，实际上 Nginx 也使用了这种方式。但是使用这种模式，编程比多线程要复杂，通常需要借助 Linux 底层的库函数来实现。
 *  **协程**。协程（Coroutine）本质上是一种用户态线程，你可以把它看作轻量级的线程，不需要操作系统来进行抢占式调度，系统开销极小，可以有效提高线程的任务并发性，避免多线程的缺点。使用协程的优点是编程简单，结构清晰；缺点是需要语言级别的支持，如果不支持，则需要用户在程序中自行实现相应的调度器。目前，原生支持协程的语言还很少，Go 语言就是其中这一，Go 语言中的协程称作「goroutine」，并且使用语言名称本身 go 做为协程的关键字，足见其在 Go 语言中的举足轻重。PHP 的 Swoole 扩展也是参考了 Go 协程的实现将其搬到 PHP 中。

# 传统并发模式的缺陷 #

接下来我们先诠释一下传统并发模型的缺陷，之后再讲解 goroutine 并发模型是如何解决这些缺陷的。如果你之前只是熟悉 PHP 编程，没有接触过并发编程，那么需要好好消化下这些概念，学习完 Go 并发编程再回去看 Swoole 的协程，就非常驾轻就熟了。由于多进程比较消耗系统资源，且进程间数据隔离，CPU 切换成本高，因此，传统并发编程多以多线程为主，比如 Java 就是这么做的。下面我们重点探讨多线程与协程的对比。

我们之前在 PHP 中编程多是串行思维，串行的事务具有确定性，比如我们想好了123，然后按照这个顺序来编写代码，代码会严格按照这个设定的顺序执行，即使在某一个步骤阻塞了，也会一直等待阻塞代码执行完毕，再去执行下一步的代码。

多线程并发模式在这种确定性中引入了不确定性，比如我们原先设定的123，第2步是一个耗时操作，我们启动了一个新的线程来处理，这个时候就存在了两个并发的线程，即原来的主线程和第2步启动的新线程，主线程继续往后执行，第2、3步的代码并发执行，这个时候不确定性就来了，我们不知道主线程执行完毕的时候，新线程是否执行完毕了，如果主线程执行完毕退出应用，可能导致新线程的中断，或者我们在第3步的时候依赖第2步的某个返回结果，我们不知道啥时候能够返回这个结果，如果第2、3步有相互依赖的变量，甚至可能出现死锁，以及我们如何在主线程中获取新线程的异常和错误信息并进行相应的处理，等等，这种不确定性给程序的行为带来了意外和危害，也让程序变得不可控。

不同的线程好比平行时空，我们需要通过线程间通信来告知不同线程目前各自运行的状态和结果，以便使程序可控，线程之间通信可以通过共享内存的方式（参考 Swoole 中的 Swoole Table），即在不同线程中操作的是同一个内存地址上存储的值。为了保证共享内存的有效性，需要采取很多措施，比如加锁来避免死锁或资源竞争，还是以上面的主线程和新线程为例，如果我们在第1步获取了一个中间结果，第2步和第3步都要对这个中间结果进行操作，如果不加锁保证操作的原子性，很有可能产生脏数据。诸如此类的问题在生产环境极有可能造成重大故障甚至事故，而且不易察觉和调试。

我们可以将**线程加共享内存的方式称为“共享内存系统”**。为了解决共享内存系统存在的问题，计算机科学家又提出了“消息传递系统”。所谓\*\*“消息传递系统”指的是将线程间共享状态的各种操作都封装在线程之间传递的消息中，这通常要求发送消息时对状态进行复制，并且在消息传递的边界上交出这个状态的所有权\*\*。从表面上看，这个操作与“共享内存系统”中执行的通过加锁实现原子更新操作相同，但是从底层实现上来看则不同：**一个对同一个内存地址持有的值进行操作，一个是从消息通道读取数据并且处理**。由于需要执行状态复制操作，所以大多数消息传递的实现在性能上并不优越，但线程中的状态管理工作则会变得更加简单，这就有点像我们在开篇讲 PHP 不支持并发编程提到的那样，如果想让编码简单，性能就要做牺牲，如果想追求性能，代码编写起来就比较费劲，这也是我们为什么通常不会直接通过事件驱动的异步 IO 来实现并发编程一样，因为这涉及到直接调用操作系统底层的库函数（select、epoll、libevent 等）来实现，非常复杂。

> 注：最早被广泛应用的「消息传递系统」是由 C. A. R. Hoare 在他的 `Communicating Sequential Processes`中提出的，在 CSP 系统中，所有的并发操作都是通过独立线程以异步运行的方式来实现的。这些线程必须通过在彼此之间发送消息，从而向另一个线程请求信息或者将信息提供给另一个线程。

# Go 语言协程支持 #

与传统的系统级线程和进程相比，协程的最大优势在于轻量级（可以看作用户态的轻量级线程），我们可以轻松创建上百万个协程而不会导致系统资源衰竭，而线程和进程通常最多也不能超过 1 万个（C10K问题）。多数语言在语法层面并不直接支持协程，而是通过库的方式支持，比如 PHP 的 Swoole 扩展库，但用库的方式支持的功能通常并不完整，比如仅仅提供轻量级线程的创建、销毁与切换等能力。如果在这样的轻量级线程中调用一个同步 IO 操作，比如网络通信、本地文件读写，都会阻塞其他的并发执行轻量级线程，从而无法真正达到轻量级线程本身期望达到的目标。

Go 语言在语言级别支持协程，称之为 goroutine。Go 语言标准库提供的所有系统调用操作（当然也包括所有同步 IO 操作），都有协程的身影。**协程间的切换管理不依赖于系统的线程和进程，也不依赖于 CPU 的核心数量**，这让我们在 Go 语言中通过协程实现并发编程变得非常简单。

**Go 语言的协程系统是基于「消息传递系统」实现的**，在 Go 语言的编程哲学中，创始人 Rob Pike 推介「Don’t communicate by sharing memory, share memory by communicating（**不要通过共享内存来通信，而应该通过通信来共享内存**）」，这正是「消息传递系统」的精髓所在。**Go 语言中的 goroutine 和用于传递协程间消息的 channel 一起**，共同构筑了 Go 语言协程系统的基石。

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

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70_pic_center]: /images/20221123/009788e6e3b34cef87bd9db916cfbcfb.png