深入理解iOS各种锁

2017-09-29

字数统计: 5.5k字 | 阅读时长: 24min

🔐顾名思义。。锁上了表示就进不来，解锁后你才可以进来。。在开发中也是如此，在多线程开发中，就经常会使用到锁机制。锁是一种同步机制，用于在多线程的环境中对资源的访问限制，防止多个线程在同一时间操作资源.

不同的锁的性能与实现也是不一样的，我们就来研究下在iOS中的几种不同的锁~~

我们先来看下这个图

这个是Y神在对锁的性能测试后得到的一个结论, 暂且不讨论性能，我们按从上到下来看下这些锁都是怎么样实现的。

OSSpinLock（自旋锁）

SpinLock又称自旋锁,线程通过busy-wait-loop的方式来获取锁，任时刻只有一个线程能够获得锁，其他线程忙等直到获得锁。其实现是通过标志位、 test_and_set指令执行原子性和while循坏对资源进行锁操作

缺点：

对于互斥锁，如果资源已经被占用，资源申请者只能进入睡眠状态。但是自旋锁不会引起调用者睡眠，如果自旋锁已经被别的执行单元保持，调用者就一直循环(也就是忙等)在那里看是否该自旋锁的保持者已经释放了锁，这也就是自旋锁比互斥锁性能好的原因. 但是假设是时间较长的I/O操作，就会占用大量的CPU时间,从而使锁的效率降低，所以自旋锁比较适用锁使用者保持锁时间比较短的情况.
自旋锁不支持递归，如果递归调用的话会造成死锁. 所以递归程序决不能在持有自旋锁时调用它自己，也决不能在递归调用时试图获得相同的自旋锁

自旋锁使用起来比较简单：

OSSpinLock oslock = OS_SPINLOCK_INIT;
OSSpinLockLock(&oslock);
// do somthing
OSSpinLockUnlock(&oslock);

但是自旋锁是有一个比较严重的bug，假设一个低优先级的线程获得了锁并访问了资源，这时一个高优先级的线程也尝试获得这个锁，此时它会处于busy-wait忙等状态从而占用大量 CPU 时间，此时低优先级线程无法与高优先级线程争夺 CPU 时间，从而导致任务不能完成无法释放 lock, 直到超时被操作系统抢占. 这就造成了优先级的反转.

Dispatch_semaphore (信号量)

在libdispatch源码中，我们可以在semaphore.h文件发现其提供的API也是十分的简单，只有三个函数

1
2
3

dispatch_semaphore_t dispatch_semaphore_create(long value);  // 创建一个信号
long dispatch_semaphore_wait(dispatch_semaphore_t dsema, dispatch_time_t timeout);    // 等待信号
long dispatch_semaphore_signal(dispatch_semaphore_t dsema);  // 发送信号

dispatch_semaphore_signal发送一个信号，会让信号总量加1,dispatch_semaphore_wait用于等待信号，让信号总量减1，当信号总量少于0的时候就会一直等待，否则就可以正常的执行，根据这样的原理，我们便可以快速的创建一个并发控制来同步任务和有限资源访问控制

long dispatch_semaphore_wait(dispatch_semaphore_t dsema, dispatch_time_t timeout) {
	
	if (dispatch_atomic_dec(&dsema->dsema_value) >= 0) {
		return 0;
	}
	return _dispatch_semaphore_wait_slow(dsema, timeout);
}

去掉了中间的在不同架构下的优化部分，基本上就是这样

#define dispatch_atomic_dec(p) __sync_sub_and_fetch((p), 1) 这个宏调用的是__sync_sub_and_fetch, 这是个GCC的内置函数，它实现了减法的原子性操作, 将dsema_value 的值减一，并把新的值赋给dsema_value ,如果信号量的值减1之后大于等于0，表示有资源可用，那么直接返回0, 否则将会都到_dispatch_semaphore_wait_slow 函数

