一：为什么需要看门狗?
Watchdog,初次见到这个词语是在大学的单片机书上, 谈到了看门狗定时器. 在很早以前那个单片机刚发展的时候, 单片机容易受到外界工作影响, 导致自己的程序跑飞, 因此有了看门狗的保护机制, 即:需要每多少时间内都去喂狗, 如果不喂狗, 看门狗将触发重启. 大体原理是, 在系统运行以后启动了看门狗的计数器，看门狗就开始自动计数，如果到了一定的时间还不去清看门狗，那么看门狗计数器就会溢出从而引起看门狗中断，造成系统复位。
而手机, 其实是一个超强超强的单片机, 其运行速度比单片机快N倍, 存储空间比单片机大N倍, 里面运行了若干个线程, 各种软硬件协同工作, 不怕一万,就怕万一, 万一我们的系统死锁了, 万一我们的手机也受到很大的干扰程序跑飞了. 都可能发生jj思密达的事情, 因此, 我们也需要看门狗机制.
二：Android系统层看门狗
看门狗有硬件看门狗和软件看门狗之分, 硬件就是单片机那种的定时器电路, 软件, 则是我们自己实现一个类似机制的看门狗.Android系统为了保证系统的稳定性，也设计了这么一个看门狗，其为了保证各种系统服务能够正常工作，要监控很多的服务，并且在核心服务异常时要进行重启，还要保存现场。
接下来我们就看看Android系统的Watchdog是怎么设计的。
注：本文以Android6.0代码讲解
Android系统的Watchdog源码路径在此：frameworks/base/services/core/java/com/android/server/Watchdog.java
Watchdog的初始化位于SystemServer./frameworks/base/services/java/com/android/server/SystemServer.java
在SystemServer中会对Watchdog进行初始化。
492 Slog.i(TAG, "Init Watchdog");493 final Watchdog watchdog = Watchdog.getInstance();494 watchdog.init(context, mActivityManagerService);此时Watchdog会走如下初始化方法，先是构造方法，再是init方法：
216 private Watchdog() {217 super("watchdog");218 // Initialize handler checkers for each common thread we want to check. Note219 // that we are not currently checking the background thread, since it can220 // potentially hold longer running operations with no guarantees about the timeliness221 // of operations there.222223 // The shared foreground thread is the main checker. It is where we224 // will also dispatch monitor checks and do other work.225 mMonitorChecker = new HandlerChecker(FgThread.getHandler(),226 "foreground thread", DEFAULT_TIMEOUT);227 mHandlerCheckers.add(mMonitorChecker);228 // Add checker for main thread. We only do a quick check since there229 // can be UI running on the thread.230 mHandlerCheckers.add(new HandlerChecker(new Handler(Looper.getMainLooper()),231 "main thread", DEFAULT_TIMEOUT));232 // Add checker for shared UI thread.233 mHandlerCheckers.add(new HandlerChecker(UiThread.getHandler(),234 "ui thread", DEFAULT_TIMEOUT));235 // And also check IO thread.236 mHandlerCheckers.add(new HandlerChecker(IoThread.getHandler(),237 "i/o thread", DEFAULT_TIMEOUT));238 // And the display thread.239 mHandlerCheckers.add(new HandlerChecker(DisplayThread.getHandler(),240 "display thread", DEFAULT_TIMEOUT));241242 // Initialize monitor for Binder threads.243 addMonitor(new BinderThreadMonitor());244 }246 public void init(Context context, ActivityManagerService activity) {247 mResolver = context.getContentResolver();248 mActivity = activity;249 // 注册重启广播250 context.registerReceiver(new RebootRequestReceiver(),251 new IntentFilter(Intent.ACTION_REBOOT),252 android.Manifest.permission.REBOOT, null);253 }但是我们看了源码会知道，Watchdog这个类继承于Thread，所以还会需要一个启动的地方，就是下面这行代码，这是在ActivityManagerService的SystemReady接口中干的。
Watchdog.getInstance().start();
TAG: HandlerChecker
上面的代码中有个比较重要的类，HandlerChecker,这是Watchdog用来检测主线程，io线程，显示线程，UI线程的机制，代码也不长，直接贴出来吧。其原理就是通过各个Handler的looper的MessageQueue来判断该线程是否卡住了。当然，该线程是运行在SystemServer进程中的线程。
public final class HandlerChecker implements Runnable {88 private final Handler mHandler;89 private final String mName;90 private final long mWaitMax;91 private final ArrayList<Monitor> mMonitors = new ArrayList<Monitor>();92 private boolean mCompleted;93 private Monitor mCurrentMonitor;94 private long mStartTime;9596 HandlerChecker(Handler handler, String name, long waitMaxMillis) {97 mHandler = handler;98 mName = name;99 mWaitMax = waitMaxMillis;100 mCompleted = true;101 }102103 public void addMonitor(Monitor monitor) {104 mMonitors.add(monitor);105 }106 // 记录当前的开始时间107 public void scheduleCheckLocked() {108 if (mMonitors.size() == 0 && mHandler.getLooper().getQueue().isPolling()) {109 // If the target looper has recently been polling, then110 // there is no reason to enqueue our checker on it since that111 // is as good as it not being deadlocked. This avoid having112 // to do a context switch to check the thread. Note that we113 // only do this if mCheckReboot is false and we have no114 // monitors, since those would need to be executed at this point.115 mCompleted = true;116 return;117 }118119 if (!mCompleted) {120 // we already have a check in flight, so no need121 return;122 }123124 mCompleted = false;125 mCurrentMonitor = null;126 mStartTime = SystemClock.uptimeMillis();127 mHandler.postAtFrontOfQueue(this);128 }129130 public boolean isOverdueLocked() {131 return (!mCompleted) && (SystemClock.uptimeMillis() > mStartTime + mWaitMax);132 }133 // 获取完成时间标识134 public int getCompletionStateLocked() {135 if (mCompleted) {136 return COMPLETED;137 } else {138 long latency = SystemClock.uptimeMillis() - mStartTime;139 if (latency < mWaitMax/2) {140 return WAITING;141 } else if (latency < mWaitMax) {142 return WAITED_HALF;143 }144 }145 return OVERDUE;146 }147148 public Thread getThread() {149 return mHandler.getLooper().getThread();150 }151152 public String getName() {153 return mName;154 }155156 public String describeBlockedStateLocked() {157 if (mCurrentMonitor == null) {158 return "Blocked in handler on " + mName + " (" + getThread().getName() + ")";159 } else {160 return "Blocked in monitor " + mCurrentMonitor.getClass().getName()161 + " on " + mName + " (" + getThread().getName() + ")";162 }163 }164165 @Override166 public void run() {167 final int size = mMonitors.size();168 for (int i = 0 ; i < size ; i++) {169 synchronized (Watchdog.this) {170 mCurrentMonitor = mMonitors.get(i);171 }172 mCurrentMonitor.monitor();173 }174175 synchronized (Watchdog.this) {176 mCompleted = true;177 mCurrentMonitor = null;178 }179 }180 }通过上面的代码，我们可以看到一个核心的方法是
mHandler.getLooper().getQueue().isPolling()
这个方法的实现在MessageQueue中，我将代码贴出来，我们可以看到上面的注释写到：返回当前的looper线程是否在polling工作来做，这个是个很好的用于检测loop是否存活的方法。我们从HandlerChecker源码可以看到，如果looper这个返回true，将会直接返回。
150 public boolean isPolling() {151 synchronized (this) {152 return isPollingLocked();153 }154 }155若没有返回true，表明looper当前正在工作，会post一下自己，同时将mComplete置为false，标明已经发出一个消息正在等待处理。如果当前的looper没有阻塞，那很快，将会调用到自己的run方法。自己的run方法干了什么呢。干的是TAG: HandlerChecker源码里面的166行，里面对自己的Monitors遍历并进行monitor。（注：此处的monitor下面会讲到），若有monitor发生了阻塞，那么mComplete会一直是false。那么在系统检测调用这个获取完成状态时，就会进入else里面，进行了时间的计算，并返回相应的时间状态码。
133 // 获取完成时间标识134 public int getCompletionStateLocked() {135 if (mCompleted) {136 return COMPLETED;137 } else {138 long latency = SystemClock.uptimeMillis() - mStartTime;139 if (latency < mWaitMax/2) {140 return WAITING;141 } else if (latency < mWaitMax) {142 return WAITED_HALF;143 }144 }145 return OVERDUE;146 }好了，到这我们已经知道是怎么判断线程是否卡住的了
MessageQueue.isPolling
Monitor.monitor
TAG：Monitor
204 public interface Monitor {205 void monitor();206 }Monitor是一个接口，实现这个接口的类有好几个。比如：如下我搜出来的结果
看，有这么多的类实现了该接口，而且我们都不用去猜，就可以知道，他们一定会注册到这个Watchdog中。注册到哪的呢，下面代码可以看到。
225 mMonitorChecker = new HandlerChecker(FgThread.getHandler(),226 "foreground thread", DEFAULT_TIMEOUT);227 mHandlerCheckers.add(mMonitorChecker);275 public void addMonitor(Monitor monitor) {276 synchronized (this) {277 if (isAlive()) {278 throw new RuntimeException("Monitors can't be added once the Watchdog is running");279 }280 mMonitorChecker.addMonitor(monitor);281 }282 }所以各个实现这个接口的类，只需要调一下，上述接口就行了。我们看一下ActivityManagerService类的调法。路径在此，点击可以进入。 /frameworks/base/services/core/java/com/android/server/am/ActivityManagerService.java
2381 Watchdog.getInstance().addMonitor(this);19655 /** In this method we try to acquire our lock to make sure that we have not deadlocked */19656 public void monitor() {19657 synchronized (this) { }19658 }可以看到，我们的AMS实现了该接口，并在2381行，将自己注册进Watchdog. 同时其monitor方法只是同步一下自己，确保自己没有死锁。干的事情虽然不多，但这足够了。足够让外部通过这个方法得到AMS是否死了。
好了，现在我们知道是如何判断其他服务是否死锁了，那么看Watchdog的run方法是怎么完成这一套机制的吧。
TAG: Watchdog.run
run方法就是死循环，不断的去遍历所有HandlerChecker,并调其监控方法，等待三十秒，评估状态。具体见下面的注释：
341 @Override342 public void run() {343 boolean waitedHalf = false;344 while (true) {345 final ArrayList<HandlerChecker> blockedCheckers;346 final String subject;347 final boolean allowRestart;348 int debuggerWasConnected = 0;349 synchronized (this) {350 long timeout = CHECK_INTERVAL;351 // Make sure we (re)spin the checkers that have become idle within352 // this wait-and-check interval // 在这里，我们遍历所有HandlerChecker,并调其监控方法，记录开始时间353 for (int i=0; i<mHandlerCheckers.size(); i++) {354 HandlerChecker hc = mHandlerCheckers.get(i);355 hc.scheduleCheckLocked();356 }357358 if (debuggerWasConnected > 0) {359 debuggerWasConnected--;360 }361362 // NOTE: We use uptimeMillis() here because we do not want to increment the time we363 // wait while asleep. If the device is asleep then the thing that we are waiting364 // to timeout on is asleep as well and won't have a chance to run, causing a false365 // positive on when to kill things.366 long start = SystemClock.uptimeMillis(); // 等待30秒，使用uptimeMills是为了不把手机睡眠时间算进入，手机睡眠时系统服务同样睡眠367 while (timeout > 0) {368 if (Debug.isDebuggerConnected()) {369 debuggerWasConnected = 2;370 }371 try {372 wait(timeout);373 } catch (InterruptedException e) {374 Log.wtf(TAG, e);375 }376 if (Debug.isDebuggerConnected()) {377 debuggerWasConnected = 2;378 }379 timeout = CHECK_INTERVAL - (SystemClock.uptimeMillis() - start);380 }381 // 评估Checker的状态，里面会遍历所有的HandlerChecker,并获取最大的返回值。382 final int waitState = evaluateCheckerCompletionLocked(); // 最大的返回值有四种情况，分别是：COMPLETED对应消息已处理完毕线程无阻塞383 if (waitState == COMPLETED) {384 // The monitors have returned; reset385 waitedHalf = false;386 continue; // WAITING对应消息处理花费0～29秒,继续运行387 } else if (waitState == WAITING) {388 // still waiting but within their configured intervals; back off and recheck389 continue; // WAITED_HALF对应消息处理花费30～59秒，线程可能已经被阻塞，需要保存当前AMS堆栈状态390 } else if (waitState == WAITED_HALF) {391 if (!waitedHalf) {392 // We've waited half the deadlock-detection interval. Pull a stack393 // trace and wait another half.394 ArrayList<Integer> pids = new ArrayList<Integer>();395 pids.add(Process.myPid());396 ActivityManagerService.dumpStackTraces(true, pids, null, null,397 NATIVE_STACKS_OF_INTEREST);398 waitedHalf = true;399 }400 continue;401 }402 //OVERDUE对应消息处理已经花费超过60, 能够走到这里，说明已经发生了超时60秒了。那么下面接下来全是应对超时的情况403 // something is overdue!404 blockedCheckers = getBlockedCheckersLocked();405 subject = describeCheckersLocked(blockedCheckers);406 allowRestart = mAllowRestart;407 }408409 // If we got here, that means that the system is most likely hung.410 // First collect stack traces from all threads of the system process.411 // Then kill this process so that the system will restart.412 EventLog.writeEvent(EventLogTags.WATCHDOG, subject);413 .......各种记录的保存468469 // Only kill the process if the debugger is not attached.470 if (Debug.isDebuggerConnected()) {471 debuggerWasConnected = 2;472 }473 if (debuggerWasConnected >= 2) {474 Slog.w(TAG, "Debugger connected: Watchdog is *not* killing the system process");475 } else if (debuggerWasConnected > 0) {476 Slog.w(TAG, "Debugger was connected: Watchdog is *not* killing the system process");477 } else if (!allowRestart) {478 Slog.w(TAG, "Restart not allowed: Watchdog is *not* killing the system process");479 } else {480 Slog.w(TAG, "*** WATCHDOG KILLING SYSTEM PROCESS: " + subject);481 for (int i=0; i<blockedCheckers.size(); i++) {482 Slog.w(TAG, blockedCheckers.get(i).getName() + " stack trace:");483 StackTraceElement[] stackTrace484 = blockedCheckers.get(i).getThread().getStackTrace();485 for (StackTraceElement element: stackTrace) {486 Slog.w(TAG, " at " + element);487 }488 }489 Slog.w(TAG, "*** GOODBYE!");490 Process.killProcess(Process.myPid());491 System.exit(10);492 }493494 waitedHalf = false;495 }496 }上述可以看到， 如果走到412行处。便是重启系统前的准备了。会进行以下事情：
写Eventlog
以追加的方式，输出system_server和3个native进程的栈信息
输出kernel栈信息
dump所有阻塞线程
输出dropbox信息
判断有没有debuger，没有的话，重启系统了，并输出log： *** WATCHDOG KILLING SYSTEM PROCESS:
三:总结：
以上便是Android系统层Watchdog的原理了。设计的比较好。若由我来设计，我还真想不到使用Monitor那个锁机制来判断。接下来总结以下：
Watchdog是一个线程，用来监听系统各项服务是否正常运行，没有发生死锁
HandlerChecker用来检查Handler以及monitor
monitor通过锁来判断是否死锁
超时30秒会输出log，超时60秒会重启（debug情况除外）
作者 | Anderson大码渣
地址 | https://www.jianshu.com/p/5c18c4e8c826
声明 | 本文是 Anderson大码渣 原创，已获授权发布，未经原作者允许请勿转载
