回到简体

ch8/ch8-09.md

@@ -1,14 +1,14 @@
-## 8.9. 併發的退出
+## 8.9. 并发的退出
 
-有時候我們需要通知goroutine停止它正在榦的事情，比如一個正在執行計算的web服務，然而它的客戶端已經斷開了和服務端的連接。
+有时候我们需要通知goroutine停止它正在干的事情，比如一个正在执行计算的web服务，然而它的客户端已经断开了和服务端的连接。
 
-Go語言併沒有提供在一個goroutine中終止另一個goroutine的方法，由於這樣會導致goroutine之間的共享變量落在未定義的狀態上。在8.7節中的rocket launch程序中，我們往名字叫abort的channel里發送了一個簡單的值，在countdown的goroutine中會把這個值理解爲自己的退出信號。但是如果我們想要退出兩個或者任意多個goroutine怎麽辦呢？
+Go语言并没有提供在一个goroutine中终止另一个goroutine的方法，由于这样会导致goroutine之间的共享变量落在未定义的状态上。在8.7节中的rocket launch程序中，我们往名字叫abort的channel里发送了一个简单的值，在countdown的goroutine中会把这个值理解为自己的退出信号。但是如果我们想要退出两个或者任意多个goroutine怎么办呢？
 
-一種可能的手段是向abort的channel里發送和goroutine數目一樣多的事件來退出它們。如果這些goroutine中已經有一些自己退出了，那麽會導致我們的channel里的事件數比goroutine還多，這樣導致我們的發送直接被阻塞。另一方面，如果這些goroutine又生成了其它的goroutine，我們的channel里的數目又太少了，所以有些goroutine可能會無法接收到退出消息。一般情況下我們是很難知道在某一個時刻具體有多少個goroutine在運行着的。另外，當一個goroutine從abort channel中接收到一個值的時候，他會消費掉這個值，這樣其它的goroutine就沒法看到這條信息。爲了能夠達到我們退出goroutine的目的，我們需要更靠譜的策略，來通過一個channel把消息廣播出去，這樣goroutine們能夠看到這條事件消息，併且在事件完成之後，可以知道這件事已經發生過了。
+一种可能的手段是向abort的channel里发送和goroutine数目一样多的事件来退出它们。如果这些goroutine中已经有一些自己退出了，那么会导致我们的channel里的事件数比goroutine还多，这样导致我们的发送直接被阻塞。另一方面，如果这些goroutine又生成了其它的goroutine，我们的channel里的数目又太少了，所以有些goroutine可能会无法接收到退出消息。一般情况下我们是很难知道在某一个时刻具体有多少个goroutine在运行着的。另外，当一个goroutine从abort channel中接收到一个值的时候，他会消费掉这个值，这样其它的goroutine就没法看到这条信息。为了能够达到我们退出goroutine的目的，我们需要更靠谱的策略，来通过一个channel把消息广播出去，这样goroutine们能够看到这条事件消息，并且在事件完成之后，可以知道这件事已经发生过了。
 
-迴憶一下我們關閉了一個channel併且被消費掉了所有已發送的值，操作channel之後的代碼可以立卽被執行，併且會産生零值。我們可以將這個機製擴展一下，來作爲我們的廣播機製：不要向channel發送值，而是用關閉一個channel來進行廣播。
+回忆一下我们关闭了一个channel并且被消费掉了所有已发送的值，操作channel之后的代码可以立即被执行，并且会产生零值。我们可以将这个机制扩展一下，来作为我们的广播机制：不要向channel发送值，而是用关闭一个channel来进行广播。
 
-隻要一些小脩改，我們就可以把退出邏輯加入到前一節的du程序。首先，我們創建一個退出的channel，這個channel不會向其中發送任何值，但其所在的閉包內要寫明程序需要退出。我們同時還定義了一個工具函數，cancelled，這個函數在被調用的時候會輪詢退出狀態。
+只要一些小修改，我们就可以把退出逻辑加入到前一节的du程序。首先，我们创建一个退出的channel，这个channel不会向其中发送任何值，但其所在的闭包内要写明程序需要退出。我们同时还定义了一个工具函数，cancelled，这个函数在被调用的时候会轮询退出状态。
 
 <u><i>gopl.io/ch8/du4</i></u>
 ```go
@@ -24,7 +24,7 @@ func cancelled() bool {
 }
 ```
 
-下面我們創建一個從標準輸入流中讀取內容的goroutine，這是一個比較典型的連接到終端的程序。每當有輸入被讀到(比如用戶按了迴車鍵)，這個goroutine就會把取消消息通過關閉done的channel廣播出去。
+下面我们创建一个从标准输入流中读取内容的goroutine，这是一个比较典型的连接到终端的程序。每当有输入被读到(比如用户按了回车键)，这个goroutine就会把取消消息通过关闭done的channel广播出去。
 
 ```go
 // Cancel traversal when input is detected.
@@ -34,7 +34,7 @@ go func() {
 }()
 ```
 
