make loop

ch9/ch9-02.md

@@ -1,6 +1,6 @@
 ## 9.2. sync.Mutex互斥鎖
 
-在8.6节中，我们使用了一个buffered channel作为一个计数信号量，来保证最多只有20个goroutine会同时执行HTTP请求。同理，我们可以用一个容量只有1的channel来保证最多只有一个goroutine在同一时刻访问一个共享变量。一个只能为1和0的信号量叫做二元信号量(binary semaphore)。
+在8.6節中，我們使用了一個buffered channel作爲一個計數信號量，來保證最多隻有20個goroutine會同時執行HTTP請求。同理，我們可以用一個容量隻有1的channel來保證最多隻有一個goroutine在同一時刻訪問一個共享變量。一個隻能爲1和0的信號量叫做二元信號量(binary semaphore)。
 
 ```go
 gopl.io/ch9/bank2
@@ -23,7 +23,7 @@ func Balance() int {
 }
 ```
 
-这种互斥很实用，而且被sync包里的Mutex类型直接支持。它的Lock方法能够获取到token(这里叫锁)，并且Unlock方法会释放这个token：
+這種互斥很實用，而且被sync包里的Mutex類型直接支持。它的Lock方法能夠獲取到token(這里叫鎖)，併且Unlock方法會釋放這個token：
 
 ```go
 gopl.io/ch9/bank3
@@ -48,13 +48,13 @@ func Balance() int {
 }
 ```
 
-每次一个goroutine访问bank变量时(这里只有balance余额变量)，它都会调用mutex的Lock方法来获取一个互斥锁。如果其它的goroutine已经获得了这个锁的话，这个操作会被阻塞直到其它goroutine调用了Unlock使该锁变回可用状态。mutex会保护共享变量。惯例来说，被mutex所保护的变量是在mutex变量声明之后立刻声明的。如果你的做法和惯例不符，确保在文档里对你的做法进行说明。
+每次一個goroutine訪問bank變量時(這里隻有balance餘額變量)，它都會調用mutex的Lock方法來獲取一個互斥鎖。如果其它的goroutine已經獲得了這個鎖的話，這個操作會被阻塞直到其它goroutine調用了Unlock使該鎖變迴可用狀態。mutex會保護共享變量。慣例來説，被mutex所保護的變量是在mutex變量聲明之後立刻聲明的。如果你的做法和慣例不符，確保在文檔里對你的做法進行説明。
 
-在Lock和Unlock之间的代码段中的内容goroutine可以随便读取或者修改，这个代码段叫做临界区。goroutine在结束后释放锁是必要的，无论以哪条路径通过函数都需要释放，即使是在错误路径中，也要记得释放。
+在Lock和Unlock之間的代碼段中的內容goroutine可以隨便讀取或者脩改，這個代碼段叫做臨界區。goroutine在結束後釋放鎖是必要的，無論以哪條路徑通過函數都需要釋放，卽使是在錯誤路徑中，也要記得釋放。
 
-上面的bank程序例证了一种通用的并发模式。一系列的导出函数封装了一个或多个变量，那么访问这些变量唯一的方式就是通过这些函数来做(或者方法，对于一个对象的变量来说)。每一个函数在一开始就获取互斥锁并在最后释放锁，从而保证共享变量不会被并发访问。这种函数、互斥锁和变量的编排叫作监控monitor(这种老式单词的monitor是受"monitor goroutine"的术语启发而来的。两种用法都是一个代理人保证变量被顺序访问)。
+上面的bank程序例證了一種通用的併發模式。一繫列的導出函數封裝了一個或多個變量，那麽訪問這些變量唯一的方式就是通過這些函數來做(或者方法，對於一個對象的變量來説)。每一個函數在一開始就獲取互斥鎖併在最後釋放鎖，從而保證共享變量不會被併發訪問。這種函數、互斥鎖和變量的編排叫作監控monitor(這種老式單詞的monitor是受"monitor goroutine"的術語啟發而來的。兩種用法都是一個代理人保證變量被順序訪問)。
 
