视频系统--线程死锁调试

本文原地址: http://www.feitianzhi.com/boke/index.php/archives/27/

---

概述

      "视频系统"虽采用面向过程对象(参见:http://www.feitianzhi.com/boke/index.php/archives/18/)编程,去除线程池等复杂的设计,并减少线程的使用量,但线程数依然高达40个之多;
      40个线程数虽对cpu而言已没有任何压力了,但多线程的复杂性依然存在,其中线程死锁是多线程中最常见同时也难以定位的问题;

---

线程死锁产生的原因分析

1. 能否通过合理的设计规划避免线程死锁?
   "小雉视频系统"是一份持续维护并增加新功能的代码,代码的修改必须考虑与老代码的兼容,需要处理的细节多,对每次修改都做出完美的设计几乎是不能实现的;
2. 能否使用第三方工具查找线程死锁?
   对开发阶段就能发现的死锁用第三方工具定位是处理问题的通用方法,但使用第三方工具会导致系统速度指数级别的下降,在生产环境中无法使用,同时"小雉视频系统"模块众多,模块均支持按需开启和关闭,任何一个修改需要准备的测试用例太多,死锁后难以确定与此死锁相关的模块;

---

理想化设计

1. 死锁时自动报告是哪些线程卡住了?卡在源码的哪一行?卡时的调用堆栈是什么样?
2. 可在任意时间接受外部干预,报告所有线程当前执行到哪段源代码的哪行并提供调用堆栈;

---

小雉视频系统--线程死锁设计预览

1. 线程死锁时自动报告,"小雉视频系统"并不能判断线程死锁,"小雉视频系统"是做视频应用,5S以上的卡顿足以让用户不满,"小雉视频系统"是监视所有线程,看哪个线程连续5S时间内一直停在同一句代码处,以此认为其死锁了,效果如下:转存失败重新上传取消转存失败重新上传取消转存失败重新上传取消转存失败重新上传取消转存失败重新上传取消转存失败重新上传取消转存失败重新上传取消转存失败重新上传取消转存失败重新上传取消转存失败重新上传取消转存失败重新上传取消转存失败重新上传取消转存失败重新上传取消转存失败重新上传取消转存失败重新上传取消

   

    

2. 任意时间打印所有线程的调用堆栈,"视频系统"监听linux下10的信号,在收到信号后打印所有线程当前的调用堆栈,效果如下:转存失败重新上传取消转存失败重新上传取消转存失败重新上传取消转存失败重新上传取消转存失败重新上传取消转存失败重新上传取消转存失败重新上传取消转存失败重新上传取消转存失败重新上传取消转存失败重新上传取消转存失败重新上传取消转存失败重新上传取消转存失败重新上传取消转存失败重新上传取消转存失败重新上传取消

   

    

猜您可能喜欢