CFSDN坚持开源创造价值，我们致力于搭建一个资源共享平台，让每一个IT人在这里找到属于你的精彩世界.

这篇CFSDN的博客文章IOS 线程死锁详细介绍由作者收集整理，如果你对这篇文章有兴趣，记得点赞哟.

ios线程死锁 。

前言:

     在chat view的开发过程中，添加了“混合标签添加与显示”，app出现发送图片会出现卡死的情况，但过了大约30～40 second后会恢复正常.

问题分析:

     因为没有任何报错与提示，只能根据表面现象慢慢分析，经过多次测试与观察得出以下规律:

     （1）发送表情与文本不会发生该情况，只有发送图片才会发生app界面卡死的情况。（主线程阻塞，与大文件上传有关）      （2）app卡死一定时间后会恢复正常，但时间不定，大约范围在30～40 second。（主线程解除阻塞，与系统某些机制有关）      （3）当界面中有gif图时才会发生，界面中全是移动端本地图片是能顺利发送。（与gif下载有关） 。

     根据上述现象，可以总结为：主线程阻塞，过后因通信通信失败而阻塞解除.

     因为与gif图的下载有关，于是分析gif的下载实现，gif图的下载由以下代码实现.

        nsdata *gifimagedata = [nsdatadatawithcontentsofurl:model.imageremoteurl];         flanimatedimage *flaimage = [flanimatedimageanimatedimagewithgifdata:gifimagedata],

     其中，关于nsdata的静态方法datawithcontentsofurl的说明中有以下使用说明.

important do not use this synchronous method to request network-based urls. for network-based urls, this method can block the current thread for tens of seconds on a slow network, resulting in a poor user experience, and in ios, may cause your app to be terminated. 。

     这里说明了要尽量避免使用datawithcontentsofurl从网络下载资源，因为它会阻塞当前线程，若下载的文件比较大而网络又不好就会带来很差的用户体验，对于ios设备还可能引起app被迫终止.

  虽然只需要把datawithcontentsofurl放置到别的线程中实现，又或者使用nsurlconnect、nsurlsession中的异步请求方法也能解决问题，但本质上引起这问题是因为调用datawithcontentsofurl时网络环境差吗?

  明显不是，因为测试环境是模拟器，模拟器的cpu、网络通信是比真机要好的，只有gpu是不如真机。而且问题的出现规律是固定.

  但datawithcontentsofurl已经解析了为什么主线程阻塞，那么现在需要解析为什么会阻塞那么长的时间.

     cpu分析结果：             。

       图中的标记的那段是发生异常情况时的cpu的情况。从cpu图上可以更加肯定线程是并没有死掉的，而且进入了无法响应的状态，因此可以判断出发生线程死锁的情况.

线程死锁      。

     死锁的概念:

  死锁是进程死锁的简称，是由dijkstra于1965年研究银行家算法时首先提出来的。它是计算机操作系统乃至并发程序设计中最难处理的问题之一。实际上，死锁问题不仅在计算机系统中存在，在我们日常生活中它也广泛存在.

  我们先看看这样一个生活中的例子：在一条河上有一座桥，桥面较窄，只能容纳一辆汽车通过，无法让两辆汽车并行。如果有两辆汽车a和b分别由桥的两端驶上该桥，则对于a车来说，它走过桥面左面的一段路（即占有了桥的一部分资源），要想过桥还须等待b车让出右边的桥面，此时a车不能前进；对于b车来说，它走过桥面右边的一段路（即占有了桥的一部分资源），要想过桥还须等待a车让出左边的桥面，此时b车也不能前进。两边的车都不倒车，结果造成互相等待对方让出桥面，但是谁也不让路，就会无休止地等下去。这种现象就是死锁。如果把汽车比做进程，桥面作为资源，那麽上述问题就描述为：进程a占有资源r1，等待进程b占有的资源rr；进程b占有资源rr，等待进程a占有的资源r1。而且资源r1和rr只允许一个进程占用，即：不允许两个进程同时占用。结果，两个进程都不能继续执行，若不采取其它措施，这种循环等待状况会无限期持续下去，就发生了进程死锁.

  。

     上图是一张描述一个简单的死锁模型的图，首先thread1锁定占有资源y，thread2锁定占有资源x，但同时相互向对方请求资源，因此都无法释放自身资源去访问下一个资源，结果两个线程相互阻塞.

死锁的四个充分必要条件 。

     从以上分析可见，如果在计算机系统中同时具备下面四个必要条件时，那麽会发生死锁。换句话说，只要下面四个条件有一个不具备，系统就不会出现死锁.

    〈1〉互斥条件。即某个资源在一段时间内只能由一个进程占有，不能同时被两个或两个以上的进程占有。这种独占资源如cd-rom驱动器，打印机等等，必须在占有该资源的进程主动释放它之后，其它进程才能占有该资源。这是由资源本身的属性所决定的。如独木桥就是一种独占资源，两方的人不能同时过桥.

    〈2〉不可抢占条件。进程所获得的资源在未使用完毕之前，资源申请者不能强行地从资源占有者手中夺取资源，而只能由该资源的占有者进程自行释放。如过独木桥的人不能强迫对方后退，也不能非法地将对方推下桥，必须是桥上的人自己过桥后空出桥面（即主动释放占有资源），对方的人才能过桥.

    〈3〉占有且申请条件。进程至少已经占有一个资源，但又申请新的资源；由于该资源已被另外进程占有，此时该进程阻塞；但是，它在等待新资源之时，仍继续占用已占有的资源。还以过独木桥为例，甲乙两人在桥上相遇。甲走过一段桥面（即占有了一些资源），还需要走其余的桥面（申请新的资源），但那部分桥面被乙占有（乙走过一段桥面）。甲过不去，前进不能，又不后退；乙也处于同样的状况.

    〈4〉循环等待条件。存在一个进程等待序列{p1，p2，...，pn}，其中p1等待p2所占有的某一资源，p2等待p3所占有的某一源，......，而pn等待p1所占有的的某一资源，形成一个进程循环等待环。就像前面的过独木桥问题，甲等待乙占有的桥面，而乙又等待甲占有的桥面，从而彼此循环等待.

  上面我们提到的这四个条件在死锁时会同时发生。也就是说，只要有一个必要条件不满足，则死锁就可以排除.

项目中死锁的形成与解决 。

     根据以上理论，以及断点调试，可以分析得项目的形成，如下图所描述.

因此只要让同步下载时不会挂起主线程就可以避免线程死锁的情况发生。因此项目中使用nsurlconnet的同步请求方法实现下载即可， 因为它不会挂起主线程，还能让其他线程往主线程中添加代码块block.

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

最后此篇关于IOS 线程死锁详细介绍的文章就讲到这里了,如果你想了解更多关于IOS 线程死锁详细介绍的内容请搜索CFSDN的文章或继续浏览相关文章，希望大家以后支持我的博客！ 。