Merge branch 'master' of github.com:golang-china/gopl-zh

ch9/ch9-01.md

@@ -1,18 +1,18 @@
 ## 9.1. 競爭條件
 
-在一个线性(就是说只有一个goroutine的)的程序中，程序的执行顺序只由程序的逻辑来决定。例如，我们有一段语句序列，第一个在第二个之前(废话)，以此类推。在有两个或更多goroutine的程序中，每一个goroutine内的语句也是按照既定的顺序去执行的，但是一般情况下我们没法去知道分别位于两个goroutine的事件x和y的执行顺序，x是在y之前还是之后还是同时发生是没法判断的。当我们能够没有办法自信地确认一个事件是在另一个事件的前面或者后面发生的话，就说明x和y这两个事件是并发的。
+在一個線性(就是説隻有一個goroutine的)的程序中，程序的執行順序隻由程序的邏輯來決定。例如，我們有一段語句序列，第一個在第二個之前(廢話)，以此類推。在有兩個或更多goroutine的程序中，每一個goroutine內的語句也是按照旣定的順序去執行的，但是一般情況下我們沒法去知道分别位於兩個goroutine的事件x和y的執行順序，x是在y之前還是之後還是同時發生是沒法判斷的。當我們能夠沒有辦法自信地確認一個事件是在另一個事件的前面或者後面發生的話，就説明x和y這兩個事件是併發的。
 
-考虑一下，一个函数在线性程序中可以正确地工作。如果在并发的情况下，这个函数依然可以正确地工作的话，那么我们就说这个函数是并发安全的，并发安全的函数不需要额外的同步工作。我们可以把这个概念概括为一个特定类型的一些方法和操作函数，如果这个类型是并发安全的话，那么所有它的访问方法和操作就都是并发安全的。
+考慮一下，一個函數在線性程序中可以正確地工作。如果在併發的情況下，這個函數依然可以正確地工作的話，那麽我們就説這個函數是併發安全的，併發安全的函數不需要額外的同步工作。我們可以把這個概念概括爲一個特定類型的一些方法和操作函數，如果這個類型是併發安全的話，那麽所有它的訪問方法和操作就都是併發安全的。
 
-在一个程序中有非并发安全的类型的情况下，我们依然可以使这个程序并发安全。确实，并发安全的类型是例外，而不是规则，所以只有当文档中明确地说明了其是并发安全的情况下，你才可以并发地去访问它。我们会避免并发访问大多数的类型，无论是将变量局限在单一的一个goroutine内还是用互斥条件维持更高级别的不变性都是为了这个目的。我们会在本章中说明这些术语。
+在一個程序中有非併發安全的類型的情況下，我們依然可以使這個程序併發安全。確實，併發安全的類型是例外，而不是規則，所以隻有當文檔中明確地説明了其是併發安全的情況下，你才可以併發地去訪問它。我們會避免併發訪問大多數的類型，無論是將變量局限在單一的一個goroutine內還是用互斥條件維持更高級别的不變性都是爲了這個目的。我們會在本章中説明這些術語。
 
-相反，导出包级别的函数一般情况下都是并发安全的。由于package级的变量没法被限制在单一的gorouine，所以修改这些变量“必须”使用互斥条件。
+相反，導出包級别的函數一般情況下都是併發安全的。由於package級的變量沒法被限製在單一的gorouine，所以脩改這些變量“必須”使用互斥條件。
 
-一个函数在并发调用时没法工作的原因太多了，比如死锁(deadlock)、活锁(livelock)和饿死(resource starvation)。我们没有空去讨论所有的问题，这里我们只聚焦在竞争条件上。
+一個函數在併發調用時沒法工作的原因太多了，比如死鎖(deadlock)、活鎖(livelock)和餓死(resource starvation)。我們沒有空去討論所有的問題，這里我們隻聚焦在競爭條件上。
 
