Golang 探索對Goroutine的控制方法

前言

在golang中，只須要在函數調用前加上關鍵字go便可建立一個併發任務單元，而這個新建的任務會被放入隊列中，等待調度器安排。相比系統的MB級別線程棧，goroutine的自定義棧只有2KB，這使得咱們可以輕易建立上萬個併發任務，如此對性能提高很多。但隨之而來的有如下幾個問題：

• 如何等待全部goroutine的退出
• 如何限制建立goroutine的數量（信號量實現）
• 怎麼讓goroutine主動退出
• 探索——如何從外部殺死goroutine

本文記錄了筆者就以上幾個問題進行探究的過程，文中給出了大部分問題的解決方案，同時也拋出了未解決的問題，期待與各位交流：p

準備

開始以前先定義一個常量const N=100以及一個HeavyWork函數，假定該函數具備極其冗長、複雜度高、難以解耦的特性

func HeavyWork(id int) {
    rand.Seed(int64(id))
    interval := time.Duration(rand.Intn(3)+1) * time.Second
    time.Sleep(interval)
    fmt.Printf("HeavyWork %-3d cost %v\n", id, interval)
}

以上定義的內容將在以後的代碼中直接使用以縮減篇幅，大部分完整代碼可在 Github: explore-goroutine 中找到

如何等待全部goroutine的退出

"Do not communicate by sharing memory; instead, share memory by communicating"——GO的一大設計哲學《Share Memory By Communicating》
翻譯成中文就是，用通訊來共享內存數據，而不要經過共享內存數據來進行通訊。
Go中的goroutines和channel提供了一種優雅而獨特的結構化併發軟件的方法，咱們能夠利用通道(channel)的特性，來實現當前等待goroutine的操做。可是channel並非當前這個場景的最佳方案，用它來實現的方式是稍顯笨拙的，須要知道肯定個數的goroutine，同時稍不注意就極易產生死鎖，代碼以下:

// "talk is cheap, show me the code."
func main() {
    waitChan := make(chan int, 1)
    for i := 0; i < N; i++ {
        go func(n int) {
            HeavyWork(n)
            waitChan <- 1
        }(i)
    }
    cnt := 0
    for range waitChan {
        cnt++
        if cnt == N {
            break
        }
    }
    close(waitChan)
    fmt.Println("finished")
}

上述代碼使用了一個緩存大小爲1的通道(channel)，建立N個goroutine用於運行HeavyWork，每一個任務完成後向waitChan寫入一個數據，在收到N個完成信號後退出。
但事實上比較優雅的方式是使用go標準庫sync，其中提供了專門的解決方案sync.WaitGroup用於等待一個goroutines集合的結束

// "talk is cheap, show me the code."
func main() {
    wg := sync.WaitGroup{}
    for i := 0; i < N; i++ {
        wg.Add(1)
        go func(n int) {
            defer wg.Done()
            HeavyWork(n)
        }(i)
    }
    wg.Wait()
    fmt.Println("finished")
}

關於sync.WaitGroup的具體使用請參照官方文檔 [GoDoc] sync.WaitGroup ，這裏再也不贅述

如何限制goroutine的建立數量（信號量實現）

信號量(Semaphore)，有時被稱爲信號燈，是在多線程環境下使用的一種設施，是能夠用來保證兩個或多個關鍵代碼段不被併發調用。

其中V操做會增長信號量的數值即釋放資源，而P操做會減小它即佔用資源

那麼很是容易想到的就是利用channel（通道）緩存有限的特性，它容許咱們能夠自實現一個簡單的數量控制，就如同使用信號量通常，在這基礎再加上前面提到的sync.WaitGroup，咱們能夠打出一套組合拳，提供可阻塞的信號量PV操做，可以實現固定建立goroutine數量而且支持等待當前goroutine的退出。結構體定義以下：

type Semaphore struct {
    Threads chan int
    Wg      sync.WaitGroup
}

