defer增大临界区的解决方案

引言

在并发数量较大的情况下，我们应该尽可能的让临界区变的小，减少资源竞争的时间，提高性能。

在 Glang 中，如果我们使用 defer unlock() 操作，会让临界区编程从lock()开始到整个函数结束，会影响性能。

最初版本

type Counter struct {
	count int
	mutex sync.Mutex
}

func(c *Counter) Incr() {
	// mutex开始
	c.mutex.Lock()
	defer c.mutex.Unlock()
	c.count++
	fmt.Println(c.count)
	// mutex结束
}

func(c *Counter) Get() int {
	c.mutex.Lock()
	defer c.mutex.Unlock()
	return c.count
}

func main() {
	var wg sync.WaitGroup
	wg.Add(10)
	var cnt Counter
	for i := 0; i < 10; i++ {
		go func() {
			defer wg.Done()
			for i := 0; i < 10000; i++ {
				cnt.Incr()
			}
		}()
	}
	wg.Wait()
	fmt.Println(cnt.Get())
}

我们发现，虽然程序正常运行，但是 Incr方法中的临界区变大了，而真实的临界区在 c.count++ 完成后就应该结束。

在更复杂的场景以及并发量更大的场景下，临界区过大势必会影响性能。

解决方案一

首先我们可能想到，利用块级作用域来管理这把锁。但是随后我们就会发现，这样不仅每次都需要创建锁，而且如果程序panic，我们还无法释放锁。

{
    var mu sync.Mutex
    mu.Lock()
    // 代码块
    mu.UnLock()
}

所以，这种方法我们放弃。

解决方案二

我们可以利用匿名函数以及闭包的特性，来实现限制临界区的功能。


package main

import (
	"fmt"
	"sync"
)

type Counter struct {
	count int
	mutex sync.Mutex
}

func(c *Counter) Incr() {
	func() {
		// mutex开始
		c.mutex.Lock()
		defer c.mutex.Unlock()
		c.count++
		// mutex结束
	}()
	fmt.Println(c.count)
}

func(c *Counter) Get() int {
	return func() int{
		// mutex开始
		c.mutex.Lock()
		defer c.mutex.Unlock()
		// mutex结束
		return c.count
	}()
}

func main() {
	var wg sync.WaitGroup
	wg.Add(10)
	var cnt Counter
	for i := 0; i < 10; i++ {
		go func() {
			defer wg.Done()
			for i := 0; i < 10000; i++ {
				cnt.Incr()
			}
		}()
	}
	wg.Wait()
	fmt.Println(cnt.Get())
}