IOS 实现一个死锁导致 UI 假死的例子

150 阅读 0 评论 99 点赞

我是靠谱客的博主轻松飞鸟，最近开发中收集的这篇文章主要介绍IOS 实现一个死锁导致 UI 假死的例子，觉得挺不错的，现在分享给大家，希望可以做个参考。

概述

IOS 实现一个死锁导致 UI 假死的例子

现象

当 APP 启动一段时间后（约半小时左右），经常会发现 App 界面出现“冻死”的现象。同时后台输出：

[CocoaGoPush]WorkThreadProc end

这时 App 呈现“假死”状态，点击屏幕任何地方没有反应，iPhone 除了开屏关屏无任何响应（包括按 Home 键），当然也无法解锁（但可以重启）。如果用 Xcode 终止应用程序，则 iPhone 又恢复正常。

注：App 使用了 CocoaGoPush 框架。

发现

原来以为是程序主线程中产生了死循环，导致 UI 无反应。但当我点击 Debug 工具栏中的 Pause 按钮，列出当前运行的线程时，则发现问题并不是这样，而是用于死锁。调试暂停后，断点停在了这一句：

app.gopushLock.lock()// MARK: yhy removed 这行导致主线程死锁

app.gopushLock 是一个 NSRecursiveLock 对象：

let gopushLock = NSRecursiveLock()

NSRecursiveLock 是递归锁，该类锁可以在同一线程多次请求一个锁时，不会引起死锁。但如果程序员错误地在两个线程中使用了递归锁，则很容易导致“死锁”出现：两个线程同时对同一个锁进行加锁，同时发现该锁已经锁定，彼此等待对方解锁，导致两个线程都无法执行下去。尤其是有一方是主线程的情况下，主线程被阻塞，UI 呈现假死状态。在这个例子中还发现，gopush 所在的线程也停止了，不再继续监听 gopush 消息和维持心跳。

检查代码发现，代码在另一个地方使用了这个递归锁：

NSURLConnection.sendAsynchronousRequest(request, queue: NSOperationQueue.mainQueue(), completionHandler:{
      (response, data, error) -> Void in

      if (error != nil) {
        app.gopushLock.lock()
        app.isGoPushFetchingMessage = false
        app.gopushLock.unlock()
        println("-----------GoPush Message Guard fail to fetch offline message. err = (error.localizedDescription)-----------")
        ...
 })

NSURLConection.sendAysnchronousRequest 方法导致请求在新的线程中发送，因此 app.gopushLock.lock() 实际上是在子线程中调用的。而另外一处（第一段代码）则是在主线程中调用的，因此导致了“竞争”。

解决

方法一

将主线程中的递归锁调用注释，只留下子线程中的递归锁调用。

方法二

在主线程中采用不同的锁，比如重新定义一个 NSLock 专门用于主线程，和子线程中的 gopushLock 区别开来。

方法三

将 gopushLock 的类型由 NSRecursiveLock 改为 NSLock。顾名思义，递归锁专门用于循环或递归中需要同步的代码，但它却不能避免两个线程同时访问锁中代码的情况。而 NSLock 却恰恰相反，它能避免两个线程同时访问锁中的代码，却不能避免在同一线程中，同步代码中嵌套加锁的情况。检查第二段调用递归锁的情况，发现这里根本没有必要使用递归锁，因为代码中既没有递归也没有循环。因此可以放心地将 gopushLock 修改为 NSLock 而不是 NSRecursiveLock。

感谢阅读，希望能帮助到大家，谢谢大家对本站的支持！