static long _dispatch_semaphore_wait_slow(dispatch_semaphore_t dsema, dispatch_time_t timeout) {
	mach_timespec_t _timeout;
	kern_return_t kr;
	uint64_t nsec;
	long orig;
	
again:
	// Mach semaphores appear to sometimes spuriously wake up.  Therefore,
	// we keep a parallel count of the number of times a Mach semaphore is
	// signaled.
	while ((orig = dsema->dsema_sent_ksignals)) {
		if (dispatch_atomic_cmpxchg(&dsema->dsema_sent_ksignals, orig, orig - 1)) {
			return 0;
		}
	}

	_dispatch_semaphore_create_port(&dsema->dsema_port);

	// From xnu/osfmk/kern/sync_sema.c:
	// wait_semaphore->count = -1;  /* we don't keep an actual count */
	//
	// The code above does not match the documentation, and that fact is
	// not surprising. The documented semantics are clumsy to use in any
	// practical way. The above hack effectively tricks the rest of the
	// Mach semaphore logic to behave like the libdispatch algorithm.

	switch (timeout) {
	default:
		do {
			// timeout() already calculates relative time left
			nsec = _dispatch_timeout(timeout);
			_timeout.tv_sec = (typeof(_timeout.tv_sec))(nsec / NSEC_PER_SEC);
			_timeout.tv_nsec = (typeof(_timeout.tv_nsec))(nsec % NSEC_PER_SEC);
			kr = slowpath(semaphore_timedwait(dsema->dsema_port, _timeout));
		} while (kr == KERN_ABORTED);

		if (kr != KERN_OPERATION_TIMED_OUT) {
			DISPATCH_SEMAPHORE_VERIFY_KR(kr);
			break;
		}
		// Fall through and try to undo what the fast path did to dsema->dsema_value
	case DISPATCH_TIME_NOW:
		while ((orig = dsema->dsema_value) < 0) {
			if (dispatch_atomic_cmpxchg(&dsema->dsema_value, orig, orig + 1)) {
				return KERN_OPERATION_TIMED_OUT;
			}
		}
		// Another thread called semaphore_signal().
		// Fall through and drain the wakeup.
	case DISPATCH_TIME_FOREVER:
		do {
			kr = semaphore_wait(dsema->dsema_port);
		} while (kr == KERN_ABORTED);
		DISPATCH_SEMAPHORE_VERIFY_KR(kr);
		break;
	}
	goto again;
}

进入这个方法，timeout有三种case：

DISPATCH _TIME _NOW: 不等待, 如果dsema_value小于0，那么将其+1, 然后返回KERN_OPERATION_TIMED_OUT；如果大于等于0，表示有资源可用，那么将会进入到again;
DISPATCH _TIME _FOREVER: 无线等待, semaphore_wait将无限等待到信号值等于于KERN_ABORTED ;
等信号来了，跳转到again;
Default: 计时等待, semaphore_timedwait(dsema->dsema_port, _timeout)直到timeout或者KERN_ABORTED为止

long dispatch_semaphore_signal(dispatch_semaphore_t dsema) {
	if (dispatch_atomic_inc(&dsema->dsema_value) > 0) {
		return 0;
	}
	return _dispatch_semaphore_signal_slow(dsema);
}

发送信号与等待信号的函数差不多, dispatch_atomic_inc, #define dispatch_atomic_inc(p) __sync_add_and_fetch((p), 1) 这也是一个GCC内置函数, 若信号值加1后大于零，表示有资源可用，那么直接返回0, 否则将会走到_dispatch_semaphore_signal_slow 中

static long _dispatch_semaphore_signal_slow(dispatch_semaphore_t dsema) {
	kern_return_t kr;
	
	_dispatch_semaphore_create_port(&dsema->dsema_port);

	// Before dsema_sent_ksignals is incremented we can rely on the reference
	// held by the waiter. However, once this value is incremented the waiter
	// may return between the atomic increment and the semaphore_signal(),
	// therefore an explicit reference must be held in order to safely access
	// dsema after the atomic increment.
	_dispatch_retain(dsema);
	
	dispatch_atomic_inc(&dsema->dsema_sent_ksignals);
	
	kr = semaphore_signal(dsema->dsema_port);
	DISPATCH_SEMAPHORE_VERIFY_KR(kr);

	_dispatch_release(dsema);
	
	return 1;
}

如果信号量之前的值小于0，那么信号量加1；其核心是:semaphore_signal(dsema->dsema_port) 利用系统的信号量库实现发送信号量的功能，最后返回1, 表示其当前有（一个或多个）线程等待其处理的信号量，并且该函数唤醒了一个等待的线程(当线程有优先级时，唤醒优先级最高的线程；否则随机唤醒).

信号量使用起来也是比较简单的:

1
2
3

dispatch_semaphore_t semaphore = dispatch_semaphore_create(0);   
dispatch_semaphore_signal(semaphore);   
dispatch_group_wait(semaphore, DISPATCH_TIME_FOREVER);

