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

软件发布|下载排行|最新软件

当前位置:首页IT学院IT技术

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

  2021-03-25 我要评论
想了解IOS 实现一个死锁导致 UI 假死的例子的相关内容吗,在本文为您仔细讲解IOS UI假死的相关知识和一些Code实例,欢迎阅读和指正,我们先划重点:IOS,UI假死,IOS,死锁导致UI假死,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。

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

Copyright 2022 版权所有 软件发布 访问手机版

声明:所有软件和文章来自软件开发商或者作者 如有异议 请与本站联系 联系我们