-現在我們需要使我們的goroutine來對取消進行響應。在main goroutine中，我們添加了select的第三個case語句，嚐試從done channel中接收內容。如果這個case被滿足的話，在select到的時候卽會返迴，但在結束之前我們需要把fileSizes channel中的內容“排”空，在channel被關閉之前，舍棄掉所有值。這樣可以保證對walkDir的調用不要被向fileSizes發送信息阻塞住，可以正確地完成。
+现在我们需要使我们的goroutine来对取消进行响应。在main goroutine中，我们添加了select的第三个case语句，尝试从done channel中接收内容。如果这个case被满足的话，在select到的时候即会返回，但在结束之前我们需要把fileSizes channel中的内容“排”空，在channel被关闭之前，舍弃掉所有值。这样可以保证对walkDir的调用不要被向fileSizes发送信息阻塞住，可以正确地完成。
 
 ```go
 for {
@@ -51,7 +51,7 @@ for {
 }
 ```
 
-walkDir這個goroutine一啟動就會輪詢取消狀態，如果取消狀態被設置的話會直接返迴，併且不做額外的事情。這樣我們將所有在取消事件之後創建的goroutine改變爲無操作。
+walkDir这个goroutine一启动就会轮询取消状态，如果取消状态被设置的话会直接返回，并且不做额外的事情。这样我们将所有在取消事件之后创建的goroutine改变为无操作。
 
 ```go
 func walkDir(dir string, n *sync.WaitGroup, fileSizes chan<- int64) {
@@ -65,9 +65,9 @@ func walkDir(dir string, n *sync.WaitGroup, fileSizes chan<- int64) {
 }
 ```
 
-在walkDir函數的循環中我們對取消狀態進行輪詢可以帶來明顯的益處，可以避免在取消事件發生時還去創建goroutine。取消本身是有一些代價的；想要快速的響應需要對程序邏輯進行侵入式的脩改。確保在取消發生之後不要有代價太大的操作可能會需要脩改你代碼里的很多地方，但是在一些重要的地方去檢査取消事件也確實能帶來很大的好處。
+在walkDir函数的循环中我们对取消状态进行轮询可以带来明显的益处，可以避免在取消事件发生时还去创建goroutine。取消本身是有一些代价的；想要快速的响应需要对程序逻辑进行侵入式的修改。确保在取消发生之后不要有代价太大的操作可能会需要修改你代码里的很多地方，但是在一些重要的地方去检查取消事件也确实能带来很大的好处。
 
-對這個程序的一個簡單的性能分析可以揭示瓶頸在dirents函數中獲取一個信號量。下面的select可以讓這種操作可以被取消，併且可以將取消時的延遲從幾百毫秒降低到幾十毫秒。
+对这个程序的一个简单的性能分析可以揭示瓶颈在dirents函数中获取一个信号量。下面的select可以让这种操作可以被取消，并且可以将取消时的延迟从几百毫秒降低到几十毫秒。
 
 ```go
 func dirents(dir string) []os.FileInfo {
@@ -81,8 +81,8 @@ func dirents(dir string) []os.FileInfo {
 }
 ```
 
-現在當取消發生時，所有後台的goroutine都會迅速停止併且主函數會返迴。當然，當主函數返迴時，一個程序會退出，而我們又無法在主函數退出的時候確認其已經釋放了所有的資源(譯註：因爲程序都退出了，你的代碼都沒法執行了)。這里有一個方便的竅門我們可以一用：取代掉直接從主函數返迴，我們調用一個panic，然後runtime會把每一個goroutine的棧dump下來。如果main goroutine是唯一一個剩下的goroutine的話，他會清理掉自己的一切資源。但是如果還有其它的goroutine沒有退出，他們可能沒辦法被正確地取消掉，也有可能被取消但是取消操作會很花時間；所以這里的一個調研還是很有必要的。我們用panic來獲取到足夠的信息來驗證我們上面的判斷，看看最終到底是什麽樣的情況。
+现在当取消发生时，所有后台的goroutine都会迅速停止并且主函数会返回。当然，当主函数返回时，一个程序会退出，而我们又无法在主函数退出的时候确认其已经释放了所有的资源(译注：因为程序都退出了，你的代码都没法执行了)。这里有一个方便的窍门我们可以一用：取代掉直接从主函数返回，我们调用一个panic，然后runtime会把每一个goroutine的栈dump下来。如果main goroutine是唯一一个剩下的goroutine的话，他会清理掉自己的一切资源。但是如果还有其它的goroutine没有退出，他们可能没办法被正确地取消掉，也有可能被取消但是取消操作会很花时间；所以这里的一个调研还是很有必要的。我们用panic来获取到足够的信息来验证我们上面的判断，看看最终到底是什么样的情况。
 
-**練習 8.10：** HTTP請求可能會因http.Request結構體中Cancel channel的關閉而取消。脩改8.6節中的web crawler來支持取消http請求。（提示：http.Get併沒有提供方便地定製一個請求的方法。你可以用http.NewRequest來取而代之，設置它的Cancel字段，然後用http.DefaultClient.Do(req)來進行這個http請求。）
+**练习 8.10：** HTTP请求可能会因http.Request结构体中Cancel channel的关闭而取消。修改8.6节中的web crawler来支持取消http请求。（提示：http.Get并没有提供方便地定制一个请求的方法。你可以用http.NewRequest来取而代之，设置它的Cancel字段，然后用http.DefaultClient.Do(req)来进行这个http请求。）
 
-**練習 8.11：** 緊接着8.4.4中的mirroredQuery流程，實現一個併發請求url的fetch的變種。當第一個請求返迴時，直接取消其它的請求。
+**练习 8.11：** 紧接着8.4.4中的mirroredQuery流程，实现一个并发请求url的fetch的变种。当第一个请求返回时，直接取消其它的请求。