线程安全: 互斥锁和自旋锁(10种)

无并发,不编程.提到多线程就很难绕开锁🔐.

iOS开发中较常见的两类锁:

1. 互斥锁: 同一时刻只能有一个线程获得互斥锁,其余线程处于挂起状态.
2. 自旋锁: 当某个线程获得自旋锁后,别的线程会一直做循环,尝试加锁,当超过了限定的次数仍然没有成功获得锁时,线程也会被挂起.

自旋锁较适用于锁的持有者保存时间较短的情况下,实际使用中互斥锁会用的多一些.

1. 互斥锁,信号量

1.遵守NSLocking协议的四种锁

四种锁分别是:
NSLockNSConditionLockNSRecursiveLockNSCondition

NSLocking协议

public protocol NSLocking {    
    public func lock()
    public func unlock()
}

下面举个多个售票点同时卖票的例子

var ticket = 20
var 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(),意如其名.

除此之外NSLockNSConditionLockNSRecursiveLockNSCondition四种互斥锁各有其实现:

1. 除NSCondition外,三种锁都有的两个方法:
    // 尝试去锁,如果成功,返回true,否则返回false
    open func `try`() -> Bool
    // 在limit时间之前获得锁,没有返回NO
    open func lock(before limit: Date) -> Bool
2. NSCondition条件锁:
    // 当前线程挂起
    open func wait()
    // 当前线程挂起,设置一个唤醒时间
    open func wait(until limit: Date) -> Bool
    // 唤醒在等待的线程
    open func signal()
    // 唤醒所有NSCondition挂起的线程
    open func broadcast()

当调用wait()之后,NSCondition实例会解锁已有锁的当前线程,然后再使线程休眠,当被signal()通知后,线程被唤醒,然后再给当前线程加锁,所以看起来好像wait()一直持有该锁,但根据苹果文档中说明,直接把wait()当线程锁并不能保证线程安全.

3. 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
4. NSRecurisiveLock递归锁:

定义了可以多次给相同线程上锁并不会造成死锁的锁.

提供的几个方法和NSLock类似.

2. GCD的DispatchSemaphore和栅栏函数
1. 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
        }
    }
}
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_enterobjc_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替换,
顾名思义能够保证不同优先级的线程申请锁的时候不会发生优先级反转问题.

详见大神ibireme的不再安全的 OSSpinLock

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对各种锁的性能测试图

image
本文收录于 SwiftTips

参考:
不再安全的OSSpinLock
深入理解iOS开发中的锁

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 158,560评论 4 361
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 67,104评论 1 291
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 108,297评论 0 243
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 43,869评论 0 204
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 52,275评论 3 287
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 40,563评论 1 216
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 31,833评论 2 312
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 30,543评论 0 197
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 34,245评论 1 241
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 30,512评论 2 244
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 32,011评论 1 258
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 28,359评论 2 253
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 33,006评论 3 235
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 26,062评论 0 8
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 26,825评论 0 194
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 35,590评论 2 273
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 35,501评论 2 268