oc中实现线程同步的手段

当多线程访问共享资源的时候，会出现资源竞争的情况，导致数据错乱的问题，OC中要想实现线程间的同步的话，有以下手段：

一、锁

锁就是实现多线程同步的其中一种方案，查看示例程序，

总数是15程序执行完成应该是0,然而并不是,现在要做的就是让多线程对共享资源这里是

1
2
3
4
5
int preCount = self.totalCount;
sleep(0.2);
self.totalCount = --preCount ;

NSLog(@"---now value : %d---%@",self.totalCount,[NSThread currentThread]);

能够顺序执行。

1.1、自旋锁

所谓的自旋锁，形如以下形式

1
2
3
while( 抢锁 == 没抢到 ) {

}

只要没有抢到锁，程序就会一直重试，所以会一直占用CPU资源。

1.1.1 OSSpinLockLock

跟踪下OSSpinLockLock的汇编代码内部确实是一个while循环，循环部分的代码如下

1
2
3
4
5
6
7
8
9
10
11
12
13
0x104ba98b1 <+12>: cmpl   $-0x1, %eax
0x104ba98b4 <+15>: jne    0x104ba98d1               ; <+44>
0x104ba98b6 <+17>: testl  %ecx, %ecx
0x104ba98b8 <+19>: je     0x104bab0f9               ; _OSSpinLockLockYield
0x104ba98be <+25>: pause
0x104ba98c0 <+27>: incl   %ecx
0x104ba98c2 <+29>: movl   (%rdi), %eax
0x104ba98c4 <+31>: testl  %eax, %eax
0x104ba98c6 <+33>: jne    0x104ba98b1               ; <+12>
0x104ba98c8 <+35>: xorl   %eax, %eax
0x104ba98ca <+37>: lock
0x104ba98cb <+38>: cmpxchgl %edx, (%rdi)
0x104ba98ce <+41>: jne    0x104ba98b1               ; <+12>

OSSpinLockLock特点：

  1. 效率高，因为一直占用着cpu，其实这个是优点也是缺点
  2. 会出现优先级反转（对于优先级不同的线程，使用同一把锁访问共同资源，优先级低的线程先拿到锁，这时优先级高的线程过来后，由于锁被占用，但是优先级高，一直占有CPU资源，导致持有锁的低优先级的线程无法执行释放锁的操作，从而优先级高的线程一直处于忙等的状态）的问题；
  3. 无法处理递归。

OSSpinLockLock使用见demo

1.2、互斥锁

由于自旋锁一直占用着cpu资源

1
2
3
while( 抢锁 == 没抢到 ) {

}

其实不需要一直循环等待，只要当检测到锁被占用了，那么就去睡觉，当锁的状态改变了，通知它就行了，这就是互斥锁。

1
2
3
while (抢锁 == 没抢到) {
    当前线程先去睡觉，当锁的状态改变了，再唤醒;
}

1.2.1 os_unfair_lock

由于OSSpinLockLock存在优先级反转的问题，os_unfair_lock是苹果用来替代OSSpinLockLock的。跟踪了汇编代码，等待的汇编代码如下

跟踪路径：os_unfair_lock_lock -> _os_unfair_lock_lock_slow -> __ulock_wait

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

libsystem_kernel.dylib`__ulock_wait:
0x10701f360 <+0>:  movl   $0x2000203, %eax          ; imm = 0x2000203
0x10701f365 <+5>:  movq   %rcx, %r10

0x10701f368 <+8>:  syscall

0x10701f36a <+10>: jae    0x10701f374               ; <+20>
0x10701f36c <+12>: movq   %rax, %rdi
0x10701f36f <+15>: jmp    0x10701ce67               ; cerror_nocancel
0x10701f374 <+20>: retq
0x10701f375 <+21>: nop
0x10701f376 <+22>: nop
0x10701f377 <+23>: nop

一旦执行到syscall时，该条线程就去睡觉了。

os_unfair_lock特点：

  1. 没有优先级反转的问题；
  2. 由于线程睡觉，当然唤醒也是要时间的，效率没有自旋锁高；
  3. iOS10.0以上才可用;
  4. 也不能处理递归的场景。

os_unfair_lock使用见demo

1.2.2 pthread_mutex_t

这个是一个比较底层的api，在C和C++都可以使用，这个对于没有抢到的资源也是睡觉，所以是互斥锁，通过断点可以查看休眠的代码

1
2
3
4
5
6
7
8
9
10
libsystem_kernel.dylib`__psynch_mutexwait:
0x10c5f1868 <+0>:  movl   $0x200012d, %eax          ; imm = 0x200012D
0x10c5f186d <+5>:  movq   %rcx, %r10

0x10c5f1870 <+8>:  syscall // 也是调用的这个系统调用，线程处于休眠状态