-竞争条件指的是程序在多个goroutine交叉执行操作时，没有给出正确的结果。竞争条件是很恶劣的一种场景，因为这种问题会一直潜伏在你的程序里，然后在非常少见的时候蹦出来，或许只是会在很大的负载时才会发生，又或许是会在使用了某一个编译器、某一种平台或者某一种架构的时候才会出现。这些使得竞争条件带来的问题非常难以复现而且难以分析诊断。
+競爭條件指的是程序在多個goroutine交叉執行操作時，沒有給出正確的結果。競爭條件是很惡劣的一種場景，因爲這種問題會一直潛伏在你的程序里，然後在非常少見的時候蹦出來，或許隻是會在很大的負載時才會發生，又或許是會在使用了某一個編譯器、某一種平台或者某一種架構的時候才會出現。這些使得競爭條件帶來的問題非常難以複現而且難以分析診斷。
 
-传统上经常用经济损失来为竞争条件做比喻，所以我们来看一个简单的银行账户程序。
+傳統上經常用經濟損失來爲競爭條件做比喻，所以我們來看一個簡單的銀行賬戶程序。
 
 ```go
 // Package bank implements a bank with only one account.
@@ -22,22 +22,22 @@ func Deposit(amount int) { balance = balance + amount }
 func Balance() int { return balance }
 ```
 
-(当然我们也可以把Deposit存款函数写成balance += amount，这种形式也是等价的，不过长一些的形式解释起来更方便一些。)
+(當然我們也可以把Deposit存款函數寫成balance += amount，這種形式也是等價的，不過長一些的形式解釋起來更方便一些。)
 
-对于这个具体的程序而言，我们可以瞅一眼各种存款和查余额的顺序调用，都能给出正确的结果。也就是说，Balance函数会给出之前的所有存入的额度之和。然而，当我们并发地而不是顺序地调用这些函数的话，Balance就再也没办法保证结果正确了。考虑一下下面的两个goroutine，其代表了一个银行联合账户的两笔交易：
+對於這個具體的程序而言，我們可以瞅一眼各種存款和査餘額的順序調用，都能給出正確的結果。也就是説，Balance函數會給出之前的所有存入的額度之和。然而，當我們併發地而不是順序地調用這些函數的話，Balance就再也沒辦法保證結果正確了。考慮一下下面的兩個goroutine，其代表了一個銀行聯合賬戶的兩筆交易：
 
 ```go
 // Alice:
 go func() {
-    bank.Deposit(200)                // A1
-    fmt.Println("=", bank.Balance()) // A2
+	bank.Deposit(200)                // A1
+	fmt.Println("=", bank.Balance()) // A2
 }()
 
 // Bob:
 go bank.Deposit(100)                 // B
 ```
 
-Alice存了$200，然后检查她的余额，同时Bob存了$100。因为A1和A2是和B并发执行的，我们没法预测他们发生的先后顺序。直观地来看的话，我们会认为其执行顺序只有三种可能性：“Alice先”，“Bob先”以及“Alice/Bob/Alice”交错执行。下面的表格会展示经过每一步骤后balance变量的值。引号里的字符串表示余额单。
+Alice存了$200，然後檢査她的餘額，同時Bob存了$100。因爲A1和A2是和B併發執行的，我們沒法預測他們發生的先後順序。直觀地來看的話，我們會認爲其執行順序隻有三種可能性：“Alice先”，“Bob先”以及“Alice/Bob/Alice”交錯執行。下面的表格會展示經過每一步驟後balance變量的值。引號里的字符串表示餘額單。
 
 ```
 Alice first Bob first Alice/Bob/Alice
@@ -47,9 +47,9 @@ A2 "=200"       A1    300   B      300
 B   300         A2   "=300" A2    "=300"
 ```
 
-所有情况下最终的余额都是$300。唯一的变数是Alice的余额单是否包含了Bob交易，不过无论怎么着客户都不会在意。
+所有情況下最終的餘額都是$300。唯一的變數是Alice的餘額單是否包含了Bob交易，不過無論怎麽着客戶都不會在意。
 
