Update coroutine.

zh/coroutine.md

@@ -6,7 +6,7 @@ Hyperf 是运行于 `Swoole 4` 的协程之上的，这也是 Hyperf 能提供
 
 ### PHP-FPM 的运作模式
 
-在聊协程是什么之前，我们先聊聊传统 PHP-FPM 架构的运作模式，PHP-FPM 是一个多进程的 FastCGI 管理程序，是绝大多数 PHP 应用所使用的运行模式，假设我们使用Nginx提供 HTTP 服务（Apache同理），所有客户端发起的请求最先抵达的都是 Nginx，然后 Nginx 通过 FastCGI 协议将请求转发给 PHP-FPM 处理，PHP-FPM 的 Master进程 会为每个请求分配一个 Worker进程 来进行处理，这个处理指的就是，等待 PHP 脚本的解析，等待业务处理的结果返回，完成后回收子进程，这整个的过程是阻塞等待的，也就意味着 PHP-FPM 的进程数有多少能处理的请求也就是多少，假设 PHP-FPM 有200个 Worker进程，一个请求将耗费1秒的时间，那么简单的来说整个服务器理论上最多可以处理的请求也就是200个，QPS 即为200/s，在高并发的场景下，这样的性能往往是不够的，尽管可以利用 Nginx 作为负载均衡配合多台 PHP-FPM 服务器来提供服务，但由于 PHP-FPM 的阻塞等待的工作模型，一个请求会占用至少一个 MySQL 连接，多节点高并发下会产生大量的 MySQL 连接，而 MySQL 的最大连接数默认值为 100，尽管可以修改，但显而易见该模式没法很好的应对高并发的场景。
+在聊协程是什么之前，我们先聊聊传统 PHP-FPM 架构的运作模式，PHP-FPM 是一个多进程的 FastCGI 管理程序，是绝大多数 PHP 应用所使用的运行模式。假设我们使用 Nginx 提供 HTTP 服务（Apache同理），所有客户端发起的请求最先抵达的都是 Nginx，然后 Nginx 通过 FastCGI 协议将请求转发给 PHP-FPM 处理，PHP-FPM 的 Master进程 会为每个请求分配一个 Worker进程 来处理，这个处理指的就是，等待 PHP 脚本的解析，等待业务处理的结果返回，完成后回收子进程，这整个的过程是阻塞等待的，也就意味着 PHP-FPM 的进程数有多少能处理的请求也就是多少，假设 PHP-FPM 有200个 Worker进程，一个请求将耗费1秒的时间，那么简单的来说整个服务器理论上最多可以处理的请求也就是200个，QPS 即为200/s，在高并发的场景下，这样的性能往往是不够的，尽管可以利用 Nginx 作为负载均衡配合多台 PHP-FPM 服务器来提供服务，但由于 PHP-FPM 的阻塞等待的工作模型，一个请求会占用至少一个 MySQL 连接，多节点高并发下会产生大量的 MySQL 连接，而 MySQL 的最大连接数默认值为 100，尽管可以修改，但显而易见该模式没法很好的应对高并发的场景。
 
 ### 异步非阻塞系统
 