-由于在存款和查询余额函数中的临界区代码这么短--只有一行，没有分支调用--在代码最后去调用Unlock就显得更为直截了当。在更复杂的临界区的应用中，尤其是必须要尽早处理错误并返回的情况下，就很难去(靠人)判断对Lock和Unlock的调用是在所有路径中都能够严格配对的了。Go语言里的defer简直就是这种情况下的救星：我们用defer来调用Unlock，临界区会隐式地延伸到函数作用域的最后，这样我们就从“总要记得在函数返回之后或者发生错误返回时要记得调用一次Unlock”这种状态中获得了解放。Go会自动帮我们完成这些事情。
+由於在存款和査詢餘額函數中的臨界區代碼這麽短--隻有一行，沒有分支調用--在代碼最後去調用Unlock就顯得更爲直截了當。在更複雜的臨界區的應用中，尤其是必鬚要盡早處理錯誤併返迴的情況下，就很難去(靠人)判斷對Lock和Unlock的調用是在所有路徑中都能夠嚴格配對的了。Go語言里的defer簡直就是這種情況下的救星：我們用defer來調用Unlock，臨界區會隱式地延伸到函數作用域的最後，這樣我們就從“總要記得在函數返迴之後或者發生錯誤返迴時要記得調用一次Unlock”這種狀態中獲得了解放。Go會自動幫我們完成這些事情。
 
 
 ```go
@@ -65,11 +65,11 @@ func Balance() int {
 }
 ```
 
-上面的例子里Unlock会在return语句读取完balance的值之后执行，所以Balance函数是并发安全的。这带来的另一点好处是，我们再也不需要一个本地变量b了。
+上面的例子里Unlock會在return語句讀取完balance的值之後執行，所以Balance函數是併發安全的。這帶來的另一點好處是，我們再也不需要一個本地變量b了。
 
-此外，一个deferred Unlock即使在临界区发生panic时依然会执行，这对于用recover (§5.10)来恢复的程序来说是很重要的。defer调用只会比显式地调用Unlock成本高那么一点点，不过却在很大程度上保证了代码的整洁性。大多数情况下对于并发程序来说，代码的整洁性比过度的优化更重要。如果可能的话尽量使用defer来将临界区扩展到函数的结束。
+此外，一個deferred Unlock卽使在臨界區發生panic時依然會執行，這對於用recover (§5.10)來恢複的程序來説是很重要的。defer調用隻會比顯式地調用Unlock成本高那麽一點點，不過卻在很大程度上保證了代碼的整潔性。大多數情況下對於併發程序來説，代碼的整潔性比過度的優化更重要。如果可能的話盡量使用defer來將臨界區擴展到函數的結束。
 
-考虑一下下面的Withdraw函数。成功的时候，它会正确地减掉余额并返回true。但如果银行记录资金对交易来说不足，那么取款就会恢复余额，并返回false。
+考慮一下下面的Withdraw函數。成功的時候，它會正確地減掉餘額併返迴true。但如果銀行記録資金對交易來説不足，那麽取款就會恢複餘額，併返迴false。
 
 ```go
 // NOTE: not atomic!
@@ -83,9 +83,9 @@ func Withdraw(amount int) bool {
 }
 ```
 
-函数终于给出了正确的结果，但是还有一点讨厌的副作用。当过多的取款操作同时执行时，balance可能会瞬时被减到0以下。这可能会引起一个并发的取款被不合逻辑地拒绝。所以如果Bob尝试买一辆sports car时，Alice可能就没办法为她的早咖啡付款了。这里的问题是取款不是一个原子操作：它包含了三个步骤，每一步都需要去获取并释放互斥锁，但任何一次锁都不会锁上整个取款流程。
+函數終於給出了正確的結果，但是還有一點討厭的副作用。當過多的取款操作同時執行時，balance可能會瞬時被減到0以下。這可能會引起一個併發的取款被不合邏輯地拒絶。所以如果Bob嚐試買一輛sports car時，Alice可能就沒辦法爲她的早咖啡付款了。這里的問題是取款不是一個原子操作：它包含了三個步驟，每一步都需要去獲取併釋放互斥鎖，但任何一次鎖都不會鎖上整個取款流程。
 
-理想情况下，取款应该只在整个操作中获得一次互斥锁。下面这样的尝试是错误的：
+理想情況下，取款應該隻在整個操作中獲得一次互斥鎖。下面這樣的嚐試是錯誤的：
 
 ```go
 // NOTE: incorrect!
@@ -101,11 +101,11 @@ func Withdraw(amount int) bool {
 }
 ```
 
