没有同时性，不编程。说到多线程很难解锁。
iOS开发中常见的两种锁：
1 .排他锁：同时只能获得一个线程排他锁，其馀线程处于挂起状态。
2 .旋转锁：在一个线程获得旋转锁后，另一个线程一直尝试创建循环并锁定，但在超过限制次数后仍无法获得锁时，线程也会挂起。
自旋锁适用于锁的持有者保存时间短的情况，在实际使用中多使用互斥锁
1 .排他锁，信号量
遵守NSLocking协议的四种锁定
四种摇滚分别是：
NSLock、NSConditionLock、NSRecursiveLock和NSCondition
ns锁定协议公共协议锁定{
publicfunclock (
publicfuncunlock (
}
以多个售票点同时售票为例。 varticket=20
varlock=NSLock ()
overridefunctouchesbegan (_ touches : set，withevent:UIEvent？ () )。
let thread1=thread (target : self，selector:#selector ) saletickets )，object:nil ) ) )。
thread1.name='售票点a '
thread1.start (
let thread2=thread (target : self，selector:#selector ) saletickets )，object:nil ) ) )。
thread2.name='售票点b '
thread2.start (
}
@objcprivatefuncsaleTickets (
whiletrue{
lock.lock () )。
thread.sleep (for time interval :0.5 ) /模拟延迟
ifticket0{
ticket=ticket-1
print ((string (describing : thread.current.name！ () )卖了一张票，但现在还有票(((ticket ) ) )
lock.unlock (
}else{
print('oh票已经卖完了) )。
lock.unlock (
黑；
}
}
}
遵守协议实现的两种方法lock (和unlock )，顾名思义。
此外，NSLock、NSConditionLock、NSRecursiveLock、NSCondition种互斥锁分别实现了：
对于非NSCondition的3种锁定，尝试2种方法：//解锁，如果成功则返回true，否则返回false
openfunc`try ` () )-Bool
在limit时间之前取得了锁，没有回复NO
openfunclock (before limit : date )-Bool
2. NSCondition条件锁定：//当前线程挂起
openfuncwait (
//当前线程挂起并设置唤醒时间
openfuncwait (until limit : date )-Bool
//唤醒正在等待的线程
openfuncsignal ()
调用NSCondition的所有挂起的线程
openfuncbroadcast (
调用wait ()时，NSCondition实例会解锁当前已锁定的线程，然后使线程进入休眠状态。 signal ) )时，线程被唤醒，然后锁定当前线程，因此wait ) )看起来像是保持了锁定，但根据苹果文档的说明，wait ) )将直接锁定
3. NSConditionLock条件锁定：
NSConditionLock通过NSCondition实现，在NSCondition中加入了限制条件，可定制性高于NSCondition。 ///锁定时还必须满足condition
开放时钟(whenconditioncondition : int ) )。
和//try一样，需要满足条件
openfunctrylock (whenconditioncondition : int )-Bool
//必须满足该unlock、condition
openfuncunlock (withconditioncondi
tion: Int)// 同lock,需要满足condition和在limit时间之前
open func lock(whenCondition condition: Int, before limit: Date) -> Bool
4. NSRecurisiveLock递归锁:
定义了可以多次给相同线程上锁并不会造成死锁的锁.
提供的几个方法和NSLock类似.
2. GCD的DispatchSemaphore和栅栏函数
1. DispatchSemaphore信号量:
DispatchSemaphore中的信号量,可以解决资源抢占的问题,支持信号的通知和等待.每当发送一个信号通知,则信号量+1;每当发送一个等待信号时信号量-1,如果信号量为0则信号会处于等待状态.直到信号量大于0开始执行.所以我们一般将DispatchSemaphore的value设置为1.
下面给出了DispatchSemaphore的封装类class GCDSemaphore {
// hxdfk: 变量
fileprivate var dispatchSemaphore: DispatchSemaphore!
// hxdfk: 初始化
public init() {
dispatchSemaphore = DispatchSemaphore(value: 0)
}
public init(withValue: Int) {
dispatchSemaphore = DispatchSemaphore(value: withValue)
}
// 执行
public func signal() -> Bool {
return dispatchSemaphore.signal() != 0
}
public func wait() {
_ = dispatchSemaphore.wait(timeout: DispatchTime.distantFuture)
}
public func wait(timeoutNanoseconds: DispatchTimeInterval) -> Bool {
if dispatchSemaphore.wait(timeout: DispatchTime.now() + timeoutNanoseconds) == DispatchTimeoutResult.success {
return true
} else {
return false
}
}
}
2. barrier栅栏函数:
栅栏函数也可以做线程同步,当然了这个肯定是要并行队列中才能起作用.只有当当前的并行队列执行完毕,才会执行栅栏队列./// 创建并发队列
let queue = DispatchQueue(label: "queuename", attributes: .concurrent)
/// 异步函数
queue.async {
for _ in 1...5 {
print(Thread.current)
}
}
queue.async {
for _ in 1...5 {
print(Thread.current)
}
}
/// 栅栏函数
queue.async(flags: .barrier) {
print("barrier")
}
queue.async {
for _ in 1...5 {
print(Thread.current)
}
}
3. 其他的互斥锁
1. pthread_mutex互斥锁
pthread表示POSIX thread,跨平台的线程相关的API,pthread_mutex也是一种互斥锁,互斥锁的实现原理与信号量非常相似,阻塞线程并睡眠,需要进行上下文切换.
一般情况下,一个线程只能申请一次锁,也只能在获得锁的情况下才能释放锁,多次申请锁或释放未获得的锁都会导致崩溃.假设在已经获得锁的情况下再次申请锁,线程会因为等待锁的释放而进入睡眠状态,因此就不可能再释放锁，从而导致死锁.
这边给出了一个基于pthread_mutex_t(安全的"FIFO"互斥锁)的基本封装 MutexLock
1. @synchronized条件锁
日常开发中最常用的应该是@synchronized,这个关键字可以用来修饰一个变量,并为其自动加上和解除互斥锁.这样,可以保证变量在作用范围内不会被其他线程改变.但是在swift中它已经不存在了.其实@synchronized在幕后做的事情是调用了objc_sync中的objc_sync_enter和objc_sync_exit 方法，并且加入了一些异常判断.
因此我们可以利用闭包自己封装一套.func synchronized(lock: AnyObject, closure: () -> ()) {
objc_sync_enter(lock)
closure()
objc_sync_exit(lock)
}
// 使用
synchronized(lock: AnyObject) {
// 此处AnyObject不会被其他线程改变
}
2. 自旋锁
1. OSSpinLock自旋锁
执行效率最高的锁,不过在iOS10.0以后废弃了这种锁机制,使用os_unfair_lock替换,
fndxq能够保证不同优先级的线程申请锁的时候不会发生优先级反转问题.
2. os_unfair_lock自旋锁
对于os_unfair_lock,非FIFO的锁,苹果为了取代OSSPinLock新出的一个锁,一个高级的能够避免优先级带来的死锁问题的一个锁,OSSPinLock之前就爆出在iOS平台有由于优先级造成死锁的问题).
注意: 这个锁适用于小场景下的一个高效锁,否则会大量消耗cpu资源.var unsafeMutex = os_unfair_lock()
os_unfair_lock_lock(&unsafeMutex)
os_unfair_lock_trylock(&unsafeMutex)
os_unfair_lock_unlock(&unsafeMutex)
这边给出了基于os_unfair_lock的封装 MutexLock
3. 性能比较
这边贴一张大神ibireme在iPhone6、iOS9对各种锁的性能测试图
作者：Dariel
链接：https://www.jianshu.com/p/a321377c5639