-但是事实是上面的直觉推断是错误的。第四种可能的结果是事实存在的，这种情况下Bob的存款会在Alice存款操作中间，在余额被读到(balance + amount)之后，在余额被更新之前(balance = ...)，这样会导致Bob的交易丢失。而这是因为Alice的存款操作A1实际上是两个操作的一个序列，读取然后写；可以称之为A1r和A1w。下面是交叉时产生的问题：
+但是事實是上面的直覺推斷是錯誤的。第四種可能的結果是事實存在的，這種情況下Bob的存款會在Alice存款操作中間，在餘額被讀到(balance + amount)之後，在餘額被更新之前(balance = ...)，這樣會導致Bob的交易丟失。而這是因爲Alice的存款操作A1實際上是兩個操作的一個序列，讀取然後寫；可以稱之爲A1r和A1w。下面是交叉時産生的問題：
 
 ```
 Data race
@@ -60,11 +60,11 @@ A1w    200     balance = ...
 A2  "= 200"
 ```
 
-在A1r之后，balance + amount会被计算为200，所以这是A1w会写入的值，并不受其它存款操作的干预。最终的余额是$200。银行的账户上的资产比Bob实际的资产多了$100。(译注：因为丢失了Bob的存款操作，所以其实是说Bob的钱丢了)
+在A1r之後，balance + amount會被計算爲200，所以這是A1w會寫入的值，併不受其它存款操作的榦預。最終的餘額是$200。銀行的賬戶上的資産比Bob實際的資産多了$100。(譯註：因爲丟失了Bob的存款操作，所以其實是説Bob的錢丟了)
 
-这个程序包含了一个特定的竞争条件，叫作数据竞争。无论任何时候，只要有两个goroutine并发访问同一变量，且至少其中的一个是写操作的时候就会发生数据竞争。
+這個程序包含了一個特定的競爭條件，叫作數據競爭。無論任何時候，隻要有兩個goroutine併發訪問同一變量，且至少其中的一個是寫操作的時候就會發生數據競爭。
 
-如果数据竞争的对象是一个比一个机器字(译注：32位机器上一个字=4个字节)更大的类型时，事情就变得更麻烦了，比如interface，string或者slice类型都是如此。下面的代码会并发地更新两个不同长度的slice：
+如果數據競爭的對象是一個比一個機器字(譯註：32位機器上一個字=4個字節)更大的類型時，事情就變得更麻煩了，比如interface，string或者slice類型都是如此。下面的代碼會併發地更新兩個不同長度的slice：
 
 ```go
 var x []int
@@ -73,13 +73,13 @@ go func() { x = make([]int, 1000000) }()
 x[999999] = 1 // NOTE: undefined behavior; memory corruption possible!
 ```
 
-最后一个语句中的x的值是未定义的；其可能是nil，或者也可能是一个长度为10的slice，也可能是一个程度为1,000,000的slice。但是回忆一下slice的三个组成部分：指针(pointer)、长度(length)和容量(capacity)。如果指针是从第一个make调用来，而长度从第二个make来，x就变成了一个混合体，一个自称长度为1,000,000但实际上内部只有10个元素的slice。这样导致的结果是存储999,999元素的位置会碰撞一个遥远的内存位置，这种情况下难以对值进行预测，而且定位和debug也会变成噩梦。这种语义雷区被称为未定义行为，对C程序员来说应该很熟悉；幸运的是在Go语言里造成的麻烦要比C里小得多。
+最後一個語句中的x的值是未定義的；其可能是nil，或者也可能是一個長度爲10的slice，也可能是一個程度爲1,000,000的slice。但是迴憶一下slice的三個組成部分：指針(pointer)、長度(length)和容量(capacity)。如果指針是從第一個make調用來，而長度從第二個make來，x就變成了一個混合體，一個自稱長度爲1,000,000但實際上內部隻有10個元素的slice。這樣導致的結果是存儲999,999元素的位置會碰撞一個遙遠的內存位置，這種情況下難以對值進行預測，而且定位和debug也會變成噩夢。這種語義雷區被稱爲未定義行爲，對C程序員來説應該很熟悉；幸運的是在Go語言里造成的麻煩要比C里小得多。
 