而P操做只需在channel中加入一個元素同時調用WaitGroup.Add便可，這一操做完成對資源的申請

func (sem *Semaphore) P() {
    sem.Threads <- 1
    sem.Wg.Add(1)
}

相反則是V操做，進行資源的釋放

func (sem *Semaphore) V() {
    sem.Wg.Done()
    <-sem.Threads
}

Wait則阻塞等待直到當前全部資源都歸還，直接調用WaitGroup的方法便可

func (sem *Semaphore) Wait() {
    sem.Wg.Wait()
}

完整代碼能夠在 Github: semaphore 中查看

利用上面的信號量就能夠作到，在一個時刻的goroutines數量不會超過信號量值的大小，而某個goroutine退出後將返還佔用的信號量，而正在等待的goroutine就能夠當即申請，下圖形象地展示了運行時的狀態

怎麼讓goroutine主動退出

對於goroutine的主動退出，比較友好的作法就是循環監聽一個channel，經過相似信號的方式來告知goroutine的」該退出了「，而後goroutine本身主動退出，這種作法在網上十分常見，也是Golang官方推薦的作法，思想也很簡單。

func main() {
    ok, quit := make(chan int, 1), make(chan int, 1)
    go func() {
        i := 0
        for {
            select {
            case <-quit:
                ok <- 1
                return
            default:
                HeavyWork(i)
                i++
            }
        }
    }()
    time.Sleep(5 * time.Second)
    quit <- 1
    <-ok
}

運行結果以下圖

探索——如何從外部殺死goroutine

上面講了一些關於goroutines和channel的簡單使用，接下來終於寫到本文的重點了。筆者並無解決如何從外部殺死一個goroutine，但記錄了嘗試「殺死」中的可行或不可行方法，但願對各位有所幫助。
由於近期在開發中遇到這樣一個問題，當一個函數是極其冗長、複雜度高、難以解耦的順序結構代碼時（例如某個極其複雜無循環結構的加密算法），並且因爲數據量巨大，須要反覆調用該函數，因爲每運行一次，程序都會消耗大量的時間、空間，那麼當一個任務已經被用戶拋棄時，如何才能拋棄仍在作着無用功的goroutine？

爲了達到「殺死goroutine」的目的，筆者作了不少嘗試，如

• select結構（條件實現）
• panic退出機制（失敗）
• 獲取pid殺死（失敗）
• ptrace單步調試（失敗）
• ...（失敗）

利用select語句實現

關於「如何殺死goroutine」，網上有一部分答案就是利用select實現的，可是這種方式實現的代碼並不適用於服務類的程序，可是對於通常非服務類程序的確可以實現殺死goroutine的效果，代碼以下：

func main() {
    wrapper := func() chan int {
        c := make(chan int)
        go func() {
            HeavyWork(0)
            c <- 1
        }()
        return c
    }
    select {
    case <-wrapper():
    case <-time.After(1 * time.Second):
        fmt.Println("time limit exceed")
    }
    // time.Sleep(3 * time.Second)
}

可是一旦主函數沒有當即退出，而是做爲某種服務而繼續運行時，這裏刪除了main函數的最後一行註釋time.Sleep(3 * time.Second)，延遲三秒後退出。能夠看見儘管已經超時並輸出"time limit exceed"以後，HeavyWork在main函數沒退出前依舊在運行。效果以下

因此使用select-timeout的方式比較適合實時退出類型的程序，可以實現必定程度上的併發控制，

小結

就目前而言，尚未完美的方案來解決控制goroutine的問題，事實上Go彷佛並不容許和推薦人們直接控制goroutine，因此暫時還沒法作到從外部直接控制goroutine的生命週期，因此比較推薦的作法仍是隻能經過goroutine主動退出的方法，循環監聽channel，在發出退出信號後最多隻消耗一輪資源後就退出，但這就要求該代碼具備循環結構不然就很難使用。有更好解決方案的朋友，請務必告訴我！

轉載請註明出處：http://www.cnblogs.com/tr3e/p/7995689.html