1、System先ANR。
2、ANR之后系统重启。
Platform：MT6732
Android版本：4.4.4KK
BuildType：user
系统软件版本：D17+ZX
系统RAM:1GB
问题概率：暂未统计，截止到目前仅此1次
通过初步分析、深入分析（）我们清楚的知道了问题发生的原因：
4、
考虑mediaserver中复杂的逻辑，所以要以最小风险的改动来修复这个问题，因此这里给出的方案没有进行太大的改动。
最终，针对以上问题的根本原因，我们给出以下解决方案：
在可能递归调用的加了mutex autolock的函数中，使用vector容器延长sp指针的生命周期，使其在mutex autolock生命周期结束并unlock之后再析构sp指针，此时如果再发生递归调用则不会死锁。
以上是发生死锁时锁对应的backtrace调用栈以及相应的代码，通过红线圈住部分我们可以看到发生问题时的关键调用关系和状态。
通过查看如上对应代码，发现setParameter这个方法会通过audioflinger的代理对象跨进程调用到mediaserver中的audioflinger的setParameter方法，因此接下来就要mediaserver进程是否工作的正常。
根据这个线索继续查看mediaserver中各个thread的调用栈，发现几乎所有的Binder thread都被block了，这也就解释了为什么SystemServer的调用得不到处理而发生ANR以及SWT重启。其中绝大多数Binder thread被block的backtrace如下：
由于mediaserver是native的C/C++代码，所以需要用通过查看其他thread的backtrace，发现，但是它也被block在另外一个mutex lock上，，具体的backtrace和代码如下：
顺着这个线索我们继续看mediaserver进程中的其他thread，看谁占用了，最终找到了
经过初步分析我们定位到了第一个问题点，即
通过进一步分析和查看代码发现，rstp thread之所以会间接递归调用，关键代码如下：
回答完第一个问题，我们接下来看第二个问题，在回答上面第二个问题之前我们需要先简单说一下，从而实现自动的Mutex。而Mutex类是
Analyzed by vincent.song fromSWD2 Framework team.
vincent.song@tcl.com
201506242052
版权声明：本文为博主原创文章，未经博主允许不得转载。
下午某时，天气晴，我在某地，想念你。