-尽管并发程序的概念让我们知道并发并不是简单的语句交叉执行。我们将会在9.4节中看到，数据竞争可能会有奇怪的结果。许多程序员，甚至一些非常聪明的人也还是会偶尔提出一些理由来允许数据竞争，比如：“互斥条件代价太高”，“这个逻辑只是用来做logging”，“我不介意丢失一些消息”等等。因为在他们的编译器或者平台上很少遇到问题，可能给了他们错误的信心。一个好的经验法则是根本就没有什么所谓的良性数据竞争。所以我们一定要避免数据竞争，那么在我们的程序中要如何做到呢？
+盡管併發程序的概念讓我們知道併發併不是簡單的語句交叉執行。我們將會在9.4節中看到，數據競爭可能會有奇怪的結果。許多程序員，甚至一些非常聰明的人也還是會偶爾提出一些理由來允許數據競爭，比如：“互斥條件代價太高”，“這個邏輯隻是用來做logging”，“我不介意丟失一些消息”等等。因爲在他們的編譯器或者平台上很少遇到問題，可能給了他們錯誤的信心。一個好的經驗法則是根本就沒有什麽所謂的良性數據競爭。所以我們一定要避免數據競爭，那麽在我們的程序中要如何做到呢？
 
-我们来重复一下数据竞争的定义，因为实在太重要了：数据竞争会在两个以上的goroutine并发访问相同的变量且至少其中一个为写操作时发生。根据上述定义，有三种方式可以避免数据竞争：
+我們來重複一下數據競爭的定義，因爲實在太重要了：數據競爭會在兩個以上的goroutine併發訪問相同的變量且至少其中一個爲寫操作時發生。根據上述定義，有三種方式可以避免數據競爭：
 
-第一种方法是不要去写变量。考虑一下下面的map，会被“懒”填充，也就是说在每个key被第一次请求到的时候才会去填值。如果Icon是被顺序调用的话，这个程序会工作很正常，但如果Icon被并发调用，那么对于这个map来说就会存在数据竞争。
+第一種方法是不要去寫變量。考慮一下下面的map，會被“懶”填充，也就是説在每個key被第一次請求到的時候才會去填值。如果Icon是被順序調用的話，這個程序會工作很正常，但如果Icon被併發調用，那麽對於這個map來説就會存在數據競爭。
 
 ```go
 var icons = make(map[string]image.Image)
@@ -87,36 +87,36 @@ func loadIcon(name string) image.Image
 
 // NOTE: not concurrency-safe!
 func Icon(name string) image.Image {
-    icon, ok := icons[name]
-    if !ok {
-        icon = loadIcon(name)
-        icons[name] = icon
-    }
-    return icon
+	icon, ok := icons[name]
+	if !ok {
+		icon = loadIcon(name)
+		icons[name] = icon
+	}
+	return icon
 }
 ```
 
-反之，如果我们在创建goroutine之前的初始化阶段，就初始化了map中的所有条目并且再也不去修改它们，那么任意数量的goroutine并发访问Icon都是安全的，因为每一个goroutine都只是去读取而已。
+反之，如果我們在創建goroutine之前的初始化階段，就初始化了map中的所有條目併且再也不去脩改它們，那麽任意數量的goroutine併發訪問Icon都是安全的，因爲每一個goroutine都隻是去讀取而已。
 
 ```go
 var icons = map[string]image.Image{
-    "spades.png":   loadIcon("spades.png"),
-    "hearts.png":   loadIcon("hearts.png"),
-    "diamonds.png": loadIcon("diamonds.png"),
-    "clubs.png":    loadIcon("clubs.png"),
+	"spades.png":   loadIcon("spades.png"),
+	"hearts.png":   loadIcon("hearts.png"),
+	"diamonds.png": loadIcon("diamonds.png"),
+	"clubs.png":    loadIcon("clubs.png"),
 }
 
 // Concurrency-safe.
 func Icon(name string) image.Image { return icons[name] }
 ```
 
