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

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

很久之前写的了,留着有点浪费,共享之(文章没有完全写完)。 

编写者:李文栋 

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


【原创】Android 系统稳定性 - Watchdog_第1张图片
 

        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 {

        ... ...

        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 pids = new ArrayList();

                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 pids = new ArrayList();

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


【原创】Android 系统稳定性 - Watchdog_第2张图片
 

你可能感兴趣的:(Android,移动开发)