Android WatchDog

最新推荐文章于 2024-01-10 15:50:26 发布

weixin_41355766

最新推荐文章于 2024-01-10 15:50:26 发布

阅读量85

点赞数

本文链接：https://blog.csdn.net/weixin_41355766/article/details/102953848

版权

https://blog.csdn.net/fu_kevin0606/article/details/64479489
https://blog.csdn.net/lezhang123/article/details/72537647
https://www.jianshu.com/p/af5c93fd84c6 java的线程锁
对于Monitor Checker而言，会调用实现类的monitor方法，譬如上文中提到的AMS.monitor()方法，方法实现一般很简单，就是获取当前类的对象锁，如果当前对象锁已经被持有，则monitor()会一直处于wait状态，直到超时，这种情况下，很可能是线程发生了死锁。
monitor()因为获取不到锁，就一直处于等待状态，那么在HandlerChecker的run函数里面就没法给 mCompleted赋值为true, mCompleted的值一直处于false状态，因为线程阻塞在那了执行不到后面的： synchronized (Watchdog.this) {
mCompleted = true;
mCurrentMonitor = null;
}。
然后watchdog下次或者下下次检测时(每次间隔30秒)，会结合mCompleted和上次发出的postAtFrontOfQueue的时间到现在的时间差，如果mCompleted还是false，而且时间差超过60秒就杀死systemServer。Looper Checker的检查也差不多这样的原理，Looper如果阻塞都不会跑到HandlerChecker的run函数，自然而然mCompleted是false的。后面的超时判断原理是一样的。