pthread_mutex

pthread 表示 POSIX标准的线程库，该标准定义了创建和操纵线程的一整套API, pthread_mutex 表示的是互斥锁

POSIX下抽象了一个锁类型的结构：ptread _mutex _t 我们可以看下在iOS中，是怎么定义的。

typedef __darwin_pthread_mutex_t pthread_mutex_t;

typedef struct _opaque_pthread_mutex_t __darwin_pthread_mutex_t;

struct _opaque_pthread_mutex_t {
	long __sig;
	char __opaque[__PTHREAD_MUTEX_SIZE__];
};

ptread _mutex _t其实就是一个_opaque_pthread_mutex_t 结构体, 其原理与信号量类似,不使用忙等，而是阻塞线程并睡眠，需要进行上下文的切换. PS:一个线程只能申请一次锁，只有在获得锁的情况下才能释放锁，多次申请锁或释放未获得的锁都会导致崩溃.

因为ptread _mutex _t支持多种类型, 在申请加锁时，需要对锁的类型进行判断, 虽然实现跟信号量差不多，但是性能却略低一些.

我们来看下其提供的API

// 创建锁 可以传一个属性为 `pthread_mutexattr_t` 类型的参数
int pthread_mutex_init(pthread_mutex_t * __restrict,const pthread_mutexattr_t * _Nullable __restrict);

// 申请锁
int pthread_mutex_lock(pthread_mutex_t *);

// 释放锁
int pthread_mutex_unlock(pthread_mutex_t *);

//  初始化互斥锁属性对象
int pthread_mutexattr_init(pthread_mutexattr_t *);

// 为所属性对象设置类型
int pthread_mutexattr_settype(pthread_mutexattr_t *, int);

有以下几种类型
/*
 * Mutex type attributes
 */
#define PTHREAD_MUTEX_NORMAL		0       // 普通
#define PTHREAD_MUTEX_ERRORCHECK	1       // errorcheck
#define PTHREAD_MUTEX_RECURSIVE		2   // 递归
#define PTHREAD_MUTEX_DEFAULT		PTHREAD_MUTEX_NORMAL

// 会尝试加锁，如果该互斥锁已经锁定，则返回一个不为0的错误值，如果该互斥锁没有锁定，则返回0，表示尝试加锁成功
int pthread_mutex_trylock(pthread_mutex_t *);

// 销毁锁,销毁成功则会返回0,否则会返回错误码
int pthread_mutex_destroy(pthread_mutex_t *);

来看下使用方法：

pthread_mutexattr_t attr;       // 定义一个锁属性对象
pthread_mutexattr_init(&attr);  // 初始化锁属性对象
pthread_mutexattr_settype(&attr, PTHREAD_MUTEX_NORMAL);  // 为锁设置的属性类型

pthread_mutex_t mutex;   // 定义一个锁对象
pthread_mutex_init(&mutex, &attr) // 创建锁
pthread_mutex_lock(&mutex); // 申请锁  
// do something
pthread_mutex_unlock(&mutex); // 释放锁  
pthread_mutex_destroy(&mutex); // 销毁锁

NSLock

由于GNU的源码是开源的，也跟Cocoa的实现差不多，所以我们打算使用 GNU源码来分析NSLock

我们先来看看NSLock的方法：

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

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

      /* Initialise attributes for the different types of mutex.
       * We do it once, since attributes can be shared between multiple
       * mutexes.
       * If we had a pthread_mutexattr_t instance for each mutex, we would
       * either have to store it as an ivar of our NSLock (or similar), or
       * we would potentially leak instances as we couldn't destroy them
       * when destroying the NSLock.  I don't know if any implementation
       * of pthreads actually allocates memory when you call the
       * pthread_mutexattr_init function, but they are allowed to do so
       * (and deallocate the memory in pthread_mutexattr_destroy).
       */
      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);

      /* To emulate OSX behavior, we need to be able both to detect deadlocks
       * (so we can log them), and also hang the thread when one occurs.
       * the simple way to do that is to set up a locked mutex we can
       * force a deadlock on.
       */
      pthread_mutex_init(&deadlock, &attr_normal);
      pthread_mutex_lock(&deadlock);
    }
}

在NSLock类初始化的时候，初始化了三种属性,attr_normal 、attr_reporting 、attr_recursive ,对应的类型分别是PTHREAD_MUTEX_NORMAL、PTHREAD_MUTEX_ERRORCHECK 、PTHREAD_MUTEX_RECURSIVE ,
当执行NSLock的init方法时：

