背景：在多线程中，如果同时抢一块资源，比如给数组追加数据，可变数组（字典）不是线程安全的，就会导致crash，为了避免这种问题，就衍生出线程同步，来保证线程安全。

先介绍几种锁，

第一种锁

@synchronized（互斥锁）

NSObject *obj = [[NSObject alloc] init];

dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{

      @synchronized(obj) {

             NSLog(@"需要线程同步的操作1 开始");

             sleep(3);

             NSLog(@"需要线程同步的操作1 结束");

      }

});

dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{

           sleep(1);

           @synchronized(obj) {

                  NSLog(@"需要线程同步的操作2");

         }

});

1.@synchronized(obj)指令使用的obj为该锁的唯一标识，@synchronized(obj)指令使用的obj为该锁的唯一标识，只有当标识相同时，才为满足互斥，如果线程2中的@synchronized(obj)改为@synchronized(self),刚线程2就不会被阻塞，@synchronized块会隐式的添加一个异常处理例程来保护代码，该处理例程会在异常抛出的时候自动的释放互斥锁。

2.synchronized 优劣分析：

劣势：@synchronized块会隐式的添加一个异常处理例程来保护代码，该处理例程会在异常抛出的时候自动的释放互斥锁。开销大，性能差，不适合在生成环境使用。

优点：使用@synchronized关键字可以很方便地创建锁对象，而且不用显式的创建锁对象。

3.synchronized 内部的锁是一个递归锁。

4.atomic：原子属性，为setter方法加锁，的内部实现就是synchronized。

第二种锁

NSLock（性质：互斥锁）

容易造成死锁，比如：

//主线程中

NSLock *theLock = [[NSLock alloc] init];

TestObj *obj = [[TestObj alloc] init];

//线程1

dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{

        static void(^TestMethod)(int);

        TestMethod = ^(int value){

               [theLock lock];

               if (value > 0){

                      [obj method1];

                     sleep(5); //后面写上[theLock unlock];而不是放在最后，就加锁，解锁就一一对应了，

                    TestMethod(value-1);

             }

        [theLock unlock];

      };

        TestMethod(5);

});

//线程2

dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{

         sleep(1);

        [theLock lock];

         [obj method2];

        [theLock unlock];

});

//简单分析：这段代码是一个典型的死锁情况。在我们的线程中1是递归调用的。所以每次进入这个block时，都会去加一次锁，而从第二次开始，由于锁已经被使用了且没有解锁，所以它需要等待锁被解除，这样就导致了死锁，

//调试器有这些提示：[NSLock lock]: deadlock

//如果在在递归或循环中正确的使用锁:

NSRecursiveLock 递归锁，直接NSLock *theLock = [[NSLock alloc] init];

替换成NSRecursiveLock *lock = [[NSRecursiveLock alloc] init];就ok了

第三种锁

NSConditionLock条件锁

特殊场景使用，也就是满足一定的条件下，才解锁，和创建锁。

第四种方式，用信号量来实现锁的功能

信号量 ==>当信号个数为 0 时，则线程阻塞，等待发送新信号；一旦信号个数大于 0 时，就开始处理任务。

dispatch_semaphore_create、

dispatch_semaphore_wait  //在执行完这行代码后，信号量就会减一，如果信号量变成了0，那么就在这里等着，后面一般就是一些排他操作（比如：数组的写操作，保证同步）

dispatch_semaphore_signal、 //作用：在排他操作结束后，现在就可以让其他线程来玩了，执行完这行代码，信号量加1，之前其他等待的线程就又开始工作了。

dispatch_semaphore_t signal = dispatch_semaphore_create(1);

dispatch_time_t overTime = dispatch_time(DISPATCH_TIME_NOW, 3 * NSEC_PER_SEC);

dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{

         dispatch_semaphore_wait(signal, overTime);

         NSLog(@"需要线程同步的操作1 开始");

          sleep(2); //数组写操作

          NSLog(@"需要线程同步的操作1 结束");

         dispatch_semaphore_signal(signal);

});

dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{

          sleep(1);

         dispatch_semaphore_wait(signal, overTime);

          NSLog(@"需要线程同步的操作2");

          dispatch_semaphore_signal(signal);

});

//结果就是：

2016-06-29 20:47:52.324 SafeMultiThread[35945:579032] 需要线程同步的操作1 开始

