本篇文章面向的讀者： 已經基本掌握Go中的 協程(goroutine)，通道(channel)，互斥鎖(sync.Mutex)，讀寫鎖(sync.RWMutex) 這些知識。如果對這些還不太懂，可以先回去把這幾個知識點解決了。
首先理解以下三點再進入正題：
假如有這樣一個現實場景：在一個公園中有一個公共廁所，這個廁所一次只能容納一個人上廁所，同時這個廁所中有個放捲紙的位置，其一次只能放一卷紙，一卷紙的總長度是 5 米，而每個人上一次廁所需要用掉 1 米的紙。而當一卷紙用完後，公園管理員要負責給廁所加上一卷新紙，以便大家可以繼續使用廁所。 那麼對於這個單人公共廁所，大家只能排隊上廁所，當每個人進到廁所的時候，當然會把廁所門鎖好，以便任何人都進不來（包括管理員）。管理員若要進到廁所檢視用紙情況並加捲紙，也需要排隊（因為插隊總是不文明對吧）。
那麼怎麼用 Golang 去模擬上述場景呢？
首先我們先不用 sync.Cond，看如何實現？那麼請看下面這段程式碼：
package main
import (
"fmt"
"time"
"sync"
)
var 捲紙 int
var m sync.Mutex
var wg sync.WaitGroup
func 上廁所(姓名 string){
m.Lock()
defer func(){
m.Unlock()
wg.Done()
}()
fmt.Printf("%s 進到廁所\t",姓名)
if 捲紙 >= 1 { // 進到廁所第一件事是看還有沒有紙
fmt.Printf("正在拉屎中...\n")
time.Sleep(time.Second)
捲紙 -= 1
fmt.Printf("%s 已用完廁所，正在離開\n",姓名)
return
}
fmt.Printf("發現紙用完了，無奈先離開廁所\n")
}
func 加廁紙(){
m.Lock()
defer func(){
m.Unlock()
wg.Done()
}()
fmt.Printf("公園管理員 進到廁所\t")
if 捲紙 <= 0 { // 管理員進到廁所是看紙有沒有用完
fmt.Printf("公園管理員 正在加新紙...\n")
time.Sleep(time.Millisecond*500)
捲紙 = 5
fmt.Printf("公園管理員 已加上新廁紙，正在離開\n")
}else{
fmt.Printf("發現紙還沒用完，先離開廁所\n")
}
}
func main() {
捲紙 = 5 // 廁所一開始就準備好了一卷紙，長度5米
要排隊上廁所的人 := [...]string{"老王","小李","老張","小劉","阿明","欣欣","西西","芳芳"}
for _,誰 := range 要排隊上廁所的人 {
wg.Add(1)
go 上廁所(誰)
}
wg.Add(1)
go 加廁紙()
wg.Wait()
}
/*
輸出（由於協程執行順序的不可預測性，因此每次輸出的順序都可能不一樣）：
公園管理員 進到廁所 發現紙還沒用完，先離開廁所
阿明 進到廁所 正在拉屎中...
阿明 已用完廁所，正在離開
老王 進到廁所 正在拉屎中...
老王 已用完廁所，正在離開
小劉 進到廁所 正在拉屎中...
小劉 已用完廁所，正在離開
小李 進到廁所 正在拉屎中...
小李 已用完廁所，正在離開
老張 進到廁所 正在拉屎中...
老張 已用完廁所，正在離開
欣欣 進到廁所 發現紙用完了，無奈先離開廁所
芳芳 進到廁所 發現紙用完了，無奈先離開廁所
西西 進到廁所 發現紙用完了，無奈先離開廁所
*/
上面的程式碼已經能看出一些效果，但還是有問題：最後三個人因為廁紙用完，都直接離開廁所後就沒有後續了？應該是他們離開廁所後再次嘗試排隊，直到需求解決，就離開廁所不再參與排隊了，否則要不斷去排隊上廁所。而公園管理員呢，他要一直去排隊進到廁所裡看還有沒有紙，而不是看一次就再也不管了。 那麼請看下面的完善程式碼：
package main
import (
"fmt"
"sync"
"time"
)
var (
捲紙 int
m sync.Mutex
wg sync.WaitGroup
廁所的排隊 chan string
)
func 上廁所(姓名 string) {
m.Lock() // 該語句的呼叫只說明本執行體（可理解成該姓名所指的那個人）加入到了廁所資源的爭搶組中；
// 而該語句的完成呼叫，才代表了從爭搶組中脫穎而出，搶到了廁所；在完成呼叫之前，會一直阻塞在這裡（可理解為這個人正在爭搶中）
defer func() {
m.Unlock()
wg.Done()
}()
fmt.Printf("%s 進到廁所\t", 姓名)
if 捲紙 >= 1 { // 進到廁所第一件事是看還有沒有紙
fmt.Printf("正在拉屎中...\n")
time.Sleep(time.Second)
捲紙 -= 1
fmt.Printf("%s 已用完廁所，正在離開\n", 姓名)
return
}
fmt.Printf("發現紙用完了，無奈先離開廁所\n")
廁所的排隊 <- 姓名 // 再次加入廁所排隊，期望下次可以成功如廁
}
func 加廁紙() {
m.Lock()
defer m.Unlock()
fmt.Printf("公園管理員 進到廁所\t")
if 捲紙 <= 0 { // 管理員進到廁所是看紙有沒有用完
fmt.Printf("公園管理員 正在加新紙...\n")
time.Sleep(time.Millisecond * 500)
捲紙 = 5
fmt.Printf("公園管理員 已加上新廁紙，正在離開\n")
} else {
fmt.Printf("發現紙還沒用完，先離開廁所\n")
}
}
func main() {
捲紙 = 5 // 廁所一開始就準備好了一卷紙，長度5米
要上廁所的人 := [...]string{"老王", "小李", "老張", "小劉", "阿明", "欣欣", "西西", "芳芳"} // 這裡只是舉幾個人名例子，假設此處有源源不斷的人去上廁所（讀者可以隨意改造人名來源）
廁所的排隊 = make(chan string, len(要上廁所的人))
for _, 誰 := range 要上廁所的人 {
廁所的排隊 <- 誰
}
go func() { // 在這個執行體中，會不斷從 廁所排隊 中把人加入到 對廁所資源的爭搶組中
for 誰 := range 廁所的排隊 {
wg.Add(1)
go 上廁所(誰)
}
}()
wg.Add(1)
go func() { // 在這個執行體中，代表公園管理員的個人時間線，他會每隔一段時間去加入爭搶組進到廁所，檢查紙還有沒有
for {
time.Sleep(time.Millisecond * 1200)
加廁紙()
}
}()
wg.Wait()
}
/*
輸出：
老王 進到廁所 正在拉屎中...
老王 已用完廁所，正在離開
芳芳 進到廁所 正在拉屎中...
芳芳 已用完廁所，正在離開
阿明 進到廁所 正在拉屎中...
阿明 已用完廁所，正在離開
小劉 進到廁所 正在拉屎中...
小劉 已用完廁所，正在離開
欣欣 進到廁所 正在拉屎中...
欣欣 已用完廁所，正在離開
小李 進到廁所 發現紙用完了，無奈先離開廁所
老張 進到廁所 發現紙用完了，無奈先離開廁所
西西 進到廁所 發現紙用完了，無奈先離開廁所
公園管理員 進到廁所 公園管理員 正在加新紙...
公園管理員 已加上新廁紙，正在離開
西西 進到廁所 正在拉屎中...
西西 已用完廁所，正在離開
小李 進到廁所 正在拉屎中...
小李 已用完廁所，正在離開
老張 進到廁所 正在拉屎中...
老張 已用完廁所，正在離開
公園管理員 進到廁所 發現紙還沒用完，先離開廁所
公園管理員 進到廁所 發現紙還沒用完，先離開廁所
公園管理員 進到廁所 發現紙還沒用完，先離開廁所
*/
上面這個程式碼在功能上基本是完善了，成功模擬了上述 多人上公廁 的場景。但仔細一想，這個場景其實有些地方是不合常理的：如果有個人進到廁所發現沒紙，難道他會出來緊接著再去排隊嗎？如果排了三次五次甚至十次還是沒有紙，還要這樣不斷地反覆排隊進去出來又排隊？而公園管理員，要是這樣不斷反覆排隊進廁所檢視，那麼他這一天其他啥事都幹不了。
所以更合理實際的情況應該是：如果一個人進到廁所發現沒紙，他應該先去在旁邊歇著或在附近幹別的，當公園管理員加完紙後，會通過喇叭吆喝一聲：「新紙已加上」。這樣，附近所有因為沒廁紙而歇著的人就會聽到這個通知，此時，他們再去嘗試排隊進廁所；而公園管理員也不用不斷去排隊進廁所檢查紙用完了沒有，因為經過升級，廁所加裝了一個功能，有一個紙用盡的報警按鈕裝在紙盒旁邊，當上完廁所的人發現紙用完的時候，他會先按下這個報警按鈕，再離開廁所。這個報警的聲音在整個公園的各處都可以聽到，所以管理員無論在哪裡幹啥，他都能收到這個紙用盡的報警訊號，然後他才去進廁所加紙。
其實這種被動通知的模式就是 sync.Cond 的核心思想，它會減少資源消耗，達到更優的效果，下面就是改良為 sync.Cond 的實現程式碼：
package main
import (
"fmt"
"math"
"strconv"
"sync"
"time"
)
var (
捲紙 int
m sync.Mutex
cond = sync.NewCond(&m)
)
func 上廁所(姓名 string) {
m.Lock() // 該語句的呼叫只說明本執行體（可理解成該姓名所指的那個人）加入到了廁所資源的爭搶組中；
// 而該語句的完成呼叫，才代表了從爭搶組中脫穎而出，搶到了廁所；在完成呼叫之前，會一直阻塞在這裡（可理解為這個人正在爭搶中）
defer m.Unlock()
fmt.Printf("%s 進到廁所\t", 姓名)
for 捲紙 < 1 { // 進到廁所第一件事是看還有沒有紙
fmt.Printf("發現紙用完了，先離開廁所在附近歇息等待訊號\n")
cond.Wait() // 該語句的呼叫 相當於呼叫了 m.Unlock() 也就是退出了爭搶組，而是先歇著等待紙加上的訊號；
// 當收到紙加上的訊號後，該語句會自動執行 m.Lock()，也就是會重新加入到廁所的爭搶組中；
// 該語句的完成呼叫說明已經再次成功爭搶到了廁所；
fmt.Printf("%s 等到了廁紙已加的訊號，並去再次搶到了廁所\t", 姓名)
}
fmt.Printf("正在拉屎中...\n")
time.Sleep(time.Second)
捲紙 -= 1
fmt.Printf("%s 已用完廁所\t", 姓名)
if 捲紙 < 1 { // 注意這裡：在他用完廁所離開前，他需要看是不是紙已經用完了，如果用完了，就按下紙用盡的報警按鈕，給公園管理員傳送訊號
cond.Broadcast() // 想想，這裡為什麼不用 Signal() ？因為 Signal 只能通知到一個等待者，這樣就有可能通知不到 公園管理員。可以試著把這裡換成 Signal() 試下
fmt.Printf("發現廁紙已用完，並按下了報警\t")
}
fmt.Printf("正在離開廁所\n")
}
func 加廁紙() {
m.Lock()
defer m.Unlock()
fmt.Printf("公園管理員 進到廁所\t")
for 捲紙 > 0 { // 管理員進到廁所是看紙有沒有用完
fmt.Printf("發現紙還沒用完，先離開廁所在等紙用盡的報警訊息\n")
cond.Wait() // 如果紙沒用完，就先去幹其他工作，等紙用盡的報警訊息
fmt.Printf("公園管理員 等到了紙用盡的報警訊息，並再次搶到了廁所\n")
}
fmt.Printf("公園管理員 正在加新紙...\n")
time.Sleep(time.Millisecond * 500)
捲紙 = 5
cond.Broadcast() // 注意：公園管理員加完新紙後，要通過喇叭喊一聲 「紙已加上」 的訊息通知所有 因沒紙而等待上廁所的人
fmt.Printf("公園管理員 已加上新廁紙，並通過喇叭通知了該訊息，並正在離開廁所\n")
}
func main() {
捲紙 = 5 // 廁所一開始就準備好了一卷紙，長度5米
要上廁所的人 := [...]string{"老王", "小李", "老張", "小劉", "阿明", "欣欣", "西西", "芳芳"} // 上廁所的人名模板
go func() { // 在這個執行體中，代表廁所及廁所佇列的時間線，廁所永遠運營下去
for i := 0; i < math.MaxInt; i++ { // 此迴圈通過編號加上上面的姓名模板來 建立源源不斷 上廁所的人
for _, 人名模板 := range 要上廁所的人 {
誰 := 人名模板 + strconv.Itoa(i)
go 上廁所(誰)
time.Sleep(time.Millisecond * 500) // 平均每半秒有一個人去上廁所
}
fmt.Printf("\n====================>> 螢幕停止輸出後，請按Enter鍵繼續 <<====================\n\n")
fmt.Scanln()
}
}()
go func() { // 在這個執行體中，代表公園管理員的個人時間線，管理員永不退休
for {
// 注意：相比上個版本，此處不用再加 Sleep 函數了，因為 加廁紙() 函數中的 cond.Wait() 會在有紙的時候等待訊號
加廁紙()
}
}()
end := make(chan bool)
<-end
}
/*
輸出：
公園管理員 進到廁所 發現紙還沒用完，先離開廁所在等紙用盡的報警訊息
老王0 進到廁所 正在拉屎中...
老王0 已用完廁所 正在離開廁所
小李0 進到廁所 正在拉屎中...
小李0 已用完廁所 正在離開廁所
老張0 進到廁所 正在拉屎中...
老張0 已用完廁所 正在離開廁所
小劉0 進到廁所 正在拉屎中...
小劉0 已用完廁所 正在離開廁所
阿明0 進到廁所 正在拉屎中...
====================>> 螢幕停止輸出後，請按Enter鍵繼續 <<====================
阿明0 已用完廁所 發現廁紙已用完，並按下了報警 正在離開廁所
欣欣0 進到廁所 發現紙用完了，先離開廁所在附近歇息等待訊號
西西0 進到廁所 發現紙用完了，先離開廁所在附近歇息等待訊號
芳芳0 進到廁所 發現紙用完了，先離開廁所在附近歇息等待訊號
公園管理員 等到了紙用盡的報警訊息，並再次搶到了廁所
公園管理員 正在加新紙...
公園管理員 已加上新廁紙，並通過喇叭通知了該訊息，並正在離開廁所
公園管理員 進到廁所 發現紙還沒用完，先離開廁所在等紙用盡的報警訊息
欣欣0 等到了廁紙已加的訊號，並去再次搶到了廁所 正在拉屎中...
欣欣0 已用完廁所 正在離開廁所
芳芳0 等到了廁紙已加的訊號，並去再次搶到了廁所 正在拉屎中...
芳芳0 已用完廁所 正在離開廁所
西西0 等到了廁紙已加的訊號，並去再次搶到了廁所 正在拉屎中...
西西0 已用完廁所 正在離開廁所
老王1 進到廁所 正在拉屎中...
老王1 已用完廁所 正在離開廁所
小李1 進到廁所 正在拉屎中...
小李1 已用完廁所 發現廁紙已用完，並按下了報警 正在離開廁所
老張1 進到廁所 發現紙用完了，先離開廁所在附近歇息等待訊號
公園管理員 等到了紙用盡的報警訊息，並再次搶到了廁所
公園管理員 正在加新紙...
公園管理員 已加上新廁紙，並通過喇叭通知了該訊息，並正在離開廁所
公園管理員 進到廁所 發現紙還沒用完，先離開廁所在等紙用盡的報警訊息
小劉1 進到廁所 正在拉屎中...
小劉1 已用完廁所 正在離開廁所
阿明1 進到廁所 正在拉屎中...
====================>> 螢幕停止輸出後，請按Enter鍵繼續 <<====================
*/
用了 sync.Cond 的程式碼顯然要精簡了很多，而且還節省了計算資源，只會在收到通知的時候 才去搶公共廁所，而不是不斷地反覆去搶公共廁所。通過這個對現實場景的模擬，我們就很容易從使用者的角度理解 sync.Cond 是什麼，它的字面意思就是 「條件」，這就已經點出了這東西的核心要義，就是滿足條件才執行，條件是什麼，訊號其實就是條件，當一個執行體收到訊號之後，它才去爭搶共用資源，否則就會掛起等待（這種等待底層其實會讓出執行緒，所以這種等待並不會空耗資源），比起不斷輪尋去搶資源，這種方式要節省得多。
最後留給讀者一個思考的問題：就是上面最後一版的程式碼，為什麼 當紙用完後按報警按鈕通知 公園管理員 要用 sync.Broadcast() 方法去廣播通知？不是隻通知管理員一個人嗎，單獨通知他不就行了，用 sync.Signal() 為什麼不行？