当前位置: 开发笔记 > Android > 正文

通过Androidtrace文件分析死锁ANR实例过程

作者：汤侑亦_473 | 来源：互联网 | 2021-11-03 18:58

遇到ANR(ApplicationNotResponding)是比较常见的问题，产生ANR的原因有很多，比如CPU使用过高、事件没有得到及时的响应、死锁等，下面将通过一次因为死锁导致的ANR问题，来说明如何通过trace文件分析ANR问题

对于从事Android开发的人来说，遇到ANR(Application Not Responding)是比较常见的问题。一般情况下，如果有ANR发生，系统都会在/data/anr/目录下生成trace文件，通过分析trace文件，可以定位产生ANR的原因。产生ANR的原因有很多，比如CPU使用过高、事件没有得到及时的响应、死锁等，下面将通过一次因为死锁导致的ANR问题，来说明如何通过trace文件分析ANR问题。

对应的部分trace文件内容如下：
"PowerManagerService" prio=5 tid=24 MONITOR
| group="main" sCount=1 dsCount=0 obj=0x41dd0eb0 self=0x5241b218
| sysTid=567 nice=0 sched=0/0 cgrp=apps handle=1380038664
| state=S schedstat=( 6682116007 11324451214 33313 ) utm=450 stm=219 core=1
at com.android.server.am.ActivityManagerService.broadcastIntent(ActivityManagerService.java:~13045)
- waiting to lock <0x41a874a0> (a com.android.server.am.ActivityManagerService) held by tid=12 (android.server.ServerThread)
at android.app.ContextImpl.sendBroadcast(ContextImpl.java:1144)
at com.android.server.power.PowerManagerService$DisplayBlankerImpl.unblankAllDisplays(PowerManagerService.java:3442)
at com.android.server.power.DisplayPowerState$PhotonicModulator$1.run(DisplayPowerState.java:456)
at android.os.Handler.handleCallback(Handler.java:800)
at android.os.Handler.dispatchMessage(Handler.java:100)
at android.os.Looper.loop(Looper.java:194)
at android.os.HandlerThread.run(HandlerThread.java:60)
"Binder_B" prio=5 tid=85 MONITOR
| group="main" sCount=1 dsCount=0 obj=0x42744770 self=0x58329e88
| sysTid=3700 nice=-20 sched=0/0 cgrp=apps handle=1471424616
| state=S schedstat=( 1663727513 2044643318 6806 ) utm=132 stm=34 core=1
at com.android.server.power.PowerManagerService$DisplayBlankerImpl.toString(PowerManagerService.java:~3449)
- waiting to lock <0x41a7e420> (a com.android.server.power.PowerManagerService$DisplayBlankerImpl) held by tid=24 (PowerManagerService)
at java.lang.StringBuilder.append(StringBuilder.java:202)
at com.android.server.power.PowerManagerService.dump(PowerManagerService.java:3052)
at android.os.Binder.dump(Binder.java:264)
at android.os.Binder.onTransact(Binder.java:236)
at android.os.IPowerManager$Stub.onTransact(IPowerManager.java:373)
at android.os.Binder.execTransact(Binder.java:351)
at dalvik.system.NativeStart.run(Native Method)
"android.server.ServerThread" prio=5 tid=12 MONITOR
| group="main" sCount=1 dsCount=0 obj=0x41a76178 self=0x507837a8
| sysTid=545 nice=-2 sched=0/0 cgrp=apps handle=1349936616
| state=S schedstat=( 15368096286 21707846934 69485 ) utm=1226 stm=310 core=0
at com.android.server.power.PowerManagerService.isScreenOnInternal(PowerManagerService.java:~2529)
- waiting to lock <0x41a7e2e8> (a java.lang.Object) held by tid=85 (Binder_B)
at com.android.server.power.PowerManagerService.isScreenOn(PowerManagerService.java:2522)
at com.android.server.wm.WindowManagerService.sendScreenStatusToClientsLocked(WindowManagerService.java:7749)
at com.android.server.wm.WindowManagerService.setEventDispatching(WindowManagerService.java:7628)
at com.android.server.am.ActivityManagerService.updateEventDispatchingLocked(ActivityManagerService.java:8083)
at com.android.server.am.ActivityManagerService.wakingUp(ActivityManagerService.java:8077)
at com.android.server.power.Notifier.sendWakeUpBroadcast(Notifier.java:474)
at com.android.server.power.Notifier.sendNextBroadcast(Notifier.java:455)
at com.android.server.power.Notifier.access$700(Notifier.java:62)
at com.android.server.power.Notifier$NotifierHandler.handleMessage(Notifier.java:600)
at android.os.Handler.dispatchMessage(Handler.java:107)
at android.os.Looper.loop(Looper.java:194)
at com.android.server.ServerThread.run(SystemServer.java:1328)
从trace文件看，是因为TID为24的线程等待一个TID为12的线程持有的锁，TID为12的线程等待一个TID为85的线程持有的锁，而TID为85的线程确等待一个TID为24的线程持有的锁，导致了循环等待的现象，对应的trace文件的语句如下：
TID 24：- waiting to lock <0x41a874a0> (a com.android.server.am.ActivityManagerService) held by tid=12 (android.server.ServerThread)
TID 12： - waiting to lock <0x41a7e2e8> (a java.lang.Object) held by tid=85 (Binder_B)
TID 85：- waiting to lock <0x41a7e420> (a com.android.server.power.PowerManagerService$DisplayBlankerImpl) held by tid=24 (PowerManagerService)
既然是死锁，那么先看各线程都有那些锁。
先看TID=24的线程的栈顶，ActivityManagerService的broadcastIntent函数代码如下:

