多用派发队列,少用同步锁

来源 ——《Effective Objective-C 2.0 》Matt Galloway

在OC中,如果有多个线程要执行同一份代码,那么有时可能会出现问题。这种情况下,通常要使用锁来实现某种同步机制。在GCD出现之前,有两种方法,第一种是采用同步块(synchronization block):

这种写法会根据给定的对象,自动创建一个锁,并等待块中的代码执行完毕。执行到这段代码结尾处,锁就释放了。在本例中,同步行为所针对的对象是self。这样写通常没错,因为它可以保证每个对象实例都能不受干扰地运行其synchronizedMethod。然而,滥用@synchronized(self)则会降低代码效率,因为公用同一个锁的那些同步块,都必须按顺序执行。若是在self对象上频繁加锁,那么程序可能要等另一段与此无关的代码执行完毕,才能继续执行当前代码,这样做其实并没有必要。

另一个方法是直接使用NSLock对象:

也可以使用NSRecursiveLock这种”递归锁”(recursive lock),线程能够多次持有该锁,而不会出现死锁(deadlock)现象。
这两种方法都很好,不过也有其缺陷。比方说,在极端情况下,同步锁会导致死锁,另外,其效率也不见得很高,而如果直接使用锁对象的话,一旦遇到死锁,就会变得非常麻烦。
替代方案是使用GCD,它能以更简单、高效的形式为代码加锁。比方说,属性就是开发者经常需要同步的地方,这种属性需要做成”原子的”。用atomic特质来修饰属性,即可实现这一点。而开发者如果想自己来编写访问方法的话,那么通常会这样写:

刚才所说,滥用@synchronized(self)会很危险,因为所有同步块都会彼此抢夺同一个锁。要是有很多个属性都这么写的话,那么每个属性的同步块都要等其他所有同步块执行完毕才能执行,这也许并不是开发者想要的效果。我们只想要令每个属性各自独立地同步。
顺便说下,这么做虽然能提供某种程度的”线程安全”(thread safety),但却无法保证访问该对象时绝对是线程安全的。当然,访问属性的操作确实”原子的” 。使用属性时,必能从中获取到有效值,然而在同一个线程上多次调用获取方法(geter),每次获取到的结果却未必相同。在两次访问操作之间,其他线程可能会写入新的属性值。
有种简单而高效的办法可以代替同步块或锁对象,那就是使用”串行同步队列”(serial synchronization queue)。将读取操作及写入操作都安排在同一个队列里,即可保证数据同步。其用法如下:

此模式的思路是:把设置操作与获取操作都安排在序列化的队列里面执行,这样的话,所有针对属性的访问操作就都同步了。为了使块代码能都在设置局部变量,获取方法中用到了_block语法,若是抛开这一点,那么这种写法要比前面那些更为整洁。全部加锁任务都在GCD中处理,而GCD是在相当深的底层来实现的,于是能够做许多优化。因此,开发者无须担心那些事,只要专心把访问方法写好就行。
然而还可以进一步优化。设置方法并不一定非得是同步的。设置实例变量所用的块,并不需要向设置方法返回什么值。也就是说,设置方法可以改写成下面这样:

这次只是把同步派发改成了异步派发,从调用者的角度看,这个小改动可以提升设置方法的执行速度,而读取操作与写入操作依然会按顺序执行。但这么改有个坏处:如果你测一下程序性能,那么可能会发现这种写法比原来慢,因为执行异步派发时,需要拷贝块。若拷贝块所用的时间明显超过执行块所花的时间,则这种做法将比原来更慢。
多个获取方法可以并发执行,而获取方法与设置方法之间不能并发执行,利用这个特点,还能写出更快一些的代码来。此时正可以体现出GCD写法的好处。用同步块或锁对象,是无法轻易实现出下面这种方案的。这次不用串行队列,而是改用并发队列(concurrent queue):

像现在这样写代码,还无法正确实现同步。所有读取操作与写入操作都会在同一个队列上执行,不过由于是并发队列,所以读取与写入操作可以随时执行。而我们恰恰不想让这些操作随意执行。此问题用一个简单的GCD功能即可解决,它就是栅栏(barrier)。下列函数可以像队列中派发块,将其作为栅栏使用:

在队列中,栅栏块必须单独执行,不能与其他块并行。这只对并发队列有意义,因为串行队列的块总是按顺序逐个来执行的。并发队列如果发现接下来要处理的块是个栅栏块(barrier block),那么久一直要等当前所有并发块都执行完毕,才会单独执行这个栅栏块。待栅栏块执行过后,再按正常方式继续向下处理。
在本例中,可以用栅栏块来实现属性的设置方法。在设置方法中使用了栅栏块之后,对属性的读取操作依然可以并发执行,但是写入操作却必须单独执行了。实现代码很简单:

在这个并发队列中,读取操作是用普通块来实现的,而写入操作则是用栅栏块来实现的。读取操作可以并行,但写入操作必须单独执行,因为它是栅栏块。测试下性能,你会发现,这种做法肯定比使用串行队列要块。注意,设置函数页可以改用同步的栅栏块(synchronous barrier)来实现,那样做可能会更加高效,其原因刚才已经解释过了。最好还是测一测每种做法的性能,然后从中选出最合适当前场景的方案。

屏幕快照 2015-10-08 下午3.21.27

 

 

 

 

 

 

 

 

 

Tips:
1.派发队列可用来表述同步语义(synchronization semantic),这种做法要比使用@synchronized块或NSLock对象更简单。
2.将同步与异步派发结合起来,可以实现与普通加锁机制一样的同步行为,而这么做却不会阻塞执行异步派发的线程。
3.使用同步队列及栅栏块,可以令同步行为更加高效。



发表评论

电子邮件地址不会被公开。 必填项已用*标注