golang一個例子引出的幾個問題

這是一個建立於 的文章，其中的資訊可能已經有所發展或是發生改變。

這個例子是從go源碼src/pkg/net/rpc/server_test.go截取出來的

func benchmarkEndToEndAsync(dial func() (*Client, error), b *testing.B) {     const MaxConcurrentCalls = 100     b.StopTimer()     once.Do(startServer)     client, err := dial()     if err != nil {          b.Fatal("error dialing:", err)     }     // Asynchronous calls     args := &Args{7, 8}     procs := 4 * runtime.GOMAXPROCS(-1)     send := int32(b.N)     recv := int32(b.N)     var wg sync.WaitGroup     wg.Add(procs)     gate := make(chan bool, MaxConcurrentCalls)     res := make(chan *Call, MaxConcurrentCalls)     b.StartTimer()     for p := 0; p < procs; p++ {          go func() {               for atomic.AddInt32(&send, -1) >= 0 {                    gate <- true                    reply := new(Reply)                    client.Go("Arith.Add", args, reply, res)               }          }()          go func() {               for call := range res {                    A := call.Args.(*Args).A                    B := call.Args.(*Args).B                    C := call.Reply.(*Reply).C                    if A+B != C {                         b.Fatalf("incorrect reply: Add: expected %d got %d", A+B, C)                    }                    <-gate                    if atomic.AddInt32(&recv, -1) == 0 {                         close(res)                    }               }               wg.Done()          }()     }     wg.Wait()}

這個代碼用來對rpc的用戶端Go函數進行壓力測試。

這裡有幾個地方值得揣摩下:

1 如何測試用戶端服務端？

先使用startServer（這個函數裡面具體是開啟了一個routine）進行伺服器服務。然後在每個測試案例中啟動server，如果是benchTest的話記得這裡的Timer要在啟動伺服器行為之後再開啟。

2 這裡的wg變數有什麼用？

wg變數是sync.WaitGroup類型，Add增加計數，Done減少計數，Wait進行阻塞等待，等計數減為0的時候再停止阻塞。

這裡如果不使用WaitGroup進行wait阻塞的話，主routine會先於次routine先結束。會導致程式提早退出。

因此這裡也給出了一個測試案例中測試非同步函數的方法。就是使用WaitGroup

3 為什麼要有gate這個channel buffer？

看起來gate好像是沒什麼用啊，如果去掉gate呢？有可能會出現“rpc: discarding Call reply due to insufficient Done chan capacity”

這個gate完全是因為client.Go這個函數，rpc包的client.Go是非同步調用，雖然是非同步呼叫，這個非同步呼叫的最後一個done參數是一個channel buffer。

當client.Go進行完rpc調用後，將訊號傳入這個channel buffer。但是這個channel buffer卻是不會阻塞的。

具體看源碼：

這裡select加了個default分支，說明了done是非阻塞的。看注釋，作者認為這個buffer的大小容量應該由調用者來保證。rpc包並不保證容量大小。

在並發情況下，我們使用Client.Go的時候就要自己保證channel buffer大小。

方法有個兩個：

1 使用一個同樣大小的channel buffer來進行阻塞保證。

這個方法就是gate的使用原因了。只有gate容量有剩餘的時候才會容許調用client.Go

2 調大channel buffer大小

在這個例子中，bench的channel最大隻會是b.N，所以，如果我們分配的res的channel buffer大小為b.N也能解決這個問題。

這個方法導致的效果就是bench的時間變快了，但是mem分配增加了。

4 這裡的atomic什麼作用？

因為這裡會有多個routine會對send和recive進行操作，這裡就需要保證原子性。

多個並發routine對一個共用變數進行操作有兩種方法，channel和鎖。

這裡當然使用channel也能起到原子操作的效果。sync包的atomic和sync的mutex都是鎖的方式。

所以說這裡其實可以使用channel，mutex，atomic三種方法。

5 procs的作用？

bench test在運行前自身會調用runtime.GOMAXPROCS進行多核的設定，然後再每個處理器中並行運行測試。

這裡的runtime.GOMAXPROCS(-1)是擷取你要跑的cpu核心數，這個核心數是根據bench test的 -test.cpu設定的。具體可以看下src/testing/testing.go parseCpuList。在沒有設定過GOMAXPROCS和test.cpu的情況下，這裡的runtime.GoMAXPROCS就預設是1。

你可以使用-test.cpu 1,2,4來設定你的壓力測試用例是有幾個cpu，每個cpu是幾核的。

這裡的procs設定為處理器核心數的4倍就是為了測試routine能分配遠大於核心數的個數，這樣每個核承擔的goroutine能大於1。

上面的for迴圈就是保證起的routine數是足夠的。