【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;
    });
}
阅读更多

没有更多推荐了,返回首页