/* Use an error-checking lock.  This is marginally slower, but lets us throw
 * exceptions when incorrect locking occurs.
 */
- (id) init {
  if (nil != (self = [super init])) {
      if (0 != pthread_mutex_init(&_mutex, &attr_reporting)) {
	  	  DESTROY(self);
	  }
  }
  return self;
}

初始化的是属性为attr_reporting的锁，也就是error-checking锁, 这样性能相比于attr_normal的锁，会稍稍降低，因为它会在发生提示时牺牲一定的性能来换取提示错误信息

它提供了两个方法：


// 内部调用的还是`pthread_mutex`的 `pthread_mutex_trylock `方法, 如果尝试加锁成功则返回YES否则为NO
- (BOOL)tryLock {
    int err = pthread_mutex_trylock(&_mutex);
  	 return (0 == err) ? YES : NO;
}

// 该方法会在所指定 `Date` 之前尝试加锁，会阻塞线程，如果在指定时间之前都不能加锁，则返回 NO，指定时间之前能加锁，则返回 YES
- (BOOL)lockBeforeDate:(NSDate *)limit {
  do {
      int err = pthread_mutex_trylock(&_mutex);
      if (0 == err) {
		  return YES;
		}
      if (EDEADLK == err) {
		  _NSLockError(self, _cmd, NO)\3
	   }
      sched_yield();
      
    } while ([limit timeIntervalSinceNow] > 0);
  return NO;
}

sched_yield 函数可以使用另一个级别等于或高于当前线程的线程先运行.如果没有符合条件的线程，那么这个函数将会立刻返回然后继续执行当前线程的程序.

NSLcok使用起来也是比较简单的，因为遵循了<NSLocking>协议，协议中仅有两个方法，- (void)lock;``- (void)unlock; 所以NSLock对象可以直接调用这俩个方法

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

if ([lock tryLock]) { // 尝试加锁，如果失败返回NO，不会阻塞该线程
	[lock unlock];
}
if ([lock lockBeforeDate:date]) { // 在Date之前尝试加锁，如果不能加锁，则返回NO
	[lock unlock];
}

NSCondition（条件变量）

使用NSCondition（条件变量）对象来控制进程的同步，即可实现生产者消费者问题。其内部是通过pthread_cond_t 来实现. NSCondition是利用线程间共享的全局变量进行同步的一种机制，NSCondition也实现了NSLocking协议，因此也可以调用lock、 unlock来实现线程的同步, 为了防止竞争，条件变量的使用总是和一个互斥锁结合在一起.

生产者-消费者模式

首先要创建公用的NSCondition实例。然后：

消费者取得锁，取产品，如果没有，则wait，这时会释放锁，直到有线程唤醒它去消费产品；
生产者制造产品，首先也是要取得锁，然后生产，再发signal，这样可唤醒wait的消费者。

NSCondition提供了这么些API：

- (void)wait; // 让当前线程处于等待状态
- (BOOL)waitUntilDate:(NSDate *)limit;
- (void)signal; // CPU发信号告诉线程不用在等待，可以继续执行
- (void)broadcast; // 唤醒等待的所有线程

// 唤醒在此NSCondition对象上等待的所有线程    
- (void)broadcast {
  pthread_cond_broadcast(&_condition);
}

// NSCondition 的初始化方法，通过`pthread_cond_init`创建一个条件对象，并初始化一个属性为`attr_reporting `的锁
- (id)init {
  if (nil != (self = [super init])) {
      if (0 != pthread_cond_init(&_condition, NULL)) {
		  DESTROY(self);
	   } else if (0 != pthread_mutex_init(&_mutex, &attr_reporting)) {
		  pthread_cond_destroy(&_condition);
		  DESTROY(self);
		}
    }
  return self;
}

// 唤醒在此NSCondition对象上等待的单个线程
- (void)signal {
  pthread_cond_signal(&_condition);
}

// 该方法让线程一直等待
- (void)wait {
  pthread_cond_wait(&_condition, &_mutex);
}

