最近在做一个功能，微信公众帐号上的视频监控功能，使用了hls方式，服务器为nginx的RTMP模块。我们的流媒体服务器收到音视频流后，使用librtmp库分发给nginx的rtmp模块，生成好地址后给微信客户端，微信客户端使用ckplayer播放器(或者h5的video标签)播放视频，单独视频延迟20s。
但是现在遇到一个问题：我们的流媒体服务器之前一直都很正常，最近使用了这个librtmp库之后，偶尔会出现卡住的情况，cpu占用率并不高，但是其他的指令都不处理了，我抓了包，发现提供视频的硬件还在源源不断的发音视频数据。看了一段时间，真的是一头雾水，慌的一批！
咨询了同行中人，帮忙分析了一下，问题可能出在librtmp的使用上，范围缩小了。
记得之前另外一个服务器出现了类似的情况，也是不处理外边的指令，同事听了这个描述，就说可能是死锁！最后定位到原因了，真的是死锁，后面解决了那个问题。
现在那个同事已经离职，还好他教了我怎么定位。待bug重现后，别闲着，赶快用windbg抓了dump，命令如下：
.dump /ma C:\dumps\myapp.dmp拷贝至自己的电脑，在windbg设置好之前保存的pdb路径，加载生成的dmp，然后输入命令：
~*kb然后就大概看了列出的线程，发现9 10 11线程都在请求资源：
果然又是死锁！但是这次的死锁比较好定位，接下来又看了12线程：
RTMP_Write函数卡住了，他就是librtmp中的库函数。根据12线程的堆栈，发现他占了至少两个锁没释放，从而导致其他线程等待，也就是比较简单的死锁。
出bug的地方找到了，也印证了最开始的猜想，下面就是上网找librtmp的资料了，相信能解决！
ps：死锁有好几种，还有就是之前的那个服务器的死锁，是这样的情况：线程1中 A锁已锁住，B锁请求；线程2中B锁已锁住，A锁请求！ 这样就死锁了，我们当时分析了逻辑，调整了锁的顺序，问题解决了！问题的定位也是用windbg定位的。稍微复杂一点，主要用了windbg的如下命令：
~*kb 要列出所进程中线程。
!locks 查看锁的情况