IOS 锁

参考自：http://perpendiculo.us/2009/09/synchronized-nslock-pthread-osspinlock-showdown-done-right/，尊重原创！

苹果多线程 锁的文档 https://developer.apple.com/library/ios/documentation/Cocoa/Conceptual/Multithreading/ThreadSafety/ThreadSafety.html
常见的几种锁有： synchronized 、 NSLock、 pthread_mutex 、OSSpinLock

另外还有：NSRecursiveLock、NSConditionLock、NSDistributedLock 等

一、用法如下：

-(void)testPerformance
{
CFAbsoluteTime startTime,endTime;
int i = 0;

startTime = CFAbsoluteTimeGetCurrent();
for (i = 0 ; i < RUNCOUNT; i++) {
@synchronized(self) {

}
}
endTime = CFAbsoluteTimeGetCurrent();
NSLog(@"totalTime synchronized = %f sec", endTime - startTime);

NSLock *myL = [NSLock new];
startTime = CFAbsoluteTimeGetCurrent();
for(i= 0;i <RUNCOUNT ;i++){
[myL lock];
[myL unlock];
}
endTime = CFAbsoluteTimeGetCurrent();
NSLog(@"totalTime NSLock = %f sec", endTime - startTime);

startTime = CFAbsoluteTimeGetCurrent();
for(i= 0;i <RUNCOUNT ;i++){
pthread_mutex_lock(&sDefaultMutex);
pthread_mutex_unlock(&sDefaultMutex);
}
endTime = CFAbsoluteTimeGetCurrent();
NSLog(@"totalTime pthread = %f sec", endTime - startTime);

startTime = CFAbsoluteTimeGetCurrent();
for(i= 0;i <RUNCOUNT ;i++){
OSSpinLockLock(&_spinLock);
OSSpinLockUnlock(&_spinLock);
}
endTime = CFAbsoluteTimeGetCurrent();
NSLog(@"totalTime OSSpinLock = %f sec", endTime - startTime);
}

View Code

执行1024*1024*1024次空锁的时间是：


执行1024*1024*32次空锁的时间是：


可以看出，几种锁性能相差较大，性能 OSSpinLock > pthread > NSLock >synchronized

三、性能分析

为什么几种锁的性能有如此明显的差异，它们的实现方式有何差别？

So, what makes @sychronized and SpinLock so different from the others?

@synchronized is very heavy weight because it has to set up an exception handler, and it actually ends up taking a few internal locks on its way there. So instead of a simple cheap lock, you’re paying for a couple locks/unlocks just to acquire your measly lock. Those take time.

OSSpinLock, on the other hand, doesn’t even enter the kernel — it just keeps reloading the lock, hoping that it’s unlocked. This is terribly inefficient if locks are held for more than a few nanoseconds, but it saves a costly system call and a couple context switches. Pthread mutexes actually use an OSSpinLock first, to keep things running smoothly where there’s no contention. When there is, it resorts to heavier, kernel-level locking/tasking stuff.

So, if you’ve got hotly-contested locks, OSSpinLock probably isn’t for you (unless your critical sections are _Really_ _Fast_). Pthread mutexes are a tiny bit more expensive, but they avoid the power-wasting effects of OSSpinLock.

NSLock is a pretty wrapper on pthread mutexes. They don’t provide much else, so there’s not much point in using them over pthread mutexes.

Of course, standard optimization disclaimers apply: don’t do it until you’re sure you’ve chosen the correct algorithms, have profiled to find hotspots, and have found locking to be one of those hot items. Otherwise, you’re wasting your time on something that’s likely to provide minimal benefits.