-上面的例子里icons变量在包初始化阶段就已经被赋值了，包的初始化是在程序main函数开始执行之前就完成了的。只要初始化完成了，icons就再也不会修改的或者不变量是本来就并发安全的，这种变量不需要进行同步。不过显然我们没法用这种方法，因为update操作是必要的操作，尤其对于银行账户来说。
+上面的例子里icons變量在包初始化階段就已經被賦值了，包的初始化是在程序main函數開始執行之前就完成了的。隻要初始化完成了，icons就再也不會脩改的或者不變量是本來就併發安全的，這種變量不需要進行同步。不過顯然我們沒法用這種方法，因爲update操作是必要的操作，尤其對於銀行賬戶來説。
 
-第二种避免数据竞争的方法是，避免从多个goroutine访问变量。这也是前一章中大多数程序所采用的方法。例如前面的并发web爬虫(§8.6)的main goroutine是唯一一个能够访问seen map的goroutine，而聊天服务器(§8.10)中的broadcaster goroutine是唯一一个能够访问clients map的goroutine。这些变量都被限定在了一个单独的goroutine中。
+第二種避免數據競爭的方法是，避免從多個goroutine訪問變量。這也是前一章中大多數程序所采用的方法。例如前面的併發web爬蟲(§8.6)的main goroutine是唯一一個能夠訪問seen map的goroutine，而聊天服務器(§8.10)中的broadcaster goroutine是唯一一個能夠訪問clients map的goroutine。這些變量都被限定在了一個單獨的goroutine中。
 
-由于其它的goroutine不能够直接访问变量，它们只能使用一个channel来发送给指定的goroutine请求来查询更新变量。这也就是Go的口头禅“不要使用共享数据来通信；使用通信来共享数据”。一个提供对一个指定的变量通过cahnnel来请求的goroutine叫做这个变量的监控(monitor)goroutine。例如broadcaster goroutine会监控(monitor)clients map的全部访问。
+由於其它的goroutine不能夠直接訪問變量，它們隻能使用一個channel來發送給指定的goroutine請求來査詢更新變量。這也就是Go的口頭禪“不要使用共享數據來通信；使用通信來共享數據”。一個提供對一個指定的變量通過cahnnel來請求的goroutine叫做這個變量的監控(monitor)goroutine。例如broadcaster goroutine會監控(monitor)clients map的全部訪問。
 
-下面是一个重写了的银行的例子，这个例子中balance变量被限制在了monitor goroutine中，名为teller：
+下面是一個重寫了的銀行的例子，這個例子中balance變量被限製在了monitor goroutine中，名爲teller：
 
 ```go
 gopl.io/ch9/bank1
@@ -130,45 +130,45 @@ func Deposit(amount int) { deposits <- amount }
 func Balance() int       { return <-balances }
 
 func teller() {
-    var balance int // balance is confined to teller goroutine
-    for {
-        select {
-        case amount := <-deposits:
-            balance += amount
-        case balances <- balance:
-        }
-    }
+	var balance int // balance is confined to teller goroutine
+	for {
+		select {
+		case amount := <-deposits:
+			balance += amount
+		case balances <- balance:
+		}
+	}
 }
 
 func init() {
-    go teller() // start the monitor goroutine
+	go teller() // start the monitor goroutine
 }
 ```
 
-即使当一个变量无法在其整个生命周期内被绑定到一个独立的goroutine，绑定依然是并发问题的一个解决方案。例如在一条流水线上的goroutine之间共享变量是很普遍的行为，在这两者间会通过channel来传输地址信息。如果流水线的每一个阶段都能够避免在将变量传送到下一阶段时再去访问它，那么对这个变量的所有访问就是线性的。其效果是变量会被绑定到流水线的一个阶段，传送完之后被绑定到下一个，以此类推。这种规则有时被称为串行绑定。
+卽使當一個變量無法在其整個生命週期內被綁定到一個獨立的goroutine，綁定依然是併發問題的一個解決方案。例如在一條流水線上的goroutine之間共享變量是很普遍的行爲，在這兩者間會通過channel來傳輸地址信息。如果流水線的每一個階段都能夠避免在將變量傳送到下一階段時再去訪問它，那麽對這個變量的所有訪問就是線性的。其效果是變量會被綁定到流水線的一個階段，傳送完之後被綁定到下一個，以此類推。這種規則有時被稱爲串行綁定。
 
