如何把 golang 的 Channel 玩出 async 和 await 的 feel

jeremy1127發表於2020-02-21
GolangAI

如何優雅的同步化非同步程式碼，一直以來都是各大程式語言致力於最佳化的點，記得最早是C# 5.0加入了async/await來簡化TPL的多執行緒模型，後來Javascript的Promise也吸取這一語法糖，在ES 6中也加入了async和await.

那麼，被大家一稱讚併發效能好、非同步模型獨樹一幟的golang，能否也有async和await呢？

其實，這對於golang的CSM來說是一點也不難！

核心程式碼如下：

done := make(chan struct{})
go func() {
    // do work asynchronously here
    //
    close(done)
}()
<-done

是不是很簡單呢？ go rountine負責async， channel的負責await, 簡直是完美！

但這個程式碼看起來還是有點醜，而且這個go func(){}還沒有返回值，雖說可以透過閉包來接收返回值，但那個程式碼就更難維護了。

程式碼難看不要緊，只要Don’t repeat yourself (DRY)，封裝一下不就好了？

type WorkFunc func() (interface{}, error)

func NewPromise(workFunc WorkFunc) *Promise {
    promise := Promise{done: make(chan struct{})}
    go func() {
        defer close(promise.done)
        promise.res, promise.err = workFunc()
    }()
    return &promise
}

func (p *Promise) Done() (interface{}, error) {
    <-p.done
    return p.res, p.err
}

呼叫的程式碼如下：

promise := NewPromise(func() (interface{}, error) {
    // do work asynchronously here
    //
    return res, err
})

// await
res, err := promise.Done()

是不是美觀了許多呢？

這個實現和Javascript的Promise的API是有很大差距，使用體驗上因為golang沒有泛型，也需要轉來轉去的，但為了不辜負Promise這個名字，怎麼能沒有then呢？

type SuccessHandler func(interface{}) (interface{}, error)

type ErrorHandler func(error) interface{}

func (p *Promise) Then(successHandler SuccessHandler, errorHandler ErrorHandler) *Promise {
    newPromise := &Promise{done: make(chan struct{})}
    go func() {
        res, err := p.Done()
        defer close(newPromise.done)
        if err != nil {
            if errorHandler != nil {
                newPromise.res = errorHandler(err)
            } else {
                newPromise.err = err
            }
        } else {
            if successHandler != nil {
                newPromise.res, newPromise.err = successHandler(res)
            } else {
                newPromise.res = res
            }
        }
    }()

    return newPromise
}

有了then可以chain起來，是不是找到些Promise的感覺呢？

完整程式碼請檢視 promise.go

本來我的理解也就到些了，然後前段時間（說來也是一月有餘了），看了Go併發設計模式之 Active Object這篇文章後， 發現如果有一個常駐協程在非同步的處理任務，而且是FIFO的，那麼這其實是相當於一個無鎖的設計，可以簡化對臨界資源的操作。

於是，我照著文章的思路，實現了下面的程式碼：

// Creates a new actor
func NewActor(setActorOptionFuncs ...SetActorOptionFunc) *Actor {
    actor := &Actor{buffer: runtime.NumCPU(), quit: make(chan struct{}), wg: &sync.WaitGroup{}}
    for _, setOptionFunc := range setActorOptionFuncs {
        setOptionFunc(actor)
    }

    actor.queue = make(chan request, actor.buffer)

    actor.wg.Add(1)
    go actor.schedule()

    return actor
}

// The long live go routine to run.
func (actor *Actor) schedule() {
loop:
    for {
        select {
        case request := <-actor.queue:
            request.promise.res, request.promise.err = request.work()
            close(request.promise.done)
        case <-actor.quit:
            break loop
        }
    }
    actor.wg.Done()
}

// Do a work.
func (actor *Actor) Do(workFunc WorkFunc) *Promise {
    methodRequest := request{work: workFunc, promise: &Promise{
        done: make(chan struct{}),
    }}
    actor.queue <- methodRequest
    return methodRequest.promise
}

// Close actor
func (actor *Actor) Close() {
    close(actor.quit)
    actor.wg.Wait()
}

一個簡單的沒啥意義的純粹為了demo的測試用例如下：

func TestActorAsQueue(t *testing.T) {
    actor := NewActor()
    defer actor.Close()

    i := 0
    workFunc := func() (interface{}, error) {
        time.Sleep(1 * time.Second)
        i++
        return i, nil
    }

    promise := actor.Do(workFunc)
    promise2 := actor.Do(workFunc)

    res2, _ := promise2.Done()
    res1, _ := promise.Done()

    if res1 != 1 {
        t.Fail()
    }

    if res2 != 2 {
        t.Fail()
    }
}

完整程式碼請檢視 actor.go

每個語言都有它的獨特之處，在我的理解中，玩轉golang的CSM模型，channel一定要用的6。

於是，我建立了Channelx這個repo, 包含了對channel常用場景的封裝，歡迎大家審閱，喜歡的就點個star。

此係列其它文章：

如何用Golang的channel實現訊息的批次處理

如何把Golang的channel用的如nodejs的stream一樣絲滑

本作品採用《CC 協議》，轉載必須註明作者和本文連結

相關文章