@@ -40,21 +40,19 @@ $db->connect($config, function ($db, $r) {
     });
 });
 ```
-从上面的代码片段可以看出，每一个操作几乎就需要一个回调函数，在复杂的业务场景中回调的层次感和代码结构绝对会让你崩溃，其实不难看出这样的写法有点类似 JavaScript 上的异步方法的写法，而 JavaScript 也为此提供了不少的解决方案（当然方案是源于其它编程语言），如 Promise，yield + generator, async/await，Promise 则是对回调的一种封装方式，而 yield + generator 和 async/await 则需要在代码上显性的增加一些代码语法标记，这些相对比回调函数来说，不妨都是一些非常不错的解决方案，除了你需要理解它的实现机制和语法之外。   
+从上面的代码片段可以看出，每一个操作几乎就需要一个回调函数，在复杂的业务场景中回调的层次感和代码结构绝对会让你崩溃，其实不难看出这样的写法有点类似 JavaScript 上的异步方法的写法，而 JavaScript 也为此提供了不少的解决方案（当然方案是源于其它编程语言），如 Promise，yield + generator, async/await，Promise 则是对回调的一种封装方式，而 yield + generator 和 async/await 则需要在代码上显性的增加一些代码语法标记，这些相对比回调函数来说，不妨都是一些非常不错的解决方案，但是你需要另花时间来理解它的实现机制和语法。   
 Swoole 协程也是对异步回调的一种解决方案，在 PHP 语言下，Swoole 协程与 yield + generator 都属于协程的解决方案，协程的解决方案可以使代码以近乎于同步代码的书写方式来书写异步代码，显性的区别则是 yield + generator 的协程机制下，每一处 I/O 操作的调用代码都需要在前面加上 yield 语法实现协程切换，每一层调用都需要加上，否则会出现意料之外的错误，而 Swoole 协程的解决方案对比于此就高明多了，在遇到 I/O 时底层自动的进行隐式协程切换，无需添加任何的额外语法，无需在代码前加上 yield，协程切换的过程无声无息，极大的减轻了维护异步系统的心智负担。
 
 ### 协程是什么？
 
-我们已经知道了协程可以很好的解决异步非阻塞系统的开发问题，那么协程本身到底是什么呢？从定义上来说，*协程是一种轻量级的线程，由用户代码来调度和管理，而不是由操作系统内核来进行调度，也就是在用户态进行*。可以直接的理解为就是一个非标准的线程实现，但什么时候切换由用户自己来实现，而不是由操作系统分配 CPU 时间决定，那么放在 Swoole 上来理解协程就是，Swoole 的每个 Worker进程 会存在一个协程调度器来调度协程，协程切换的时机就是遇到 I/O 操作或代码显性切换时，进程内以单线程的形式运行协程，也就意味着一个进程内同一时间只会有一个协程在运行且切换时机明确，也就无需处理像多线程编程下的各种同步锁的问题。   
+我们已经知道了协程可以很好的解决异步非阻塞系统的开发问题，那么协程本身到底是什么呢？从定义上来说，*协程是一种轻量级的线程，由用户代码来调度和管理，而不是由操作系统内核来进行调度，也就是在用户态进行*。可以直接的理解为就是一个非标准的线程实现，但什么时候切换由用户自己来实现，而不是由操作系统分配 CPU 时间决定。具体来说，Swoole 的每个 Worker进程 会存在一个协程调度器来调度协程，协程切换的时机就是遇到 I/O 操作或代码显性切换时，进程内以单线程的形式运行协程，也就意味着一个进程内同一时间只会有一个协程在运行且切换时机明确，也就无需处理像多线程编程下的各种同步锁的问题。   
 单个协程内的代码运行仍是串行的，放在一个 HTTP 协程服务上来理解就是每一个请求是一个协程，举个例子，假设为请求A创建了协程A，为请求B创建了协程B，那么在处理协程A的时候代码跑到了查询 MySQL 的语句上，这个时候协程A则会出发协程切换，协程A就继续等待 I/O 设备返回结果，那么此时就会切换到协程B，开始处理协程B的逻辑，当又遇到了一个 I/O 操作便又触发协程切换，再回过来从协程A刚才切走的地方继续执行，如此反复，遇到 I/O 操作就切换到另一个协程去继续执行而非一直阻塞等待。   
-这里可以发现一个问题就是，协程A的 MySQL 查询操作必须得是一个异步非阻塞的操作，否则会由于阻塞导致协程调度器没法切换到另一个协程继续执行，这个也是要在协程编程下需要规避的问题之一。
+这里可以发现一个问题就是，*协程A的 MySQL 查询操作必须得是一个异步非阻塞的操作，否则会由于阻塞导致协程调度器没法切换到另一个协程继续执行*，这个也是要在协程编程下需要规避的问题之一。
 
 ### 协程与普通线程有哪些区别？
 
 都说协程是一个轻量级的线程，协程和线程都适用于多任务的场景下，从这个角度上来说，协程与线程很相似，都有自己的上下文，可以共享全局变量，但不同之处在于，在同一时间可以有多个线程处于运行状态，但对于 Swoole 协程来说只能有一个，其它的协程都会处于暂停的状态。此外，普通线程是抢占式的，那个线程能得到资源由操作系统决定，而协程是协作式的，执行权由用户态自行分配。
 
-
-
 ## 协程编程注意事项
 
 ### 不能存在阻塞代码
@@ -82,7 +80,7 @@ Swoole 协程也是对异步回调的一种解决方案，在 PHP 语言下，Sw
 
 ### 创建一个协程
 
-只需通过 `go(callable $callback)` 函数或 `Hyperf\Coroutine::create(callable $callable)` 即可创建一个协程，协程内可以使用协程相关的方法和客户端。
+只需通过 `go(callable $callable)` 函数或 `Hyperf\Coroutine::create(callable $callable)` 即可创建一个协程，协程内可以使用协程相关的方法和客户端。
 
 ### 判断当前是否处于协程环境内