0x10c5f1872 <+10>: jae    0x10c5f187c               ; <+20>
0x10c5f1874 <+12>: movq   %rax, %rdi
0x10c5f1877 <+15>: jmp    0x10c5eee67               ; cerror_nocancel
0x10c5f187c <+20>

找到该代码的路径为pthread_mutex_lock -> pthread_mutex_firstfit_lock_slow -> _pthread_mutex_firstfit_lock_wait -> __psynch_mutexwait

  1. 普通锁用法demo或者demo
  2. 递归锁用法:
    1. 演示没有递归锁程序的bug;
    2. 使用递归锁解决bug,demo
  3. 条件锁用法demo

pthread_mutex_t特点：

  1. 没有优先级反转的问题；
  2. 由于线程睡觉，当然唤醒也是要时间的，效率没有自旋锁高；
  3. 可以处理递归场景；
  4. 可以增加条件锁。

1.2.3 NS—LOCK

下面介绍Foundation框架下的lock类，其实NSLock就是对pthread_mutex_t的一个上层封装，使其更加面向对象:

  1. NSLock是对上面提到的pthread_mutex_t普通锁用法的封装
  2. NSCondition和NSConditionLock是对上面提到的pthread_mutex_t条件锁用法的封装
  3. NSRecursiveLock是对上面提到的pthread_mutex_t递归锁用法的封装。

2中方案验证下观点：

  1. 参考GNUStep的源码，地址找到Foundation代码；
  2. 通过hopper工具查看/System/Library/Frameworks/Foundation.framework

gnu不是苹果源码，但是有很大的参考价值，截取部分代码如下

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
37
@implementation NSLock

+ (void) initialize
{
  static BOOL	beenHere = NO;

  if (beenHere == NO)
    {
      beenHere = YES;

      pthread_mutexattr_init(&attr_normal);
      pthread_mutexattr_settype(&attr_normal, PTHREAD_MUTEX_NORMAL);
      pthread_mutexattr_init(&attr_reporting);
      pthread_mutexattr_settype(&attr_reporting, PTHREAD_MUTEX_ERRORCHECK);
      pthread_mutexattr_init(&attr_recursive);
      pthread_mutexattr_settype(&attr_recursive, PTHREAD_MUTEX_RECURSIVE);

      
      pthread_mutex_init(&deadlock, &attr_normal);
      pthread_mutex_lock(&deadlock);

      baseConditionClass = [NSCondition class];
      baseConditionLockClass = [NSConditionLock class];
      baseLockClass = [NSLock class];
      baseRecursiveLockClass = [NSRecursiveLock class];

      tracedConditionClass = [GSTracedCondition class];
      tracedConditionLockClass = [GSTracedConditionLock class];
      tracedLockClass = [GSTracedLock class];
      tracedRecursiveLockClass = [GSTracedRecursiveLock class];

      untracedConditionClass = [GSUntracedCondition class];
      untracedConditionLockClass = [GSUntracedConditionLock class];
      untracedLockClass = [GSUntracedLock class];
      untracedRecursiveLockClass = [GSUntracedRecursiveLock class];
    }
}

再通过hopper工具最后确认下

分别看下init和lock和unlock

1.2.3.1 NSLock

15465046593957.jpg

15465046780683.jpg

15465046919800.jpg

使用的demo地址

1.2.3.2 NSCondition

15465047250284.jpg

15465047399306.jpg

15465047553345.jpg

使用的demo地址

1.2.3.3 NSConditionLock

这个是对NSCondition的封装，扩展了功能而已

15465048157582.jpg

主要是lockWhenCondition和unlockWithCondition，看下GNU的代码

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
- (void) lockWhenCondition: (NSInteger)value
{
  [_condition lock];
  while (value != _condition_value)
    {
      [_condition wait];
    }
}

- (void) unlockWithCondition: (NSInteger)value
{
  _condition_value = value;
  [_condition broadcast];
  [_condition unlock];
}

有了源码就很好理解了。

使用的demo地址

1.2.3.4 NSRecursiveLock

15465048348121.jpg

15465048480822.jpg

15465048587863.jpg

使用的demo地址

通过逆向验证了我们的观点，所以不用测试论速度的话肯定不如pthread_mutex_t，毕竟objc_msgSend也是要时间的。

1.2.4 Synchronized

使用方式很简单

1
2
3
4
5
- (void)reduceCount {
    @synchronized (self) {
        [super reduceCount];
    }
}

通过汇编代码看下synchronized多线程等待的实现，代码修改见提交，断点在此处，拦截第二次断点，注意是第二次。

15465721424857.jpg

objc_sync_enter -> os_unfair_recursive_lock_lock_with_options -> _os_unfair_lock_lock_slow -> __ulock_wait 