2016-06-29 20:47:55.325 SafeMultiThread[35945:579032] 需要线程同步的操作1 结束

2016-06-29 20:47:55.326 SafeMultiThread[35945:579033] 需要线程同步的操作2

//这里设置的 dispatch_semaphore_wait(signal, overTime);有个超时时间，一般可以写作DISPATCH_TIME_FOREVER，永不超时。

//这里overtime 如果改成1*NSEC_PER_SEC，那么wait就不等了，就向后走了，

2016-06-30 18:53:24.049 SafeMultiThread[30834:434334] 需要线程同步的操作1 开始

2016-06-30 18:53:25.554 SafeMultiThread[30834:434332] 需要线程同步的操作2

2016-06-30 18:53:26.054 SafeMultiThread[30834:434334] 需要线程同步的操作1 结束

简单总结一下：

互斥锁特点：如果共享数据已经有其他线程加锁了，线程会进入休眠状态等待锁。一旦被访问的资源被解锁，则等待资源的线程会被唤醒。

自旋锁：如果共享数据已经有其他线程加锁了，线程会以死循环的方式等待锁，一旦被访问的资源被解锁，则等待资源的线程会立即执行。性能最高的锁，OSSpinLock已经不再安全，不再使用。

信号量：一个线程完成了操作完共享数据后，就通过发出信号量告诉别的线程，你们现在可以用这块共享资源了。

性能比较：OSSpinLock > dispatch_semaphore > NSLock > NSRecursiveLock > NSConditionLock > @synchronized.

生产环境一般推荐使用dispatch_semaphore。

上述都是解决同一时刻，只允许一个线程访问某个特定资源的问题，不管是是互斥锁还是信号量，都没法解决另外一个问题：锁定的共享资源会引起读写问题，大多数情况下，限制资源一次只能有一个线程进行读取访问其实是非常浪费的。所以就引出了GCD 的barrier来解决这个问题（资源饥饿）。

GCD barrier 解决资源饥饿 问题

dispatch_barrier使用前提：一定要在一个队列里面（自定义并行队列）。

不能用global queue,因为这个全局队列，每次系统分配可能在不同的队列里面，比如你的barrier在队列A里面，流程走到这，执行自己barrier任务，没用，后面的任务在其他队列做了，不等barrier任务，所以barrier根本不起效果。

剩下就是自定义一个队列，分串行队列，和并行队列，如果是串行队列，就不用了barrier了，他本身就是按照顺序来执行的，加barrier拦截没有意义，所以只能用自定义队列的并行方式。

concurrentQueue =dispatch_queue_create("www.test.com", DISPATCH_QUEUE_CONCURRENT);

- (NSString *)someString{

       __weak NSString *localSomeString; //1

       dispatch_sync(concurrentQueue, ^{

              localSomeString = _someString; //2

        });

      return localSomeString; //3

}

- (void)setSomeString:(NSString *)someString{

       // barrier

       dispatch_barrier_async(concurrentQueue, ^{

             _someString = someString;

       });

}

//当使用并发队列时，要确保所有的 barrier 调用都是 async 的,如果你使用 dispatch_barrier_sync ，那么你很可能会使你自己（更确切的说是，你的代码）产生死锁。

分析：写操作 ，只能用barrier，保证多线程写的安全，读取操作，可以是并行，

dispatch_sync(concurrentQueue, ^{localSomeString = _someString;});

return localSomeString;

这个操作是把block内容放到并行队列里面，这里用dispatch_sync原因就是后面还需要    return localSomeString;也就是必须让他等着，不能block里面赋值还没做，就直接返回了，所以要用dispatch_sync，流程就成了，下面的1，2，3符合逻辑。这里虽然是同步执行，但是任务是放在并行队列里面的，所以任务还是并行执行的。当然，如果这里不是读取操作，是其他操作，不需要后面的返回值，就可以用dispatch_async,异步执行，所以需要看你具体做的事情。

其他：

并行： 自定义并行队列  、 全局队列  ==>放在里面的任务block ，是可以同步执行的

串行： 自定义串行队列  、  主线程  ==> 放在里面的任务block，是一个挨着一个，按照顺序来执行的。

同步：dispatch_sync   ==>  就在当前线程做事情

异步：dispatch_async  ==>  会开一个新线程 做事情