无锁编程 - Double-checked Locking

Double-checked Locking，严格意义上来讲不属于无锁范畴，无论什么时候当临界区中的代码仅仅需要加锁一次，同时当其获取锁的时候必须是线程安全的，此时就可以利用 Double-checked Locking 模式来减少锁竞争和加锁载荷。目前Double-checkedLocking已经广泛应用于单例 (Singleton)模式中。

Double-checked Locking有以下特点：

Double-checked Locking模式是Singleton的多线程版本。 Double-checked Locking模式依旧会使用锁——临界区锁定，不要以为可以避免使用锁。 Double-checked Locking解决的问题是：当多个线程存在访问临界区企图时，保证了临界区只需要访问一次。

以Singleton为例，为了防止多次分配，通常Singleton的实现方式是：

// 实现1

Class singleton
{
	singleton* get_instance()
	{
		lock();
		if (instance == 0)
		{
			instance = new singleton;
		}
		unlock();
		return instance;
	}
}

这里存在的问题是：无论是否已经初始化都要加锁，增加了负荷，已经没有所谓的并发性能了。

要增加并发性能，可以先判断是否已经分配，在没分配的情况下才加锁，也许你想要改成下面这个样子：

// 实现2

Class singleton
{
	singleton* get_instance()
	{
		if (instance == 0)
		{
			lock();
			instance = new singleton;
			unlock();
		}
		return instance;
	}
}

这里存在的问题是：不能保证临界区只初始化一次,没能实现singleton的基本功能。

// 实现3 - Double-checkedLocking

Class singleton
{
	singleton* get_instance()
	{
		if (instance == 0)
		{
			lock();
			if (instance == 0 )
			{
				instance = new singleton;
			}
			unlock();
		}
		return instance;
	}
}

严格的说，Double-checked locking不属于无锁编程的范畴，但由原来的每次加锁访问到大多数情况下无须加锁，就是一个巨大的进步。

golang 设计模式之singleton：

golang 1.5版本之后默认设置GOMAXPROCS值为当前计算机真实核心数，使得goroutines从默认的单线程内并发执行变成了默认的（真实核心数支持的）的多线程内并行执行。多线程并行执行goroutines需要考虑并行执行过程中引入的线程安全问题。

单线程singleton模型

单例模式定义：保证一个类仅有一个实例，并提供一个访问它的全局访问点。先摘取一个在实际工作项目中碰到的singleton模型代码:

1 2 3 4 5 6 7 8 9 10 11 12 13