-下面的例子中，Cakes会被严格地顺序访问，先是baker gorouine，然后是icer gorouine：
+下面的例子中，Cakes會被嚴格地順序訪問，先是baker gorouine，然後是icer gorouine：
 
 ```go
 type Cake struct{ state string }
 
 func baker(cooked chan<- *Cake) {
-    for {
-        cake := new(Cake)
-        cake.state = "cooked"
-        cooked <- cake // baker never touches this cake again
-    }
+	for {
+		cake := new(Cake)
+		cake.state = "cooked"
+		cooked <- cake // baker never touches this cake again
+	}
 }
 
 func icer(iced chan<- *Cake, cooked <-chan *Cake) {
-    for cake := range cooked {
-        cake.state = "iced"
-        iced <- cake // icer never touches this cake again
-    }
+	for cake := range cooked {
+		cake.state = "iced"
+		iced <- cake // icer never touches this cake again
+	}
 }
 ```
 
-第三种避免数据竞争的方法是允许很多goroutine去访问变量，但是在同一个时刻最多只有一个goroutine在访问。这种方式被称为“互斥”，在下一节来讨论这个主题。
+第三種避免數據競爭的方法是允許很多goroutine去訪問變量，但是在同一個時刻最多隻有一個goroutine在訪問。這種方式被稱爲“互斥”，在下一節來討論這個主題。
 
-练习 9.1: 给gopl.io/ch9/bank1程序添加一个Withdraw(amount int)取款函数。其返回结果应该要表明事务是成功了还是因为没有足够资金失败了。这条消息会被发送给monitor的goroutine，且消息需要包含取款的额度和一个新的channel，这个新channel会被monitor goroutine来把boolean结果发回给Withdraw。
+**練習 9.1：** 給gopl.io/ch9/bank1程序添加一個Withdraw(amount int)取款函數。其返迴結果應該要表明事務是成功了還是因爲沒有足夠資金失敗了。這條消息會被發送給monitor的goroutine，且消息需要包含取款的額度和一個新的channel，這個新channel會被monitor goroutine來把boolean結果發迴給Withdraw。
 

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,14 +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"的术语启发而来的。两种用法都是一个代理人保证变量被顺序访问)。
-
-由于在存款和查询余额函数中的临界区代码这么短--只有一行，没有分支调用--在代码最后去调用Unlock就显得更为直截了当。在更复杂的临界区的应用中，尤其是必须要尽早处理错误并返回的情况下，就很难去(靠人)判断对Lock和Unlock的调用是在所有路径中都能够严格配对的了。Go语言里的defer简直就是这种情况下的救星：我们用defer来调用Unlock，临界区会隐式地延伸到函数作用域的最后，这样我们就从“总要记得在函数返回之后或者发生错误返回时要记得调用一次Unlock”这种状态中获得了解放。Go会自动帮我们完成这些事情。
+上面的bank程序例證了一種通用的併發模式。一繫列的導出函數封裝了一個或多個變量，那麽訪問這些變量唯一的方式就是通過這些函數來做(或者方法，對於一個對象的變量來説)。每一個函數在一開始就獲取互斥鎖併在最後釋放鎖，從而保證共享變量不會被併發訪問。這種函數、互斥鎖和變量的編排叫作監控monitor(這種老式單詞的monitor是受"monitor goroutine"的術語啟發而來的。兩種用法都是一個代理人保證變量被順序訪問)。
 
+由於在存款和査詢餘額函數中的臨界區代碼這麽短--隻有一行，沒有分支調用--在代碼最後去調用Unlock就顯得更爲直截了當。在更複雜的臨界區的應用中，尤其是必須要盡早處理錯誤併返迴的情況下，就很難去(靠人)判斷對Lock和Unlock的調用是在所有路徑中都能夠嚴格配對的了。Go語言里的defer簡直就是這種情況下的救星：我們用defer來調用Unlock，臨界區會隱式地延伸到函數作用域的最後，這樣我們就從“總要記得在函數返迴之後或者發生錯誤返迴時要記得調用一次Unlock”這種狀態中獲得了解放。Go會自動幫我們完成這些事情。
 
 ```go
 func Balance() int {
@@ -65,11 +64,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 +82,9 @@ func Withdraw(amount int) bool {
 }
 ```
 