// 一直等待直到超时时间
- (BOOL)waitUntilDate: (NSDate*)limit {
  NSTimeInterval t = [limit timeIntervalSince1970];
  double secs, subsecs;
  struct timespec timeout;
  int retVal = 0;

  // Split the float into seconds and fractions of a second
  subsecs = modf(t, &secs);
  timeout.tv_sec = secs;
  // Convert fractions of a second to nanoseconds
  timeout.tv_nsec = subsecs * 1e9;

  // 设置等待条件变量cond，如果超时，则返回；如果等待到条件变量cond，也返回 
   retVal = pthread_cond_timedwait(&_condition, &_mutex, &timeout);

  if (retVal == 0) {
      return YES;
  } else if (retVal == EINVAL) {
      NSLog(@"Invalid arguments to pthread_cond_timedwait");
  }
  return NO;
}

下面来看下使用方法:

// 创建消费者
- (void)createConsumenr {
	dispatch_async(dispatch_get_global_queue(0, 0), ^{
		[condition lock];
	    while (products.count == 0) {
	        NSLog(@"wait for products");
	        [condition wait];
	    }
	    [products removeObjectAtIndex:0];
	    NSLog(@"comsume a product");
	    [condition unlock];
	});
}

// 创建生产者
- (void)createProducter {
	dispatch_async(dispatch_get_global_queue(0, 0), ^{
		 [condition lock];
	    [products addObject:[[NSObject alloc] init]];
	    NSLog(@"produce a product");
	    [condition signal];
	    [condition unlock];
	});
}

当condition进入到判断条件中，products.count == 0时，condition调用wait使当前线程处于等待状态；其他线程开始访问products，当NSObject创建完成并加入到products时，cpu发出single的信号时，处于等待的线程被唤醒，开始执行[products removeObjectAtIndex:0]

pthread_mutex (recursive)

这个就是上文说的pthread_mutex , 但它的属性类型是PTHREAD_MUTEX_RECURSIVE, 也就是支持递归，允许一个线程递归的申请锁，而不会造成死锁. 这与等会说到的NSRecursiveLock实现类似

NSRecursiveLock（递归锁）

我们来看下它的实现,

+ (void)initialize {
  [NSLock class];	// Ensure mutex attributes are set up.
}

- (id)init {
  if (nil != (self = [super init])) {
      if (0 != pthread_mutex_init(&_mutex, &attr_recursive)) {
		  DESTROY(self);	
	   }
  }
  return self;
}

它在类初始化的时候，调用的是NSLock 类的初始化方法，也就是初始化了三种attributes, 然后在init的时候，初始化了属性为attr_recursive的锁，也就是递归锁，也就是说它支持递归和循环, NSRecursiveLock 会记录上锁和解锁的次数，当二者平衡的时候，才会释放锁，其它线程才可以上锁成功, 所以不会造成死锁.

因为内部判断了锁的类型，所以性能会比pthread_mutex(recursive) 要低一些

NSConditionLock （条件锁）

其实条件锁也是一个生产者-消费者模式，内部通过NSCondition来实现. NSConditionLock会持有一个 NSCondition 对象和 _condition_value 属性，在初始化时就会对这个属性进行赋值 ,默认的init, value则为0, 我们来看下它的方法实现：


- (id)init {
  return [self initWithCondition: 0];
}

- (id)initWithCondition:(NSInteger)value {
  if (nil != (self = [super init])) {
      if (nil == (_condition = [NSCondition new])) {
		  DESTROY(self);
	   } else {
         _condition_value = value;
		}
   }
  return self;
}

其中很重要的一个属性便是condition,外部传入的condition与内部相同才会获取到lock对象，反之阻塞当前线程，直到condition相同, 这其实是一个消费者方法

// 消费者方法
- (void)lockWhenCondition:(NSInteger)value {
  [_condition lock];
  while (value != _condition_value) {
      [_condition wait];
    }
}

// 生产者方法
- (void)unlockWithCondition:(NSInteger)value {
  _condition_value = value;
  [_condition broadcast];
  [_condition unlock];
}

但是解锁的时候并不是condition相同才能解锁, 而是给_condition_value 赋值并通过broadcast方法唤醒在此NSCondition对象上等待的所有线程, 最后解锁

我们来看下使用方法:


NSConditionLock *lock = [[NSConditionLock alloc] initWithCondition:0];

//线程1    
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
        [lock lockWhenCondition:1];
        NSLog(@"线程1");
        sleep(2);
        [lock unlock];
    });

//线程2   
 dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
        sleep(1);//以保证让线程2的代码后执行
        if ([lock tryLockWhenCondition:0]) {
            NSLog(@"线程2");
            [lock unlockWithCondition:2];
            NSLog(@"线程2解锁成功");
        }
    });