package singleton type singleton struct { } var instance *singleton func GetInstance() *singleton { if instance == nil { instance = &singleton{} // 没有考虑线程安全 } return instance }

上面的singleton设计代码在见过的几个golang项目中都是这么写的，如果这段代码放在golang1.5版本之前默认的单线程场景下运行显然是没什么问题的。golang1.5版本之后默认是启动多核并行执行goroutines的，如果上述代码放在golang1.5版本之后，如果程序开启n个goroutines初始化一个singleton对象, 显然会初始化成功最少一个最多n个singleton对象，从而会存在潜在的多个单例实例对象了，也就不可能保证这个singleton对象全局唯一性了，那后继采用singleton对象进行全局唯一性操作时势必会造成数据不一致的问题。如果场景中但个goroutines执行时间短的话，会使得调试更难。

采用互斥锁机制

面对上述线程安全问题，一般会考虑到用锁机制(Mutex)来解决因线程安全引入的数据不一致问题，采用锁机制如：

1 2 3 4 5 6 7 8 9 10 11

var mu Sync.Mutex func GetInstance() *singleton { mu.Lock() // singleton实例对象操作之后，锁就是多余的了 defer mu.Unlock() if instance == nil { instance = &singleton{} } return instance }

上述代码可以看到，引入锁机制Sync.Mutex后，能够保证多线程并行执行goroutines创建的singleton实例对象是唯一的，但是当这个singleton实例对象被初始化创建之后，再次并行来创建singleton实例对象时，其实已经不再需要锁了，因为已经存在了一个创建好的singleton实例对象，所以直接返回即可;但是因为锁机制的存在，使得再次创建singleton实例对象时，还是需要先获取锁，然后在判断处理，多线程执行中这种锁竞争使得多线程的并行执行变成了多线程的串行执行，这显然会使程序丧失并行执行带来的性能提升。在一个高度并行的程序中，这样显示会是抑制程序性能提升的一个瓶颈。

采用双重检查锁机制

在C++等编程语言中，为了同时保证最小锁和线程安全通常采用的方法是双重检查锁(Check-Lock-Check)机制，也表述为DCL(Double Check Lock)。双重检查锁机制的伪代码一般是下面的这种形式:

1 2 3 4 5 6 7

if check() { lock() { if check() { // 锁安全代码 } } }

其实对这个singleton实例对象来说，只有在第一次创建实例的时候才需要同步，所以为了减少同步，先check一下，判断singleton实例对象是否为空，如果为空，表示是第一使用这个singleton实例对象，那就锁住它，new一个singleton实例，下次另一个线程来GetInstance的时候，看到这个singleton实例对象不为空，就表示已经创建过一个实例了，那就可以直接得到这个实例，避免再次锁。这是第一个 check的作用。

第二个check是解决锁竞争情况下的问题，假设现在两个线程来请求GetInstance，A、B线程同时发现singleton实例对象为空，因为我们在第一次check方法上没有加锁，然后A线程率先获得锁，进入同步代码块，new了一个singleton实例对象，之后释放锁，接着B线程获得了这个锁，发现singleton实例对象已经被创建了，就直接释放锁，退出同步代码块。所以这就是Check-Lock-Check; 将上面的singleton实例用Check-Lock-Check机制实现如：

1 2 3 4 5 6 7 8 9 10 11

func GetInstance() *singleton { if instance == nil { mu.Lock() defer mu.Unlock() if instance == nil { instance = &singleton{} } } return instance }

通过上面的Check-Lock-Check机制,的确可以解决锁竟争的问题，但是这种方法不管是否singleton实例对象是否已创建，每次都要执行两次check才是一个完整的判断，那有没有方法使得只要一次check就可以完成对singleton实例对象是否存在的检查呢？ 有！通过golang的sync/atomic包提供的原子性操作可以更高效的完成这个检查，改进代码如：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

import "sync" import "sync/atomic" var initialized uint32 ... func GetInstance() *singleton { if atomic.LoadUInt32(&initialized) == 1 { return instance } mu.Lock() defer mu.Unlock() if initialized == 0 { instance = &singleton{} atomic.StoreUint32(&initialized, 1) } return instance }

改进之后的代码通过设置一个标志操作，使得singleton实例对象创建之后，直接通过原子操作读取标志字段的值判断返回已经存在的实例，连锁操作及其后面的代码都略过了。

采用atomic进一步简化

上面通过Check-Lock-Check机制改进之后似乎没有什么可做的了，先不急，来看看golang原生标准包sync包中对Once实现的源码：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36

// Once is an object that will perform exactly one action. type Once struct { m Mutex done uint32 } // Do calls the function f if and only if Do is being called for the // first time for this instance of Once. In other words, given // var once Once // if once.Do(f) is called multiple times, only the first call will invoke f, // even if f has a different value in each invocation. A new instance of // Once is required for each function to execute. // // Do is intended for initialization that must be run exactly once. Since f // is niladic, it may be necessary to use a function literal to capture the // arguments to a function to be invoked by Do: // config.once.Do(func() { config.init(filename) }) // // Because no call to Do returns until the one call to f returns, if f causes // Do to be called, it will deadlock. // // If f panics, Do considers it to have returned; future calls of Do return // without calling f. // func (o *Once) Do(f func()) { if atomic.LoadUint32(&o.done) == 1 { // <-- Check return } // Slow-path. o.m.Lock() // <-- Lock defer o.m.Unlock() if o.done == 0 { // <-- Check defer atomic.StoreUint32(&o.done, 1) f() } }

可以看到我们之前其实是借鉴了golang原生标准包sync中对Once实现对源码，那既然标准包中已经实现了这个Check-Lock-Check机制，那我们直接调用sync包提供once.Do()方法对某个方法只进行一次性调用：

1 2 3

once.Do(func() { // perform safe initialization here }

那么下面是根据sync包提供的sync.Once改进的获取singleton实例对象最终优化版本:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

package singleton import ( "sync" ) type singleton struct { } var instance *singleton var once sync.Once func GetInstance() *singleton { once.Do(func() { instance = &singleton{} }) return instance }

因此使用sync包提供的sync.Once实现获取singleton实例对象可以说是最安全有效又简洁的方法。