-函数终于给出了正确的结果，但是还有一点讨厌的副作用。当过多的取款操作同时执行时，balance可能会瞬时被减到0以下。这可能会引起一个并发的取款被不合逻辑地拒绝。所以如果Bob尝试买一辆sports car时，Alice可能就没办法为她的早咖啡付款了。这里的问题是取款不是一个原子操作：它包含了三个步骤，每一步都需要去获取并释放互斥锁，但任何一次锁都不会锁上整个取款流程。
+函數終於給出了正確的結果，但是還有一點討厭的副作用。當過多的取款操作同時執行時，balance可能會瞬時被減到0以下。這可能會引起一個併發的取款被不合邏輯地拒絶。所以如果Bob嚐試買一輛sports car時，Alice可能就沒辦法爲她的早咖啡付款了。這里的問題是取款不是一個原子操作：它包含了三個步驟，每一步都需要去獲取併釋放互斥鎖，但任何一次鎖都不會鎖上整個取款流程。
 
-理想情况下，取款应该只在整个操作中获得一次互斥锁。下面这样的尝试是错误的：
+理想情況下，取款應該隻在整個操作中獲得一次互斥鎖。下面這樣的嚐試是錯誤的：
 
 ```go
 // NOTE: incorrect!
@@ -101,11 +100,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 {
@@ -135,9 +134,6 @@ func Balance() int {
 func deposit(amount int) { balance += amount }
 ```
 
+當然，這里的存款deposit函數很小實際上取款withdraw函數不需要理會對它的調用，盡管如此，這里的表達還是表明了規則。
 
-当然，这里的存款deposit函数很小实际上取款withdraw函数不需要理会对它的调用，尽管如此，这里的表达还是表明了规则。
-
-封装(§6.6), 用限制一个程序中的意外交互的方式，可以使我们获得数据结构的不变性。因为某种原因，封装还帮我们获得了并发的不变性。当你使用mutex时，确保mutex和其保护的变量没有被导出(在go里也就是小写，且不要被大写字母开头的函数访问啦)，无论这些变量是包级的变量还是一个struct的字段。
-
-
+封裝(§6.6), 用限製一個程序中的意外交互的方式，可以使我們獲得數據結構的不變性。因爲某種原因，封裝還幫我們獲得了併發的不變性。當你使用mutex時，確保mutex和其保護的變量沒有被導出(在go里也就是小寫，且不要被大寫字母開頭的函數訪問啦)，無論這些變量是包級的變量還是一個struct的字段。

ch9/ch9-03.md

@@ -20,5 +20,5 @@ Balance函數現在調用了RLock和RUnlock方法來獲取和釋放一個讀取
 
 RLock隻能在臨界區共享變量沒有任何寫入操作時可用。一般來説，我們不應該假設邏輯上的隻讀函數/方法也不會去更新某一些變量。比如一個方法功能是訪問一個變量，但它也有可能會同時去給一個內部的計數器+1(譯註：可能是記録這個方法的訪問次數啥的)，或者去更新緩存--使卽時的調用能夠更快。如果有疑惑的話，請使用互斥鎖。
 
-RWMutex隻有當獲得鎖的大部分goroutine都是讀操作，而鎖在競爭條件下，也就是説，goroutine們必鬚等待才能獲取到鎖的時候，RWMutex才是最能帶來好處的。RWMutex需要更複雜的內部記録，所以會讓它比一般的無競爭鎖的mutex慢一些。
+RWMutex隻有當獲得鎖的大部分goroutine都是讀操作，而鎖在競爭條件下，也就是説，goroutine們必須等待才能獲取到鎖的時候，RWMutex才是最能帶來好處的。RWMutex需要更複雜的內部記録，所以會讓它比一般的無競爭鎖的mutex慢一些。
 

ch9/ch9-05.md