//线程3
 dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
        sleep(2);//以保证让线程2的代码后执行
        if ([lock tryLockWhenCondition:2]) {
            NSLog(@"线程3");
            [lock unlock];
            NSLog(@"线程3解锁成功");
        }
    });

//线程4
 dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
        sleep(3);//以保证让线程2的代码后执行
        if ([lock tryLockWhenCondition:2]) {
            NSLog(@"线程4");
            [lock unlockWithCondition:1];    
            NSLog(@"线程4解锁成功");
        }
    });

输出如下:

2017-09-26 00:01:03.235 LuaTest[72076:8074748] 线程2
2017-09-26 00:01:03.236 LuaTest[72076:8074748] 线程2解锁成功
2017-09-26 00:01:04.232 LuaTest[72076:8074747] 线程3
2017-09-26 00:01:04.232 LuaTest[72076:8074747] 线程3解锁成功
2017-09-26 00:01:05.234 LuaTest[72076:8074770] 线程4
2017-09-26 00:01:05.235 LuaTest[72076:8074770] 线程4解锁成功
2017-09-26 00:01:05.235 LuaTest[72076:8074767] 线程1

上面代码先输出了 线程 2，因为线程 1 的加锁条件不满足，初始化时候的 condition 参数为 0，而加锁条件是 condition 为 1，所以加锁失败。locakWhenCondition 与 lock 方法类似，加锁失败会阻塞线程，所以线程 1 会被阻塞着，而 tryLockWhenCondition 方法就算条件不满足，也会返回 NO，不会阻塞当前线程。回到上面的代码，线程 2 执行了 [lock unlockWithCondition:2] 所以 Condition 被修改成了 2。而线程 3 的加锁条件是 Condition 为 2，所以线程 3 才能加锁成功，线程 3 执行了 [lock unlock]; 解锁成功且不改变 Condition 值。线程 4 的条件也是 2，所以也加锁成功，解锁时将 Condition 改成 1。这个时候线程 1 终于可以加锁成功，解除了阻塞。假如线程4``unlockWithCondition 解锁条件为非1, 内部conditon值不一致, 那么线程1将会永久阻塞.

从上面可以得出，NSConditionLock 还可以实现任务之间的依赖。

@Synchronized

先来看下用法，

1
2
3

@synchronized (obj) {
	// do something            
}

也就是只需要传入一个对象，就可以使代码块实现同步

我们在Xcode中选择Product -> Perform Action -> Assemble 'main.m', 我们便能看到汇编代码…

我们会发现两个比较陌生的方法调用 _objc_sync_enter和 _objc_sync_exit emmmmmm ？

… 我们只调用了synchronized … 莫非就是这个函数的底层实现？我们到objc源码找找, 在objc-sync.mm中找到了这两个函数的实现

// Begin synchronizing on 'obj'. 
// Allocates recursive mutex associated with 'obj' if needed.
// Returns OBJC_SYNC_SUCCESS once lock is acquired.  

int objc_sync_enter(id obj) {
    int result = OBJC_SYNC_SUCCESS;
    
    if (obj) {
        SyncData *data = id2data(obj, ACQUIRE);
        data->mutex.lock();
    } else {
        // @synchronized(nil) does nothing
        objc_sync_nil();
    }
    return result;
}

方法的注释已经很清楚了，这个方法的实现用的是递归锁，首先判断obj是否存在，如果存在则通过obj创建一个SyncData 对象，然后调用lock，否则则直接调用objc_sync_nil ()方法，这是一个空方法，啥都没干,也就是说如果直接调用@synchronized(nil)的话，其实什么都没有做，也不会创建锁.

typedef struct SyncData {
    struct SyncData* nextData;
    DisguisedPtr<objc_object> object;
    int32_t threadCount;  // number of THREADS using this block
    recursive_mutex_t mutex;
} SyncData;

SyncData 包括nextData、object 、threadCount (线程数)、mutex (递归锁)

我们来看下方法是如何通过obj获取到data的，

/*
  Fast cache: two fixed pthread keys store a single SyncCacheItem. 
  This avoids malloc of the SyncCache for threads that only synchronize 
  a single object at a time.
  SYNC_DATA_DIRECT_KEY  == SyncCacheItem.data
  SYNC_COUNT_DIRECT_KEY == SyncCacheItem.lockCount
 */

