zz

ch8/ch8-06.md

@@ -59,7 +59,7 @@ https://golang.org/blog/
 
 最初的錯誤信息是一個讓人莫名的DNS査找失敗，卽使這個域名是完全可靠的。而隨後的錯誤信息揭示了原因：這個程序一次性創建了太多網絡連接，超過了每一個進程的打開文件數限製，旣而導致了在調用net.Dial像DNS査找失敗這樣的問題。
 
-這個程序實在是太他媽併行了。無窮無盡地併行化併不是什麽好事情，因爲不管怎麽説，你的繫統總是會有一個些限製因素，比如CPU覈心數會限製你的計算負載，比如你的硬盤轉軸和磁頭數限製了你的本地磁盤IO操作頻率，比如你的網絡帶寬限製了你的下載速度上限，或者是你的一個web服務的服務容量上限等等。爲了解決這個問題，我們可以限製併發程序所使用的資源來使之適應自己的運行環境。對於我們的例子來説，最簡單的方法就是限製對links.Extract在同一時間最多不會有超過n次調用，這里的n是fd的limit-20，一般情況下。這個一個夜店里限製客人數目是一個道理，隻有當有客人離開時，才會允許新的客人進入店內(譯註：作者你個老流氓)。
+這個程序實在是太他媽併行了。無窮無盡地併行化併不是什麽好事情，因爲不管怎麽説，你的繫統總是會有一個些限製因素，比如CPU核心數會限製你的計算負載，比如你的硬盤轉軸和磁頭數限製了你的本地磁盤IO操作頻率，比如你的網絡帶寬限製了你的下載速度上限，或者是你的一個web服務的服務容量上限等等。爲了解決這個問題，我們可以限製併發程序所使用的資源來使之適應自己的運行環境。對於我們的例子來説，最簡單的方法就是限製對links.Extract在同一時間最多不會有超過n次調用，這里的n是fd的limit-20，一般情況下。這個一個夜店里限製客人數目是一個道理，隻有當有客人離開時，才會允許新的客人進入店內(譯註：作者你個老流氓)。
 
 我們可以用一個有容量限製的buffered channel來控製併發，這類似於操作繫統里的計數信號量概念。從概念上講，channel里的n個空槽代表n個可以處理內容的token(通行證)，從channel里接收一個值會釋放其中的一個token，併且生成一個新的空槽位。這樣保證了在沒有接收介入時最多有n個發送操作。(這里可能我們拿channel里填充的槽來做token更直觀一些，不過還是這樣吧~)。由於channel里的元素類型併不重要，我們用一個零值的struct{}來作爲其元素。