简介
之前接手的老项目,从接手到现在也没怎么去维护过,突然测试那边给我提了一个ANR的BUG,由于从别人手中接手,并且此项目也不是经常需要维护,所有对项目代码并不是特别熟悉,因此解决此问题还是比较麻烦的,今天就把解决ANR的过程记录一下。
分析ANR问题
通过的logcat日志文件可以查看到ANR是发生在哪个进程
通过ANR文件可以发现"main" 主线程是被锁阻塞了
这是一个典型的主线程被锁阻塞的例子;
- waiting to lock <0x05ea7314> (a java.lang.Object) held by thread 4
其中等待的锁是<0x05ea7314>,这个锁的持有者是线程 4。进一步搜索 “tid=4” 找到线程4, 发现它是Native里的nativeStopWfdSession
方法导致的,
通过源码可以发现此方法最终调用了ALooper::awaitResponse
,导致主线程一直被阻塞了。
从上面报错信息,可以看到是MultiscreenSource
类的stop
方法里postAndAwaitResponse
卡死了。
我们通过添加一些日志可以发现其实kWhatStop
的消息方法已经执行了
一路跟过去发现是卡在disconnectClientAsync
方法的mClientInfo.mStreamClient→deinit();
,而这句话最终调用的时候VStreamClient
类的deinit()
方法
最终发现是因为AutoMutex _l(vClientMutex);
的锁导致了死锁
解决问题
上面我们分析到在代码中具体是哪里导致的ANR,通过全文分析导致ANR的锁机制使用的不正确,也就是说那里没必要上锁。最终把加锁的地方去掉就可以了。
标签:分析,发现,导致,接手,项目,阻塞,ANR,方法 From: https://www.cnblogs.com/zuojie/p/16901751.html