【iOS】【笔记】使用GCD实现同步锁

这是阅读了 Effective Objective-C的第41条的总结

在iOS开发中会遇到多个线程要执行同一份代码的情况，比如同时修改统一个数据（火车卖票），通俗一点说就是抢占资源的问题。
通常要使用加锁来实现这种同步机制，在GCD出现之前，一共有两种方法。

1、同步块（synchroization block）

 -(void)sunchronizedMethod{
  @synchronized(self) {
      //安全代码
  }
}

这样写会自动创建一个锁，等块中代码都执行完毕，执行到这段代码结尾，锁就释放了。这样写通常没错，因为它可以保证每个self持有的对象都能不受干扰的运行其sunchronizedMethod方法，然而，滥用@synchronized(self)会降低代码效率，因为共用同一个锁的那些同步块（synchroization block），都必须按顺序执行，若是在self对象上频繁加锁，那么程序可能要等另一段与此无关的代码执行完毕，才能继续执行当前代码，其实没有这样做的必要。

2、NSLock

_lock = [NSLock alloc]init];

-(void)sunchronizedMethod{
    [_lock lock];
    //安全代码
    [_lock unlock];
}

这两种方法都很好，不过也有缺陷，比方说，在极端的情况下，同步块（synchroization block）会导致死锁，另外，其效率也不见得很高，而如果用NSLock的话，一旦遇到死锁，就会非常麻烦。
最好的方案就是使用GCD，它能简单高效的方式给代码加锁。下面通过get和set方法来举例说明：当我们操作一个对象的时候，假设将属性设为atomic，那么实现的效果类似于以下代码：

-(NSString *)someString{
   @synchronized(self){
        return _someString;
    }
}

-(void)setSomeString:(NSString *)someString{
    @synchronized(self){
        _someString = someString;
    }
}

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

  //NULL相当于DISPATCH_QUEUE_SERIAL
_syncQueue = dispatch_queue_create("www.nnn.com", NULL);

-(NSString *)someString{
    __block NSString *str;
     dispatch_sync(_syncQueue, ^{
        str = _someString;
    });
    return str;
}

-(void)setSomeString:(NSString *)someString{
    dispatch_sync(_syncQueue, ^{
        _someString = someString;
    });
}

这种实现的思路是：把set操作与get操作都安排到序列化的队列里执行，这样的话，所有针对属性的访问操作就同步了。全部加锁任务都在GCD重处理，而GCD是在相当深的底层来实现的，于是能够做许多优化，因此开发者无须担心那些事，只要专心把访问方法写好就行。
然而还可以进一步优化，set方法不一定非得是同步的。设置实例变量所用的方法，并不需要返回什么值，也就是实说，可以改成下面那样：

-(void)setSomeString:(NSString *)someString{
        dispatch_async(_syncQueue, ^{
        _someString = someString;
    });
 }

这次只是把同步派发改成了异步派发，从调用者的角度来看，这个小改动可以提升set方法的执行速度，而get方法依然会按照顺序执行。但这么做有个坏处，有可能程序会比较慢，因为执行异步派发的时候，需要拷贝块，若拷贝块所用的时间明显超过执行块所花的时间，则这种做法比原来更慢。然而，若是派发给队列的块需要执行更为繁重的任务，那么仍然可以考虑这种方案。
多个获取方法可以并发执行，而set方法和get方法之间不能并发执行，利用这个特点，还能写出更快的代码来，我们这次改用并发队列：

_syncQueue = dispatch_queue_create("www.nnn.com", DISPATCH_QUEUE_CONCURRENT);

-(NSString *)someString{
    __block NSString *str;
     dispatch_sync(_syncQueue, ^{
        str = _someString;
    });
    return str;
}

-(void)setSomeString:(NSString *)someString{
    dispatch_sync(_syncQueue, ^{
        _someString = someString;
    });
}

像这样写代码，还无法实现同步。所有get操作和set操作都会在同一个队列上执行，不过由于是并发队列，所以set和get操作可以随时执行，而这是我们恰恰不想看到的。此问题用一个简单的GCD功能就能解决，他就是栅栏（barrier）。下面的函数可以向队列中派发块，将其作为栅栏（barrier）使用：

 void dispatch_barrier_sync(dispatch_queue_t queue, dispatch_block_t block);
 void dispatch_barrier_async(dispatch_queue_t queue, dispatch_block_t block);

在队列中，栅栏块必须单独执行，不能与其他块并行。这只对并发队列有意义，因为串行本来就是顺序逐个执行的。并发队列如果发现接下来要处理的块是个栅栏块（barrier block）,那么久一直要等到当前所有并发块都执行完毕，才会单独执行这个栅栏块，待栅栏块执行过后，再按正常方式继续乡下处理。这也就是说，当我们进行set的时候，这个块是单独执行的，这样就不会出现多个线程同时写入数据的情况。
代码如下：

_syncQueue = dispatch_queue_create("www.nnn.com", DISPATCH_QUEUE_CONCURRENT);

-(NSString *)someString{
    __block NSString *str;
     dispatch_sync(_syncQueue, ^{
        str = _someString;
    });
    return str;
}

-(void)setSomeString:(NSString *)someString{
    dispatch_barrier_async(_syncQueue, ^{
        _someString = someString;
    });
}