WatchDog源码分析

本文分析了WatchDog的源码,其基本原理是通过HandlerChecker在系统服务Loop队列前端post监测任务,若30s内未执行,视为卡顿,60s未完成则重启system_server。WatchDog主要检测死锁,例如ActivityManagerService和MediaProjectionManagerService的monitor()方法。然而,postAtFrontOfQueue可能导致WatchDog的run方法无法执行,引发误判和性能影响。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

  1. 看了一下watchdog的源码总结一下
  2. 基本原理
    1. HandlerChecker 是基本的检测类,scheduleCheckLocked里面会记录开始时间并将minitor()检测方法postAtFrontOfQueue到Loop的队列前端,如果30s内没有执行到这个方法说明系统已经卡顿了(正常Loop队列前端的方法应该很快执行),
      打印一次ActivityManagerService.dumpStackTraces。如果60s没有执行完 重启 并打印 堆栈信息,重启的目的是重新初始化system_server避免一直卡下去
    2. 其中monitor方法作为执行的检测办法被各个检测对象实现,大都是一些获取锁的操作,用来检测死锁情况
    3. 下面是几个类重写的monitor()方法
      1. ActivityManagerService 只调用了synchronized 用来检测死锁没有其他动作
        1. /** In this method we try to acquire our lock to make sure that we have not deadlocked */
          public void monitor() {
          synchronized (this) { }
          }
      2. MediaProjectionManagerService 也是检测死锁

        1. @Override
          publicvoidmonitor() {
          synchronized (mLock) {
          /* check for deadlock */ }

  3. watchdog原理非常简单,就是 开启一个叫做watchdog的线程,然后不停的往要检测线程的Loop队列头部发送任务,如果1分钟之内执行完说明当前检测的线程不卡,否则发生了卡顿,打印log,重启system_server

  4. 有几个问题

    1. 其他地方可能也会postAtFrontOfQueue 导致watchdog的run方法没有机会执行,1分钟之后也会触发超时
    2. monitor方法本身也会耗时一方面会有误判断情况,另一方面也会对系统响应速度差生影响
  5. 参考网址:http://gityuan.com/2016/06/21/watchdog/
  1. 具体打印的trace信息有时间再研究一下格式

 

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值