systemserver watchdog

本文介绍了Android系统中Watchdog机制的工作原理及作用。为避免核心服务挂起导致系统冻结,通过MonitorChecker和LooperChecker监测对象锁及线程消息队列的状态,确保系统稳定运行。

watchdog 即看门狗,用来监测系统是否发生了死锁,无响应等问题。要定时喂狗,不及时喂狗认为此时系统发生了blcok。

android系统的核心服务都跑在systemserver进程中,为了防止核心服务hang住而发生冻屏,systemserver中引入了Watchdog机制,当出现故障时,Watchdog触发杀死systemserver进程,实现软重启进行系统自恢复。

systemserver中的watchdog监测的对象主要分为两类,一个是对象锁,一个是线程的handler:

  • Monitor Checker,用于检查AMS, PKMS, WMS等系统服务的对象锁是否有长时间被持锁情况。Monitor Checker预警我们不能长时间持有核心系统服务的对象锁,否则会阻塞很多函数的运行;

  • Looper Checker,用于检查线程的消息队列是否长时间处于工作状态。Looper Checker预警我们不能长时间的霸占消息队列,否则其他消息将得不到处理。

watchdog原理:

systemsever在启动过程中初始化watchdog,启动watchdog线程。watchdog线程周期的(30s)给注册的handler发送runnable,30s内runnable执行返回,认为正常,runnable没有得到执行,出示黄牌警告,打印back tace。如果1分钟之内未得到执行,认为发生异常,出示红牌,打印backtrack,并杀死systemserver进程。Monitor Checker原理类似,运行在公共的fg线程中,30s未得到对象锁,黄牌警告,1分钟未得到对象锁红牌罚下。

09-26 00:13:05.596684 11552 14103 I System.out: [2025-09-26 00:11:32][108s]systemserver watchdog;Blocked in handler on main thread (main) for 69s "main" prio=5 tid=1 Native | group="main" sCount=1 ucsCount=0 flags=1 obj=0xabfb1498 self=0xb400007bf9754c00 | sysTid=3198 nice=-15 cgrp=ssfg sched=0/0 handle=0x7cb3ca5098 | state=S schedstat=( 12537244964 10403906075 110671 ) utm=585 stm=668 core=5 HZ=100 | stack=0x7ff6e34000-0x7ff6e36000 stackSize=8188KB | held mutexes= native: #00 pc 000abbe0 /apex/com.android.runtime/lib64/bionic/libc.so (syscall+32) (BuildId: 5925c7f342dab0dd7afa6a6b853e866c) native: #01 pc 004b144c /apex/com.android.art/lib64/libart.so (art::ConditionVariable::WaitHoldingLocksWithInfo+232) (BuildId: 31bbe8b63de8ef744f0a070fc4aa608c) native: #02 pc 00cfb700 /apex/com.android.art/lib64/libart.so (artJniMethodEnd+360) (BuildId: 31bbe8b63de8ef744f0a070fc4aa608c) native: #03 pc 0085cb8c /apex/com.android.art/lib64/libart.so (art_jni_method_end+12) (BuildId: 31bbe8b63de8ef744f0a070fc4aa608c) at android.os.HwRemoteBinder.transact(Native method) at android.hardware.soundtrigger.V2_3.ISoundTriggerHw$Proxy.interfaceChain(ISoundTriggerHw.java:703) at android.hardware.soundtrigger.V2_3.ISoundTriggerHw.asInterface(ISoundTriggerHw.java:31) at com.android.server.soundtrigger_middleware.SoundTriggerHw2Compat.initUnderlying(SoundTriggerHw2Compat.java:123) at com.android.server.soundtrigger_middleware.SoundTriggerHw2Compat.<init>(SoundTriggerHw2Compat.java:112) at com.android.server.soundtrigger_middleware.SoundTriggerHw2Compat.create(SoundTriggerHw2Compat.java:98) at com.android.server.soundtrigger_middleware.SoundTriggerHw2Compat.create(SoundTriggerHw2Compat.java:92) at com.android.server.soundtrigger_middleware.DefaultHalFactory.create(DefaultHalFactory.java:80) at com.android.server.soundtrigger_middleware.SoundTriggerModule.attachToHal(SoundTriggerModule.java:187) at com.android.server.soundtrigger_middleware.SoundTriggerModule.<init>(SoundTriggerModule.java:113) at com.android.server.soundtrigger_middleware.SoundTriggerMiddlewareImpl.<init>(SoundTriggerMiddlewareImpl.java:86) at com.android.server.soundtrigger_middleware.SoundTriggerMiddlewareService$Lifecycle.onStart(SoundTriggerMiddlewareService.java:248) at com.android.server.SystemServiceManager.startService(SystemServiceManager.java:286) at com.android.server.SystemServiceManager.startService(SystemServiceManager.java:263) at com.android.server.SystemServer.startOtherServices(SystemServer.java:2673) at com.android.server.SystemServer.run(SystemServer.java:1074) at com.android.server.SystemServer.main(SystemServer.java:709) at java.lang.reflect.Method.invoke(Native method) at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:613) at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1052) DumpLatencyMs: 0.364479这份堆栈打印可以分析出什么,此时还有transact()函数的打印,那么此时binder通信结束没,怎么判断的
09-29
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值