-上面这个例子中，Deposit会调用mu.Lock()第二次去获取互斥锁，但因为mutex已经锁上了，而无法被重入(译注：go里没有重入锁，关于重入锁的概念，请参考java)--也就是说没法对一个已经锁上的mutex来再次上锁--这会导致程序死锁，没法继续执行下去，Withdraw会永远阻塞下去。
+上面這個例子中，Deposit會調用mu.Lock()第二次去獲取互斥鎖，但因爲mutex已經鎖上了，而無法被重入(譯註：go里沒有重入鎖，關於重入鎖的概念，請參考java)--也就是説沒法對一個已經鎖上的mutex來再次上鎖--這會導致程序死鎖，沒法繼續執行下去，Withdraw會永遠阻塞下去。
 
-关于Go的互斥量不能重入这一点我们有很充分的理由。互斥量的目的是为了确保共享变量在程序执行时的关键点上能够保证不变性。不变性的其中之一是“没有goroutine访问共享变量”。但实际上对于mutex保护的变量来说，不变性还包括其它方面。当一个goroutine获得了一个互斥锁时，它会断定这种不变性能够被保持。其获取并保持锁期间，可能会去更新共享变量，这样不变性只是短暂地被破坏。然而当其释放锁之后，它必须保证不变性已经恢复原样。尽管一个可以重入的mutex也可以保证没有其它的goroutine在访问共享变量，但这种方式没法保证这些变量额外的不变性。(译注：这段翻译有点晕)
+關於Go的互斥量不能重入這一點我們有很充分的理由。互斥量的目的是爲了確保共享變量在程序執行時的關鍵點上能夠保證不變性。不變性的其中之一是“沒有goroutine訪問共享變量”。但實際上對於mutex保護的變量來説，不變性還包括其它方面。當一個goroutine獲得了一個互斥鎖時，它會斷定這種不變性能夠被保持。其獲取併保持鎖期間，可能會去更新共享變量，這樣不變性隻是短暫地被破壞。然而當其釋放鎖之後，它必鬚保證不變性已經恢複原樣。盡管一個可以重入的mutex也可以保證沒有其它的goroutine在訪問共享變量，但這種方式沒法保證這些變量額外的不變性。(譯註：這段翻譯有點暈)
 
-一个通用的解决方案是将一个函数分离为多个函数，比如我们把Deposit分离成两个：一个不导出的函数deposit，这个函数假设锁总是会被保持并去做实际的操作，另一个是导出的函数Deposit，这个函数会调用deposit，但在调用前会先去获取锁。同理我们可以将Withdraw也表示成这种形式：
+一個通用的解決方案是將一個函數分離爲多個函數，比如我們把Deposit分離成兩個：一個不導出的函數deposit，這個函數假設鎖總是會被保持併去做實際的操作，另一個是導出的函數Deposit，這個函數會調用deposit，但在調用前會先去獲取鎖。同理我們可以將Withdraw也表示成這種形式：
 
 ```go
 func Withdraw(amount int) bool {
@@ -136,8 +136,8 @@ func deposit(amount int) { balance += amount }
 ```
 
 
-当然，这里的存款deposit函数很小实际上取款withdraw函数不需要理会对它的调用，尽管如此，这里的表达还是表明了规则。
+當然，這里的存款deposit函數很小實際上取款withdraw函數不需要理會對它的調用，盡管如此，這里的表達還是表明了規則。
 
-封装(§6.6), 用限制一个程序中的意外交互的方式，可以使我们获得数据结构的不变性。因为某种原因，封装还帮我们获得了并发的不变性。当你使用mutex时，确保mutex和其保护的变量没有被导出(在go里也就是小写，且不要被大写字母开头的函数访问啦)，无论这些变量是包级的变量还是一个struct的字段。
+封裝(§6.6), 用限製一個程序中的意外交互的方式，可以使我們獲得數據結構的不變性。因爲某種原因，封裝還幫我們獲得了併發的不變性。當你使用mutex時，確保mutex和其保護的變量沒有被導出(在go里也就是小寫，且不要被大寫字母開頭的函數訪問啦)，無論這些變量是包級的變量還是一個struct的字段。