[譯]Go使用封裝返回模式回收被goroutines佔用的內存

原文：medium.com/@cep21/gos-…

問題

當咱們有一個後臺運行的goroutines經過其內部的構造函數建立一個對象之後，咱們但願這個對象即便在goroutines沒有被及時關閉之後，還能及時被垃圾回收。這是不可能的由於後臺運行goroutines會一直運行而且會指向這個對象上。

解決方法

咱們將這個返回的對象封裝一下，而後在這個對象上使用finalizer，從而達到關閉後臺goroutines的目的。

舉個栗子

假設咱們如今有個Go的靜態客戶端go-statsd-client，它會建立一個BufferedSender以下：

func NewBufferedSender(addr string, flushInterval time.Duration, flushBytes int) (Sender, error) {
	simpleSender, err := NewSimpleSender(addr)
	if err != nil {
		return nil, err
	}

	sender := &BufferedSender{
		flushBytes:    flushBytes,
		flushInterval: flushInterval,
		sender:        simpleSender,
		buffer:        senderPool.Get(),
		shutdown:      make(chan chan error),
	}

	sender.Start()
	return sender, nil
}
複製代碼

Start方法複製建立一個gorutinues來按期刷新BufferedSender。

func (s *BufferedSender) Start() {
	// write lock to start running
	s.runmx.Lock()
	defer s.runmx.Unlock()
	if s.running {
		return
	}

	s.running = true
	s.bufs = make(chan *bytes.Buffer, 32)
	go s.run()
}
複製代碼

咱們如今建立而且使用這個BufferedSender看看會發生什麼

func Process() {
  x := statsd.NewBufferedSender("localhost:2125", time.Second, 1024)
  x.Inc("stat", 1, .1)
}
複製代碼

最開始main gorotinues是指向x，但當咱們退出Process的時候BufferedSender仍然在運行，由於Start所啓動的goruntinues沒有中止。

咱們至關於泄漏了BufferedSender的內存由於咱們忘記調用Close來關閉它了。

解決方案

參考一下Go的緩存庫go-cache。你會注意到Cache其實只是一個封裝。

type Cache struct {
	*cache
	// If this is confusing, see the comment at the bottom of New()
}

type cache struct {
	defaultExpiration time.Duration
	items             map[string]Item
	mu                sync.RWMutex
	onEvicted         func(string, interface{}) janitor *janitor } 複製代碼

當你new一個Cache對象的時候，他將返回一個代理者，代理者指向被封裝的對象cache，而不是返回的對象Cache

func New(defaultExpiration, cleanupInterval time.Duration) *Cache {
	items := make(map[string]Item)
	return newCacheWithJanitor(defaultExpiration, cleanupInterval, items)
}

func newCacheWithJanitor(de time.Duration, ci time.Duration, m map[string]Item) *Cache {
	c := newCache(de, m)
	// This trick ensures that the janitor goroutine (which--granted it
	// was enabled--is running DeleteExpired on c forever) does not keep
	// the returned C object from being garbage collected. When it is
	// garbage collected, the finalizer stops the janitor goroutine, after
	// which c can be collected.
	C := &Cache{c}
	if ci > 0 {
		runJanitor(c, ci)
		runtime.SetFinalizer(C, stopJanitor)
	}
	return C
}

func runJanitor(c *cache, ci time.Duration) {
	j := &janitor{
		Interval: ci,
		stop:     make(chan bool),
	}
	c.janitor = j
	go j.Run(c)
}
複製代碼

參考它把咱們代碼改爲

func Process() {
  x := cache.New(time.Second, time.Minute)
}
複製代碼

很是重要的區別的是這裏的Cache是能夠被垃圾回收的，即便cache對象並不能被回收。咱們將GC行爲器SetFinalizer設置在cache上。stopJanitor函數會通知後臺運行的goruntines中止運行。

runtime.SetFinalizer(C, stopJanitor)
...
...
func stopJanitor(c *Cache) {
	c.janitor.stop <- true
}
複製代碼

當後臺gorutinues被中止之後，就沒有東西再繼續指向cache了。

而後它就會被垃圾回收。

何時使用它

這實際上是取決於用你這個庫的用戶是怎麼想的，他們是否但願能明確地建立並能關閉後臺進程。Go的http.Serve就是一個很好的例子。注意到這裏不是func NewHTTPServer() *http.Server，而是使用一個對象，而且用戶能夠在準備就緒時顯式啓動（或中止）服務器。

基於這個最佳實現，若是你確實想控制你的後臺進程在何時被關閉的時候，你仍然應該暴露一個Close函數容許用戶關閉後臺gorutines來達到回收內存的目的。可是若是你認爲讓用戶本身去調用Close比較麻煩，你就能夠加一個finalizer的封裝來確保內潤以及你所建立的goruntinue能在最後被正確地回收無論有沒有調用Close