[go語言]goroutine的一種使用情境

這是一個建立於 的文章，其中的資訊可能已經有所發展或是發生改變。近日在使用go語言寫一個檔案轉換的工具，使用到了goroutine來提高處理效率。在寫代碼的過程中，對goroutine的使用方式經曆了三個版本的變動，我覺得有必要記錄和總結一下，也需要不斷思考怎麼樣才是用go語言的思考去寫go語言代碼。Writeyour Go code in a Go way.
目的：遍曆一個目錄及其子目錄，把某些特定檔案轉換到另外一種檔案儲存到指定目錄下。因為檔案可能有很多，不想每個檔案都對應一個goroutine一下子有非常多goroutine。畢竟CPU的核是固定數量的。雖然同時存在很多很多goroutine也不會同時被執行導致物理線程切換代價高，但是畢竟佔了好多記憶體，而且數量不太能預期。所以打算尋找一種方法能盡量提高CPU使用效率，同時又控制goroutine的數量。
第一個版本：並發方式是採用經典的生產者消費者模型，一個生產者把遍曆到的檔案路徑通過訊息佇列交給多個在此訊息佇列上等待的消費者。
//遍曆指定目錄，把合格檔案路徑轉給回呼函數collect，實現略。func walk(path string, collectfunc(string))// 檔案轉換，實現略。func convert(file string)
進行處理。func main() {

var wg sync.WaitGroup

// 訊息佇列

ch := make(chan string,runtime.NumCPU())

// 建立消費者

for i := 0; i <runtime.NumCPU(); i++ {

go func() {

for {

file := <-ch

convert(file)

wg.Done()

}

}()

}

// 生產者

walk(path, func(filestring){

wg.Add(1)

ch <- file

})

// 等待所有檔案處理完成

wg.Wait()

}第一個版本的問題是處理邏輯分離了，很明顯的分裂成兩部分生產者邏輯和消費者邏輯，而我的目的是想讓代碼邏輯盡量的看上去序列化，像一個順序程式一樣，這樣就比較清晰易懂。所以需要盡量把生產者邏輯和消費者的邏輯放在一起。
第二個版本：還是訊息佇列，但是訊息佇列中的訊息不是資料，而是函數。消費者只要執行這個函數，不需要關心這個函數的實現和它的商務邏輯。func main(){

var wgsync.WaitGroup

//訊息佇列

ch :=make(chan func(), runtime.NumCPU())

//建立消費者

for i := 0; i< runtime.NumCPU(); i++ {

go func(){

for{

f :=<- ch

f()

}

}()

}

//生產者

walk(path,func(file string){

wg.Add(1)

ch<- func() {

convert(file)

wg.Done()

}

})

//等待所有檔案處理完成

wg.Wait()

}這個版本好多了，擷取檔案和處理檔案的商務邏輯都在一起，不會導致思維上的跳躍。但是能不能更好一些呢？那個消費者goroutine的代碼既然和商務邏輯沒有直接關係，有沒有可能精簡掉？
第三個版本：第三個版本把訊息佇列去掉了，換成數量有限的令牌，要處理一個檔案必須先獲得令牌，使用完成後再歸還。獲得令牌是阻塞的，如果暫時沒有令牌可以獲得就會阻塞在上面，避免產生過多的數量不可控的goroutine。令牌和訊息佇列一樣還是用channel實現，但是意義已經不一樣了。func main(){

var wgsync.WaitGroup

//產生指定數量的令牌

tokens :=make(chan int, runtime.NumCPU())

walk(path, func(file string){

tokens<- 1 // 擷取令牌wg.Add(1)

go func() {

convert(file)

wg.Done()

<-tokens // 歸還令牌

}()

})

//等待所有檔案處理完成

wg.Wait()

}現在的代碼就比較清晰直觀，而且程式碼也少了許多。