@@ -87,7 +87,7 @@ func Icon(name string) image.Image {
 ```
 
 
-上面的代碼有兩個臨界區。goroutine首先會獲取一個寫鎖，査詢map，然後釋放鎖。如果條目被找到了(一般情況下)，那麽會直接返迴。如果沒有找到，那goroutine會獲取一個寫鎖。不釋放共享鎖的話，也沒有任何辦法來將一個共享鎖陞級爲一個互斥鎖，所以我們必鬚重新檢査icons變量是否爲nil，以防止在執行這一段代碼的時候，icons變量已經被其它gorouine初始化過了。
+上面的代碼有兩個臨界區。goroutine首先會獲取一個寫鎖，査詢map，然後釋放鎖。如果條目被找到了(一般情況下)，那麽會直接返迴。如果沒有找到，那goroutine會獲取一個寫鎖。不釋放共享鎖的話，也沒有任何辦法來將一個共享鎖陞級爲一個互斥鎖，所以我們必須重新檢査icons變量是否爲nil，以防止在執行這一段代碼的時候，icons變量已經被其它gorouine初始化過了。
 
 上面的模闆使我們的程序能夠更好的併發，但是有一點太複雜且容易出錯。幸運的是，sync包爲我們提供了一個專門的方案來解決這種一次性初始化的問題：sync.Once。概念上來講，一次性的初始化需要一個互斥量mutex和一個boolean變量來記録初始化是不是已經完成了；互斥量用來保護boolean變量和客戶端數據結構。Do這個唯一的方法需要接收初始化函數作爲其參數。讓我們用sync.Once來簡化前面的Icon函數吧：
 

ch9/ch9-08-3.md

@@ -18,6 +18,6 @@ $ GOMAXPROCS=2 go run hacker-cliché.go
 010101010101010101011001100101011010010100110...
 ```
 
-在第一次執行時，最多同時隻能有一個goroutine被執行。初始情況下隻有main goroutine被執行，所以會打印很多1。過了一段時間後，GO調度器會將其置爲休眠，併喚醒另一個goroutine，這時候就開始打印很多0了，在打印的時候，goroutine是被調度到操作繫統線程上的。在第二次執行時，我們使用了兩個操作繫統線程，所以兩個goroutine可以一起被執行，以同樣的頻率交替打印0和1。我們必鬚強調的是goroutine的調度是受很多因子影響的，而runtime也是在不斷地發展演進的，所以這里的你實際得到的結果可能會因爲版本的不同而與我們運行的結果有所不同。
+在第一次執行時，最多同時隻能有一個goroutine被執行。初始情況下隻有main goroutine被執行，所以會打印很多1。過了一段時間後，GO調度器會將其置爲休眠，併喚醒另一個goroutine，這時候就開始打印很多0了，在打印的時候，goroutine是被調度到操作繫統線程上的。在第二次執行時，我們使用了兩個操作繫統線程，所以兩個goroutine可以一起被執行，以同樣的頻率交替打印0和1。我們必須強調的是goroutine的調度是受很多因子影響的，而runtime也是在不斷地發展演進的，所以這里的你實際得到的結果可能會因爲版本的不同而與我們運行的結果有所不同。
 
 練習9.6: 測試一下計算密集型的併發程序(練習8.5那樣的)會被GOMAXPROCS怎樣影響到。在你的電腦上最佳的值是多少？你的電腦CPU有多少個核心？

ch9/ch9.md

@@ -1,5 +1,5 @@
 # 第九章 基於共享變量的併發
 
-前一章我們介紹了一些使用goroutine和channel這樣直接而自然的方式來實現併發的方法。然而這樣做我們實際上屏蔽掉了在寫併發代碼時必鬚處理的一些重要而且細微的問題。
+前一章我們介紹了一些使用goroutine和channel這樣直接而自然的方式來實現併發的方法。然而這樣做我們實際上屏蔽掉了在寫併發代碼時必須處理的一些重要而且細微的問題。
 
 在本章中，我們會細致地了解併發機製。尤其是在多goroutine之間的共享變量，併發問題的分析手段，以及解決這些問題的基本模式。最後我們會解釋goroutine和操作繫統線程之間的技術上的一些區别。