1
2
3
4
5
6
7
8
9
10
11
libsystem_kernel.dylib`__ulock_wait:
->  0x10f124360 <+0>:  movl   $0x2000203, %eax          ; imm = 0x2000203 
    0x10f124365 <+5>:  movq   %rcx, %r10
    0x10f124368 <+8>:  syscall 
    0x10f12436a <+10>: jae    0x10f124374               ; <+20>
    0x10f12436c <+12>: movq   %rax, %rdi
    0x10f12436f <+15>: jmp    0x10f121e67               ; cerror_nocancel
    0x10f124374 <+20>: retq   
    0x10f124375 <+21>: nop    
    0x10f124376 <+22>: nop    
    0x10f124377 <+23>: nop

发现到最后也是调用了syscall，从_os_unfair_lock_lock_slow开始和上面的os_unfair_lock一样。

Synchronized的源码是开源的在objc的objc-sync.mm文件中

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
int objc_sync_enter(id obj)
{
    int result = OBJC_SYNC_SUCCESS;

    if (obj) {
        SyncData* data = id2data(obj, ACQUIRE);
        assert(data);
        data->mutex.lock();
    } else {
        // @synchronized(nil) does nothing
        if (DebugNilSync) {
            _objc_inform("NIL SYNC DEBUG: @synchronized(nil); set a breakpoint on objc_sync_nil to debug");
        }
        objc_sync_nil();
    }

    return result;
}

本质是对os_unfair_lock的一个封装

1
2
3
4
typedef struct os_unfair_recursive_lock_s {
	os_unfair_lock ourl_lock;
	uint32_t ourl_count;
} os_unfair_recursive_lock, *os_unfair_recursive_lock_t;

特点如下：

  1. 没有优先级反转的问题；
  2. 由于线程睡觉，当然唤醒也是要时间的，效率没有自旋锁高；
  3. 可以处理递归场景；
  4. synchronized的内部维护了一个map表，性能稍微其他的差些。

二、串行队列

我们要实现线程同步的根本原因是当多线程访问统一共享资源的时候会出现数据错乱的问题，那么只要能够保证多线程执行共享资源任务的时候能够顺序执行就可以了，那么串行队列也是一种方案。使用也很简单

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

- (instancetype)init {
    if (self = [super init]) {
        self.queue = dispatch_queue_create("test", DISPATCH_QUEUE_SERIAL);
    }
    return self;
}

- (void)reduceCount {
    
    dispatch_sync(self.queue, ^{
        [super reduceCount];
    });
    
}

三、信号量

使用如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
- (instancetype)init {
    if (self= [super init]) {
    
        self.semaphore = dispatch_semaphore_create(1);
    }
    
    return self;
}

- (void)reduceCount {
    dispatch_semaphore_wait(self.semaphore, DISPATCH_TIME_FOREVER);
    [super reduceCount];
    dispatch_semaphore_signal(self.semaphore);
}
  1. 通过dispatch_semaphore_create定好信号量的数量；
  2. dispatch_semaphore_wait调用则self.semaphore会减1，如果减1以后<=0 ，那么就会等待，知道>0；
  3. dispatch_semaphore_signal会将self.semaphore加1。

四、性能对比

关乎各种方案的性能对比yykit的作者做了个代码比较，地址

性能从高到低排序：

  1. os_unfair_lock
  2. OSSpinLock
  3. dispatch_semaphore
  4. pthread_mutex
  5. dispatch_queue(DISPATCH_QUEUE_SERIAL)
  6. NSLock
  7. NSCondition
  8. pthread_mutex(recursive)
  9. NSRecursiveLock
  10. NSConditionLock
  11. @synchronized

其实，不通过代码测试也能猜出个大概了：

  1. 自旋锁高于互斥锁
  2. 越接近底层的api肯定是更快的，所以c和GCD的会快于oc（上层封装）的；

五、推荐

开发中如果对性能要求比较高的话比较常见的选择：

  1. 常规锁的话，推荐使用dispatch_semaphore和pthread_mutex；
  2. 递归锁的话，推荐使用pthread_mutex(recursive)和NSRecursiveLock（rac中用的是这个）

说明 本文的完整demo地址。

赏

谢谢你请我吃糖果

微信
访问量次

tag:

    缺失模块。
    1、请确保node版本大于6.2
    2、在博客根目录（注意不是yilia根目录）执行以下命令：
    npm i hexo-generator-json-content --save

    3、在根目录_config.yml里添加配置： 

      jsonContent:
    meta: false
    pages: false
    posts:
      title: true
      date: true
      path: true
      text: false
      raw: false
      content: false
      slug: false
      updated: false
      comments: false
      link: false
      permalink: false
      excerpt: false
      categories: false
      tags: true

FangLaoDa ，<br>Coder</br> <br> 目前就职于点融网 </br>