struct SyncList {
    SyncData *data;
    spinlock_t lock;
    SyncList() : data(nil), lock(fork_unsafe_lock) { }
};

// Use multiple parallel lists to decrease contention among unrelated objects.
#define LOCK_FOR_OBJ(obj) sDataLists[obj].lock
#define LIST_FOR_OBJ(obj) sDataLists[obj].data
static StripedMap<SyncList> sDataLists;

发现定义了sDataLists ，一个SyncList 结构体数组,

static unsigned int indexForPointer(const void *p) {
    uintptr_t addr = reinterpret_cast<uintptr_t>(p);
    return ((addr >> 4) ^ (addr >> 9)) % StripeCount;
}

T& operator[] (const void *p) { 
   return array[indexForPointer(p)].value; 
}

通过哈希算法将传入obj映射到数组上的一个下标, 是将对象指针在内存的地址,映射到另一个内存空间来存放SyncList,这样能够保证不会发生数组越界，当调用objc_sync_enter 时，通过obj内存地址的哈希值找到 SyncData,并调用lock

// End synchronizing on 'obj'. 
// Returns OBJC_SYNC_SUCCESS or OBJC_SYNC_NOT_OWNING_THREAD_ERROR

int objc_sync_exit(id obj) {
    int result = OBJC_SYNC_SUCCESS;
    if (obj) {
        SyncData* data = id2data(obj, RELEASE); 
        if (!data) {
            result = OBJC_SYNC_NOT_OWNING_THREAD_ERROR;
        } else {
            bool okay = data->mutex.tryUnlock();
            if (!okay) {
                result = OBJC_SYNC_NOT_OWNING_THREAD_ERROR;
            }
        }
    } else {
        // @synchronized(nil) does nothing
    }
    return result;
}

objc_sync_exit 方法也差不多，通过obj内存地址的哈希值找到 SyncData,并调用tryUnlock,如果返回true,则表示解锁成功，否则是失败

NSDistributedLock (分布式锁)

NSDistributedLock与其他锁不太一样, 它没有实现NSLocking协议, 它底层是基于文件系统实现的互斥锁，会自动创建用于标识的临时文件或文件夹，执行完后自动清除临时文件或文件夹；可以在多个进程或多个程序之间需要构建互斥的场景中使用

+ (void)initialize {
  if (mgr == nil) {
      mgr = RETAIN([NSFileManager defaultManager]);
      [[NSObject leakAt: &mgr] release];
    }
}

- (id)initWithPath:(NSString*)aPath {
  NSString	*lockDir;
  BOOL		isDirectory;

  _lockPath = [[aPath stringByStandardizingPath] copy];
  _lockTime = nil;

  lockDir = [_lockPath stringByDeletingLastPathComponent];
  if ([mgr fileExistsAtPath: lockDir isDirectory: &isDirectory] == NO) {
      DESTROY(self);
      return nil;
  }   
  if (isDirectory == NO) {
      DESTROY(self);
      return nil;
  }
  if ([mgr isWritableFileAtPath: lockDir] == NO) {
      DESTROY(self);
      return nil;
  }
  if ([mgr isExecutableFileAtPath: lockDir] == NO) {
      DESTROY(self);
      return nil;
  }
  return self;
}

我们从它的初始化方法便能够看出内部是基于NSFileManager文件系统实现的，由于其没有实现NSLocking协议，所以没有会阻塞线程的lock方法，取而代之的是非阻塞的tryLock方法, NSDistributedLock只有在锁持有者显式地释放后才会被释放. 如果你的程序在一个NSDistributedLock 的时候崩溃了，其他客户端无法访问该受保护的资源。在这种情况下，你可以使用breadLock方法来打破现存的锁以便你可以获取它, 但是通常应该避免打破锁，除非你确定拥有进程已经死亡并不可能再释放该锁. 和其他类型的锁一样，当你使用NSDistributedLock对象时，你也可以通过调用unlock方法来释放它

PS：花了快一星期零零碎碎的时间，研究了一下这些🔐，发现收货良多，从🔐的使用到实现都有了更进一步的认识.以及对锁的性能也有了进一步的理解.

本文作者： Aeron_Xie
最后更新： 2023年03月25日 22:39:55
本文链接： http://aeronxie.github.io/post/ad4ae88b.html
版权声明： 本作品采用 CC BY-NC-SA 4.0 许可协议进行许可，转载请注明出处！