Android 系统稳定性 - Watchdog

绝地灬酷狼 2022-06-05 12:37 258阅读 0赞

转载：[http://rayleeya.iteye.com/blog/1963408\#comments][http_rayleeya.iteye.com_blog_1963408_comments]

[【原创】Android 系统稳定性 - Watchdog][Android _ - Watchdog]

*  **博客分类：**
 *  [Android][]
 *  [移动开发][Link 1]

[Android][Android 1] [稳定性][Link 2] [Watchdog][] [重启][Link 3]

**文章都为原创，转载请注明出处，未经允许而盗用者追究法律责任。**

**很久之前写的了，留着有点浪费，共享之（文章没有完全写完）。**

**编写者：李文栋**

# 第3章 系统进程的Watchdog #

## **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的类图。

![点击查看原始大小图片][913c0f2b-059b-333d-80a2-fe224a6af310.png]

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之前，被监控服务对象只有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 \{

... ...

**case***MONITOR*: \{

... ...

**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的流程图

![点击查看原始大小图片][31030e42-88c2-3e6c-8a37-6a7726a3bff7.png]

[http_rayleeya.iteye.com_blog_1963408_comments]: http://rayleeya.iteye.com/blog/1963408#comments
[Android _ - Watchdog]: http://rayleeya.iteye.com/blog/1963408
[Android]: http://rayleeya.iteye.com/category/89044
[Link 1]: http://rayleeya.iteye.com/category/210664
[Android 1]: http://www.iteye.com/blogs/tag/Android
[Link 2]: http://www.iteye.com/blogs/tag/%E7%A8%B3%E5%AE%9A%E6%80%A7
[Watchdog]: http://www.iteye.com/blogs/tag/Watchdog
[Link 3]: http://www.iteye.com/blogs/tag/%E9%87%8D%E5%90%AF
[913c0f2b-059b-333d-80a2-fe224a6af310.png]: /images/20220605/5c46e1ef2b774cd38273d55b51f84f27.png
[31030e42-88c2-3e6c-8a37-6a7726a3bff7.png]: /images/20220605/746b918ad07e4d968f193450b0a8621d.png