编写者：李文栋 /rayleeya
http://rayleeya.iteye.com/blog/1963408
3.1 Watchdog简介
对于像笔者这样没玩过硬件的纯软程序员来说，第一次看到这个家伙的时候真心一头雾水，只是觉得这个名字很有意思。一番调查后发现，Watchdog机制最早来源于硬件，在计算机系统中，单片机的工作容易受到来自外界电磁场的干扰，而陷入死循环，系统无法继续工作，为了解决这个问题，便产生了一种专门用于监测单片机程序运行状态的芯片，俗称"看门狗"(Watchdog)。
“看门狗”本身是一个定时器电路，内部会不断的进行计时（或计数）操作。计算机系统和“看门狗”有两个引脚相连接，正常运行时每隔一段时间就会通过其中一个引脚向“看门狗”发送信号，“看门狗”接收到信号后会将计时器清零并重新开始计时。而一旦系统出现问题，进入死循环或任何阻塞状态，不能及时发送信号让“看门狗”的计时器清零，当计时结束时，“看门狗”就会通过另一个引脚向系统发送“复位信号”，让系统重启。
这样看来，向“看门狗”发送信号就像是“喂狗”，计时器就是“看门狗”的胃，当计时结束，狗饿了，就一口把系统咬死，让它重生。
软件上的看门狗技术的思想和影响类似，例如Linux自带的Watchdog。下面我们来看看Android系统进程的这条小狗吧。
3.2 系统进程的Watchdog
Android系统进程中的Watchdog（以下简称WD）自然是用来监测系统进程的，它和硬件上的WD有什么区别呢？系统进程中维护着大量的服务对象，其中有一些非常重要的对象，例如ActivityManagerService， WindowManagerService等，这些服务对象能够被正常访问对系统的运行来说至关重要，暂且称它们为关键对象。这些关键对象可能同时会被多个线程使用，所以需要在操作这些对象的地方使用同步锁将它们保护起来，确保对象状态的一致性。但是如果某个线程锁住关键对象后长时间没有释放锁，其他线程无法使用对象完成后续的任务，那么系统就会处于停滞状态无法运行，此时就需要让系统重启以恢复到一个正常的运行状态。检测这些关键服务对象是否被锁住，和重启系统的操作就是由WD完成的。
WD是如何完成这项神圣的使命的呢？我们先来了解一下WD的创建和启动，再来剖析它的结构和流程。
3.2.1 Watchdog初始化和启动
WD对象是一个单例，是在系统启动过程中的ServerThread线程中时创建的。
ServerThread.java → run()
Slog.i(TAG, "Init Watchdog");
Watchdog.getInstance().init(context, battery, power, alarm,
ActivityManagerService.self());
需要注意的是WD的构造方法，其内部创建了一个HeartbeatHandler类型的对象，后面会详细介绍它，不过可以肯定的是，这个Handler实例绑定了ServerThread线程的Looper。
Watchdog.java → Watchdog()
private Watchdog() {
super("watchdog");
mHandler = new HeartbeatHandler();
}
再看一下init方法具体做了什么。
Watchdog.java → init()
publicvoid init(Context context, BatteryService battery,
PowerManagerService power, AlarmManagerService alarm,
ActivityManagerService activity) {
//保存了几个要用到的服务对象
mResolver = context.getContentResolver();
mBattery = battery;
mPower = power;
mAlarm = alarm;
mActivity = activity;
//注册两个BroadcastReceiver，来接收重启的消息
context.registerReceiver(new RebootReceiver(),
new IntentFilter(REBOOT_ACTION));
mRebootIntent = PendingIntent.getBroadcast(context,
0, new Intent(REBOOT_ACTION), 0);
context.registerReceiver(new RebootRequestReceiver(),
new IntentFilter(Intent.ACTION_REBOOT),
android.Manifest.permission.REBOOT, null);
mBootTime = System.currentTimeMillis(); //记录启动时间
}
init方法很简单，涉及的内容后面会做介绍。
完成初始化后，WD还没有启动运行。看一下WD的类声明可以知道，它是Thread类的子类，可以想到WD是在自己的线程中实现“定时器”的功能的，这很合理，要实现类似于独立硬件完成的计时工作，用独立线程完成对所在进程的监控是再好不过的。启动WD线程是在ServerThread线程的最后阶段完成的。
ActivityManagerService.self().systemReady(new Runnable() {
publicvoid run() {
... ...
Watchdog.getInstance().start();
... ...
}
);
3.2.2 Watchdog结构剖析
为了描述方便，先给出WD的类图。
WD的结构还是比较简单的，下面我们分几个部分来分析。
1. Watchdog
WD的“定时器”的功能是在单独的线程中完成的，所以WD本身继承了Thread，如前面所说，它是在ActivityManagerService的systemReady方法中启动的。
2. HeartbeatHandler
Android系统进程的WD和硬件的“看门狗”的思想是一致的，但是实现方式上不同。WD线程在计时的过程中并不是被动的等待系统的“喂狗”信号，而是在每轮计时的开始向ServerThread（以下简称ST）线程发一个检测消息，ST接收到消息后开始遍历Monitor对象集合，尝试获取每个对象的锁，这个消息检测过程就是在HeartbeatHandler（以下简称“HH”）中实现的。需要注意的是，HH绑定的是ST线程，ST作为系统进程的主线程执行检测操作。
3. Monitor和被监控的服务对象
WD监控的是系统进程中几个关键的服务对象，对这类对象进行抽象定义，便有了Monitor接口，它只有一个monitor方法。WD对实现了此接口的对象进行监控，其内部有一个存放Monitor对象的集合，任何对象只要实现了Monitor接口，并且通过WD的addMonitor方法注册进集合即可被监控。
在GingerBread之前，被监控服务对象只<!-- 确认一下是否是从2.3开始的 -->有ActivityManagerService、WindowManagerService和PowerManagerService，在此之后又增加了4个，分别是NetworkManagementService、MountService、NativeDaemonConnector和InputManager。
Monitor接口的实现方法很简单，例如AMS的实现：
ActivityManagerService.java → monitor()
publicvoid monitor() {
synchronized (this) { }
}
可以看到所谓的“监控服务对象”，说白了就是对这些对象进行死锁检测，如果能够顺利的获得被监控对象的锁则认为系统运行正常，如果长时间没有获得则认为系统处于停滞状态，需要采取措施了。
4. RebootReceiver和RebootRequestReceiver
3.2.3 Watchdog工作流程
WD的工作流程主要就是WD线程和HH线程之间的交互，先从WD的run方法看起。
Watchdog.java → run()
publicvoid run() {
boolean waitedHalf = false;//?记录是否已经等待了一半
while (true) {
mCompleted = false;//用一个布尔变量标记是否完成死锁检测
//?向HH发送检测信号，它是在ST线程中执行的
mHandler.sendEmptyMessage(MONITOR);
synchronized (this) {
//发送检测信号后会等待检测操作完成，等待时间在正常运行的情况下是30秒
long timeout = TIME_TO_WAIT;
long start = SystemClock.uptimeMillis();
while (timeout > 0 && !mForceKillSystem) {
try {
wait(timeout);
... ...
}
. .. ...
通过以上代码可以知道，监控过程就是一个死循环，每次循环都会做一轮死锁检测。有两个需要注意的点，说明如下：
? WD的这个“定时器”每轮检测的超时时间是30秒，但是30秒超时后WD并不会马上重启系统，而是将waitedHalf设置为true，认为只是等待了一半的时间，也就是说WD想多给那个被锁住的对象一次机会，做两轮检测，如果仍然超时再杀也不晚。WD还是很有人情味的，后面会看到waitedHalf何时被设置为true的。
? 每轮的检测操作不是由WD线程自己完成的，而是发送一个消息给HH，由HH所绑定的ST线程完成。它是怎么做的呢？接下来转到HH一探究竟。
finalclass HeartbeatHandler extends Handler {
... ...
caseMONITOR: {
... ...
finalint size = mMonitors.size();
for (int i = 0 ; i < size ; i++) {
//记录下当前正在被检测的Monitor对象，这很重要
mCurrentMonitor = mMonitors.get(i);
mCurrentMonitor.monitor();//检测死锁
}
synchronized (Watchdog.this) {
mCompleted = true;//标记检测完成，WD线程会用此判断是否完成
mCurrentMonitor = null;
... ...
逻辑很简单，不多解释，只是请留意HH做完死锁检测后没有用notifyAll唤醒WD线程，所以正常情况下WD线程会在超时后再继续下一轮检测。HH比较会偷懒。
接下来又回到WD线程。
... ... //WD线程结束wait等待
if (mCompleted && !mForceKillSystem) {
//如果检测成功，则重置waitedHalf标记，继续下一轮检测
waitedHalf = false;
continue;
}
if (!waitedHalf) {
//执行到这里，说明检测过程阻塞了，没有完成，并且waitedHalf为false，说明
//这是死锁检测失败的第一轮检测。通过AMS将系统进程中各个线程的函数调用栈
//输出到/data/anr/traces.txt文件中，同时也会输出几个重要的native进程的
//backtrace，以便提供更多信息来定位问题，因为Java层的阻塞很有可能是native
//层的阻塞造成的。
ArrayList<Integer> pids = new ArrayList<Integer>();
pids.add(Process.myPid());
ActivityManagerService.dumpStackTraces(true, pids, null, null,
NATIVE_STACKS_OF_INTEREST);
waitedHalf = true;//设置为true，说明WD线程等了一轮了
continue;//再来一轮，给个机会
}
如果接下来的第二轮死锁检测仍然失败，则上述的代码就不会执行，继续往下走。
//此后便是为了能够方便分析死锁原因，而输出的各种类型的日志信息
final String name = (mCurrentMonitor != null) ?
mCurrentMonitor.getClass().getName() : "null";
//?记录正在执行死锁检测的对象
EventLog.writeEvent(EventLogTags.WATCHDOG, name);
//?再次输出系统进程的函数栈信息
ArrayList<Integer> pids = new ArrayList<Integer>();
pids.add(Process.myPid());
//同时输出com.android.phone进程的函数栈，因为电话系统对于手机来说是最重要的
//模块，自然要重点对待
if (mPhonePid > 0) pids.add(mPhonePid);
final File stack = ActivityManagerService.dumpStackTraces(
!waitedHalf, pids, null, null, NATIVE_STACKS_OF_INTEREST);
... ...
if (RECORD_KERNEL_THREADS) {
dumpKernelStackTraces();//输出一部分Kernel的信息帮助定位问题
}
... ...
//?在一个子线程中输出到DropBox中
mActivity.addErrorToDropBox(
"watchdog", null, "system_server", null, null,
name, null, stack, null);
... ...
//如果调试器没有链接则直接退出进程
if (!Debug.isDebuggerConnected()) {
Slog.w(TAG, "*** WATCHDOG KILLING SYSTEM PROCESS: " + name);
Process.killProcess(Process.myPid());
System.exit(10);
} else {//如果正在Debug，那你就可以断点调试了
... ...
有三个关键点需要注意：
? 记录正在执行死锁检测的对象，如果name为”null”，其实就相当于ServerThread线程还没有执行HH的handleMessage方法，就在其他地方阻塞了。所以要特别注意，如果在分析trace信息时发现没有因为被检测的关键服务对象而发生阻塞，那么就需要看看ServerThread线程的函数调用栈，确定真正的阻塞原因。
? 在进行系统重启前会做两轮死锁检测，第一轮会新建traces.txt文件，但第二轮会在原有文件的基础上续写，所以你会在trace信息中看到两次系统进程各个线程的函数调用栈信息。
? 在一个子线程中输出到DropBox中，所以如果这次保存在traces.txt中的死锁信息没有来得及查看就被覆盖了，那么可以到/data/system/dropbox目录下找到这次日志的备份。
Watchdog的实现说白了其实就是在一个线程中建立消息循环，通过Message和成员变量在线程间进行通讯，这和Handler机制的本质是一样的。
至此，WD的工作流程介绍完了，还算比较简单，在本章的最后附上了WD的流程图。接下来会介绍一些WD检测到死锁后导致重启的问题的分析方法，对于Android系统工程师来说，处理这类问题肯定是家常便饭了。
3.3 Watchdog引起的重启问题分析方法
3.3.1 被监测对象死锁
(待续)
3.3.2 ServerThread线程阻塞
(待续)
Watchdog的流程图
