无并发,不编程.提到多线程就很难绕开锁??.
iOS开发中较常见的两类锁:
自旋锁较适用于锁的持有者保存时间较短的情况下,实际使用中互斥锁会用的多少量.
NSLocking
协议的四种锁四种锁分别是:NSLock
、NSConditionLock
、NSRecursiveLock
、NSCondition
NSLocking
协议
public protocol NSLocking { public func lock() public func unlock()}
下面举个多个售票点同时卖票的例子
var ticket = 20var lock = NSLock() override func touchesBegan(_ touches: Set<UITouch>, with event: 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()} @objc private func saleTickets() { while true { lock.lock() Thread.sleep(forTimeInterval: 0.5) // 模拟推迟 if ticket > 0 { ticket = ticket - 1 print("\(String(describing: Thread.current.name!)) 卖出了一张票,当前还剩\(ticket)张票") lock.unlock() }else { print("oh 票已经卖完了") lock.unlock() break; } }}
遵守协议后实现的两个方法lock()
和unlock()
,意如其名.
除此之外NSLock
、NSConditionLock
、NSRecursiveLock
、NSCondition
四种互斥锁各有其实现:
NSCondition
外,三种锁都有的两个方法: // 尝试去锁,假如成功,返回true,否则返回false open func `try`() -> Bool // 在limit时间之前取得锁,没有返回NO open func lock(before limit: Date) -> Bool
NSCondition
条件锁: // 当前线程挂起 open func wait() // 当前线程挂起,设置一个唤醒时间 open func wait(until limit: Date) -> Bool // 唤醒在等待的线程 open func signal() // 唤醒所有NSCondition挂起的线程 open func broadcast()
当调用wait()
之后,NSCondition
实例会解锁已有锁的当前线程,而后再使线程休眠,当被signal()
通知后,线程被唤醒,而后再给当前线程加锁,所以看起来如同wait()
一直持有该锁,但根据苹果文档中说明,直接把wait()
当线程锁并不能保证线程安全.
NSConditionLock
条件锁:NSConditionLock
是借助NSCondition
来实现的,在NSCondition
的基础上加了限定条件,可自己设置程度相对NSCondition
会高些.
// 锁的时候还需要满足condition open func lock(whenCondition condition: Int) // 同try,同样需要满足condition open func tryLock(whenCondition condition: Int) -> Bool // 同unlock,需要满足condition open func unlock(withCondition condition: Int) // 同lock,需要满足condition和在limit时间之前 open func lock(whenCondition condition: Int, before limit: Date) -> Bool
NSRecurisiveLock
递归锁:定义了可以屡次给相同线程上锁并不会造成死锁的锁.
提供的几个方法和NSLock
相似.
DispatchSemaphore
和栅栏函数DispatchSemaphore
信号量:DispatchSemaphore
中的信号量,可以处理资源抢占的问题,支持信号的通知和等待.每当发送一个信号通知,则信号量+1;每当发送一个等待信号时信号量-1,假如信号量为0则信号会处于等待状态.直到信号量大于0开始执行.所以我们一般将DispatchSemaphore
的value设置为1.
下面给出了DispatchSemaphore
的封装类
class GCDSemaphore { // MARK: 变量 fileprivate var dispatchSemaphore: DispatchSemaphore! // MARK: 初始化 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 } }}
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) }}
pthread_mutex
互斥锁pthread
表示POSIX thread
,跨平台的线程相关的API,pthread_mutex
也是一种互斥锁,互斥锁的实现原理与信号量非常类似,阻塞线程并睡眠,需要进行上下文切换.
一般情况下,一个线程只能申请一次锁,也只能在取得锁的情况下才能释放锁,屡次申请锁或者释放未取得的锁都会导致崩溃.假设在已经取得锁的情况下再次申请锁,线程会由于等待锁的释放而进入睡眠状态,因而就不可能再释放锁,从而导致死锁.
这边给出了一个基于pthread_mutex_t
(安全的"FIFO"互斥锁)的基本封装 MutexLock
日常开发中最常用的应该是@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不会被其余线程改变}
OSSpinLock
自旋锁执行效率最高的锁,不过在iOS10.0以后废弃了这种锁机制,使用os_unfair_lock
替换,
顾名思义能够保证不同优先级的线程申请锁的时候不会发生优先级反转问题.
详见大神ibireme的不再安全的 OSSpinLock
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
这边贴一张大神ibireme在iPhone6、iOS9对各种锁的性能测试图
参考:
不再安全的OSSpinLock
深入了解iOS开发中的锁