代码如下:

 
public final int broadcastIntent(IApplicationThread caller, 
Intent intent, String resolvedType, IIntentReceiver resultTo, 
int resultCode, String resultData, Bundle map, 
String requiredPermission, boolean serialized, boolean sticky, int userId) { 
enforceNotIsolatedCaller("broadcastIntent"); 
synchronized(this) { 
intent = verifyBroadcastLocked(intent); 
final ProcessRecord callerApp = getRecordForAppLocked(caller); 
final int callingPid = Binder.getCallingPid(); 
final int callingUid = Binder.getCallingUid(); 
final long origId = Binder.clearCallingIdentity(); 
int res = broadcastIntentLocked(callerApp, 
callerApp != null ? callerApp.info.packageName : null, 
intent, resolvedType, resultTo, 
resultCode, resultData, map, requiredPermission, serialized, sticky, 
callingPid, callingUid, userId); 
Binder.restoreCallingIdentity(origId); 
return res; 
} 

可以看到TID=24需要ActivityManagerService这个锁。再看TID=12线程的栈顶，PowerManagerService的isScreenOnInternal函数代码如下：

代码如下:

 
private boolean isScreenOnInternal() { 
synchronized (mLock) { 
return !mSystemReady 
|| mDisplayPowerRequest.screenState != DisplayPowerRequest.SCREEN_STATE_OFF; 
} 
} 

可以看到需要PowerManagerService的mlock这个锁。最后看TID=85线程的栈顶，同样在PowerManagerService里面，内部类DisplayBlankerImpl的toString函数：

代码如下:

 
public String toString() { 
synchronized (this) { 
return "blanked=" + mBlanked; 
} 
} 

这是在内部类DisplayBlankerImpl里面实现的，所以需要DisplayBlankerImpl这个锁。
对应的表格如下：

表一各线程等待的锁情况
从表一来看，没有出现死锁现象，似乎并不是我们所想的那样。难道不是死锁？开始有点小怀疑自己了，难道别的原因导致的。也许只看调用堆栈的顶端可能不行，栈顶只能看出各线程需要的锁，不能仅看自己要什么吧！一味索取可不好！人不是这样做的！看一下整个的堆栈调用流程，看看自己拥有了那些锁。
跟踪TID=24线程的堆栈，在PowerManagerService内部类DisplayBlankerImpl的unblankAllDisplays函数中持有锁：

代码如下:

 
public void unblankAllDisplays() { 
synchronized (this) { 
nativeSetAutoSuspend(false); 
nativeSetInteractive(true); 
mDisplayManagerService.unblankAllDisplaysFromPowerManager(); 
mBlanked = false; 
///M: add for tvout and hdmi 
mTvOut.tvoutPowerEnable(true); 
mHDMI.hdmiPowerEnable(true); 
///@} 
if (DEBUG) { 
Slog.d(TAG_P, "unblankAllDisplays out ..."); 
} 
if (mBootCompleted) { 
Intent intent = new Intent(ACTION_LOCK_SCREEN_SHOW); 
mContext.sendBroadcast(intent); 
} 
} 
} 

最后发送广播的代码，是我们自己添加的。根据unblankAllDisplays函数和broadcastIntent函数，可以看到TID=24的线程此时持有了DisplayBlankerImpl锁(unblankAllDisplays)，等待ActivityManagerService锁(broadcastIntent)释放。
同样，跟踪TID=12线程的堆栈，在ActivityManagerService的wake_up函数中持有锁：

代码如下:

 
public void wakingUp() { 
if (checkCallingPermission(android.Manifest.permission.DEVICE_POWER) 
!= PackageManager.PERMISSION_GRANTED) { 
throw new SecurityException("Requires permission " 
+ android.Manifest.permission.DEVICE_POWER); 
} 
synchronized(this) { 
Slog.i(TAG, "wakingUp"); 
mWentToSleep = false; 
updateEventDispatchingLocked(); 
comeOutOfSleepIfNeededLocked(); 
} 
} 

根据wakingUp函数和isScreenOnInternal函数，可以看到TID=12的线程持有ActivityManagerService锁(wakingUp)，等待PowerManagerService.mLock锁(isScreenOnInternal)。到这，似乎看到了希望，迷雾要拨开了，有点小自信是死锁导致的，但还不能最终下结论。
一鼓作气，跟踪TID=85线程的堆栈，在PowerManagerService的dump有持有锁的操作：
protected void dump(FileDescriptor fd, PrintWriter pw, String[] args) {
....
synchronized (mLock) {
...
}
根据toString函数和dump函数，可以看到TID=85线程此时持有PowerManagerService.mLock锁(dump)，需要DisplayBlankerImpl(toString)。
似乎谜底已经揭晓了，如果你还没有看出来（其实我也没看出来），来个表看看吧！

表二各线程锁的情况
清楚了吗？多么清晰的循环等待呀！死锁都死的这么完美，还是图表效果好，看来有时候在纸上画画还是有用的！

android

推荐阅读

android
国内BI工具迎战国际巨头Tableau，稳步崛起

尽管商业智能（BI）工具在中国的普及程度尚不及国际市场，但近年来，随着本土企业的持续创新和市场推广，国内主流BI工具正逐渐崭露头角。面对国际品牌如Tableau的强大竞争，国内BI工具通过不断优化产品和技术，赢得了越来越多用户的认可。 ... [详细]

蜡笔小新 2024-12-28 11:12:44
java
优化ListView性能

本文深入探讨了如何通过多种技术手段优化ListView的性能，包括视图复用、ViewHolder模式、分批加载数据、图片优化及内存管理等。这些方法能够显著提升应用的响应速度和用户体验。 ... [详细]

蜡笔小新 2024-12-28 10:36:30
android
如何在剪映中进行视频镜像处理

本文将详细介绍如何使用剪映应用中的镜像功能，帮助用户轻松实现视频的镜像效果。通过简单的步骤，您可以快速掌握这一实用技巧。 ... [详细]

蜡笔小新 2024-12-27 18:56:09
java
深入理解Cookie与Session会话管理

本文详细介绍了如何通过HTTP响应和请求处理浏览器的Cookie信息，以及如何创建、设置和管理Cookie。同时探讨了会话跟踪技术中的Session机制，解释其原理及应用场景。 ... [详细]

蜡笔小新 2024-12-27 18:20:43
android
Xcode 中多行代码缩进技巧

本文介绍如何在 Xcode 中使用快捷键和菜单命令对多行代码进行缩进，包括右缩进和左缩进的具体操作方法。 ... [详细]

蜡笔小新 2024-12-27 17:52:34
android
Linux 自动化安装脚本详解

本文介绍了一款用于自动化部署 Linux 服务的 Bash 脚本。该脚本不仅涵盖了基本的文件复制和目录创建，还处理了系统服务的配置和启动，确保在多种 Linux 发行版上都能顺利运行。 ... [详细]

蜡笔小新 2024-12-27 16:33:32
android
在Linux系统中配置并启动ActiveMQ

本文详细介绍了如何在Linux环境中安装和配置ActiveMQ，包括端口开放及防火墙设置。通过本文，您可以掌握完整的ActiveMQ部署流程，确保其在网络环境中正常运行。 ... [详细]

蜡笔小新 2024-12-27 14:38:54
java
Android 渐变圆环加载控件实现

本文介绍了如何在 Android 中创建一个自定义的渐变圆环加载控件，该控件已在多个知名应用中使用。我们将详细探讨其工作原理和实现方法。 ... [详细]

蜡笔小新 2024-12-27 13:34:19
android
如何在WPS Office for Mac中调整Word文档的文字排列方向

本文将详细介绍如何使用最新版WPS Office for Mac调整Word文档中的文字排列方向。通过这些步骤，用户可以轻松更改文本的水平或垂直排列方式，以满足不同的排版需求。 ... [详细]

蜡笔小新 2024-12-27 12:34:14
apk
Ionic 5 APK打包与QRScanner插件优化：常见问题及解决方案

本文总结了在使用Ionic 5进行Android平台APK打包时遇到的问题，特别是针对QRScanner插件的改造。通过详细分析和提供具体的解决方法，帮助开发者顺利打包并优化应用性能。 ... [详细]

蜡笔小新 2024-12-27 12:10:17
android
存储器层次结构、随机访问存储器与数据存取机制

理解存储器的层次结构有助于程序员优化程序性能，通过合理安排数据在不同层级的存储位置，提升CPU的数据访问速度。本文详细探讨了静态随机访问存储器（SRAM）和动态随机访问存储器（DRAM）的工作原理及其应用场景，并介绍了存储器模块中的数据存取过程及局部性原理。 ... [详细]

蜡笔小新 2024-12-27 12:06:47
apk
360SRC安全应急响应：从漏洞提交到修复的全过程

本文详细介绍了360SRC平台处理一起关键安全事件的过程，涵盖从漏洞提交、验证、排查到最终修复的各个环节。通过这一案例，展示了360在安全应急响应方面的专业能力和严谨态度。 ... [详细]

蜡笔小新 2024-12-27 11:10:05
android
几何画板展示电场线与等势面的交互关系

几何画板是一款功能强大的物理教学软件，具备丰富的绘图和度量工具。它不仅能够模拟物理实验过程，还能通过定量分析揭示物理现象背后的规律，尤其适用于难以在实际实验中展示的内容。本文将介绍如何使用几何画板演示电场线与等势面之间的关系。 ... [详细]

蜡笔小新 2024-12-27 10:46:07
java
使用Windows批处理脚本监控并重启Java应用程序

本文介绍如何通过Windows批处理脚本定期检查并重启Java应用程序，确保其持续稳定运行。脚本每30分钟检查一次，并在需要时重启Java程序。同时，它会将任务结果发送到Redis。 ... [详细]

蜡笔小新 2024-12-27 10:44:39
android
MySQL中枚举类型的所有可能值获取方法

本文介绍了一种在MySQL数据库中查询枚举（ENUM）类型字段所有可能取值的方法，帮助开发者更好地理解和利用这一数据类型。 ... [详细]

蜡笔小新 2024-12-27 10:36:44

汤侑亦_473

这个家伙很懒，什么也没留下！

Tags | 热门标签

RankList | 热门文章