最佳实践｜一文讲解端线程死循环的治理

阿里妹导读

本文旨在介绍钉钉 Android 团队死循环检测工具建设的思路和典型案例的修复历程。希望通过此次分享，对同样面临类似死循环问题的团队能够有所启发。

引言

钉钉作为一个用户数超 7 亿，服务企业与组织数超过了 2500 万的企业级智能办公平台，终端团队一直将打造极致用户体验作为我们的理念。对于 Android 设备来说，线程死循环问题可能会导致高耗电，界面卡顿，耗尽内存等性能问题。与此同时，死循环问题还具有隐蔽性高，黑盒测试无法感知的特点。针对潜在的线程死循环风险我们进行了专项的治理优化。

术语表

线程死循环检测机制

线程死循环检测是一项复杂的任务。死循环可以在代码的任何地方发生，从简单的逻辑错误到复杂的系统原因，均可能会导致死循环。因此检测并诊断此类问题相当困难。

钉钉自研的 ANRCanary 监控工具，基于死循环线程高 CPU 占用和堆栈相似的两个特点，实现了精准的死循环检测能力。

获取线程 CPU 占用比

通过读取 Android 系统 proc 目录下面的 stat 文件可以获取进程和线程的 CPU 耗时，如下所示：

进程的 stat 信息

进程 ID 为：11162
进程用户态 CPU 耗时 101，内核态 CPU 耗时 51 。
对于死循环来说，CPU 的占用主要体现在用户态，所以我们只关注用户态的 CPU 占用比就好。

主线程的 stat 信息

主线程的线程 ID 为 11162，与进程 ID 相同。
主线程用户态 CPU 耗时 12，内核态 CPU 耗时 8 。则主线程用户态 CPU 占用比为：12 / 101 = 12%

子线程 Jit thread pool 的 stat 信息

子线程的线程 ID 为：11168，与进程 ID 不相同。
子线程用户态和内核态 CPU 耗时均为 0 ，则该子线程用户态 CPU 占用比为：0% 。

如果想计算一段时间区域内的各线程 CPU 占用比，只需要根据进程和线程的 CPU 耗时差值，计算即可得出。

通常可以将 CPU 占用比超过 10% 的线程标记为高耗时线程。

堆栈比较方案

死循环线程还有一个特点就是当出现一个循环点时，线程堆栈的底部是永远相同的。

以查询历史数据过多的数据库而导致死循环的案例堆栈为例：

如上图所示，针对该线程在一定时间间隔内抓的三个堆栈，可以发现堆栈的相似度很高，则可以将其作为死循环的重点怀疑对象。

CPU 占用和堆栈比较相结合

起因

CPU 占用方案：基于 stat 文件可以知道一个线程占了比较高的 CPU ，但是有效信息只有线程名，对应不上代码，因此很难分析出耗 CPU 的根因。

堆栈比较方案：能够拿到堆栈信息，但是当线程发生阻塞时（比如读 IO 或跨进程通信），堆栈相似度也很高，因此误报率比较高。

因此唯有将两个方案结合起来，才能比较准确地拿到高 CPU 占用线程的堆栈信息，从而大大提高检测结果的可分析性。

结合方案

结合的关键点为：线程名。因为两个方案输出的信息均包含线程名，因此可以用线程名进行关联匹配。

如上图所示，完整版本的死循环线程检测机制详细说明如下：

首先是线程 CPU 占用比获取阶段

先基于 stat 文件获取进程和线程的 CPU 耗时。
等待一段时间后，再次抓取进程和线程 CPU 耗时。
计算所有线程的 CPU 耗时，超过阈值，则认为属于高 CPU 线程。如果没有这类线程，则结束检测流程。
保存所有的高 CPU 线程的相关信息，留给下一个阶段使用。

其次是堆栈比较阶段

获取所有的 Java 线程对象列表，并进行遍历。
先对 Java 线程进行高 CPU 线程名匹配，如果匹配不中，不会进行堆栈比较，直接移除。
在一定时间内，针对剩余线程连续抓几次堆栈进行堆栈比较，堆栈相似度低于阈值的线程会被移除。

最后是输出检测结果通过筛选的线程就是疑似发生死循环的线程。

将 CPU 占用比信息与线程堆栈信息合并之后，输出检测结果。

实际案例分享

钉钉团队将以上解决方案整合进 ANRCanary 组件，完成线程死循环检测能力的建设。下文将通过几个典型案例，介绍钉钉在线程死循环问题治理上取得的收益。

案例 1：多线程操作 HashMap 线程死循环

本案例涉及 Java 中一个经典的死循环问题，即在多线程环境中操作 HashMap 有可能触发无限循环的情况。

ANRCanary 抓到的上报信息如下：


{  "case:1420548922":{    "name":"DThread-2",    "threadCPURate":0.*,    "threadStackList":[      "java.util.HashMap.put(HashMap.java:425)",      "fde.f(SourceFile:299)",      "iwx$1.doAfter(SourceFile:57)",      "prw.parseData(SourceFile:23)",      "prv.a(SourceFile:18)",      "pru$1.run(SourceFile:56)",      "com.***.threadpool.TaskRunner.call(SourceFile:750)",      "java.lang.Thread.run(Thread.java:762)"    ]  },  "case:1961205280":{    "name":"DThread-19",    "threadCPURate":0.*,    "threadStackList":[      "java.util.HashMap.put(HashMap.java:425)",      "fde.f(SourceFile:299)",      "iwx$1.doAfter(SourceFile:57)",      "prw.parseData(SourceFile:23)",      "psc.a(SourceFile:342)",      "com.***.im.cl.a(SourceFile:100)",      "prz.query(SourceFile:2628)",      "psh$12.onExecuteRpc(SourceFile:244)",      "pri$1.run(SourceFile:143)",      "com.***.threadpool.TaskRunner.call(SourceFile:750)",      "java.lang.Thread.run(Thread.java:762)"    ]  }}

从死循环信息来看：

两个线程堆栈均为高 CPU 线程，且最后都是在操作 HashMap。很明显是踩到了 HashMap 多线程不安全的这个坑。
将对应 HashMap 的使用改为 ConcurrentHashMap 之后，该问题得到解决。

案例 2：Lottie 动画后台未停止导致高 CPU 消耗

ANRCanary 抓到的上报信息如下：


"case:-1056518995":{  "name":"main",  "threadCPURate":0.*,  "threadStackList":[        "com.airbnb.lottie.LottieAnimationView.invalidateDrawable(SourceFile:189)",    "com.airbnb.lottie.LottieDrawable.invalidateSelf(SourceFile:261)",    "lb.onValueChanged(SourceFile:100)",        "com.airbnb.lottie.animation.keyframe.BaseKeyframeAnimation.b(SourceFile:60)",    "nj.a(SourceFile:427)",      "com.airbnb.lottie.LottieDrawable$1.onAnimationUpdate(SourceFile:103)",    "pb.c(SourceFile:88)",    "pd.doFrame(SourceFile:96)",    "android.view.Choreographer$CallbackRecord.run(Choreographer.java:785)",    "android.view.Choreographer.doFrame(Choreographer.java:568)",    "android.os.Handler.dispatchMessage(Handler.java:95)",    "android.os.Looper.loop(Looper.java:136)",    "android.app.ActivityThread.main(ActivityThread.java:5336)",    "com.android.internal.os.ZygoteInit.main(ZygoteInit.java:689)"  ]}

从死循环信息来看：

发生死循环的是主线程。
主线程相对于整个 APP 进程，CPU 占用量很高。
从堆栈看是因为 Lottie 动画导致的。
经过本地验证发现确实存在切换到后台 Lottie 依然在执行动画的问题。
原因是因为钉钉使用的 Lottie 版本太低导致，升级 Lottie 版本之后该问题得到解决。

案例 3：属性动画泄露导致高 CPU 消耗

初步分析

ANRCanary 抓到的上报信息如下：


"case:-647468375":{  "name":"main",  "threadCPURate":0.*,  "threadStackList":[    "android.graphics.drawable.LayerDrawable.setAlpha(LayerDrawable.java:1364)",    "android.animation.ObjectAnimator.animateValue(ObjectAnimator.java:990)",    "android.animation.ValueAnimator.animateBasedOnTime(ValueAnimator.java:1349)",    "android.animation.ValueAnimator.doAnimationFrame(ValueAnimator.java:1481)",    "android.animation.AnimationHandler.doAnimationFrame(AnimationHandler.java:146)",    "android.animation.AnimationHandler$1.doFrame(AnimationHandler.java:54)",    "android.view.Choreographer.doCallbacks(Choreographer.java:1047)",    "android.view.Choreographer.doFrame(Choreographer.java:914)",    "android.os.Handler.dispatchMessage(Handler.java:100)",    "android.os.Looper.loop(Looper.java:214)",    "android.app.ActivityThread.main(ActivityThread.java:7659)",    "com.android.internal.os.ZygoteInit.main(ZygoteInit.java:938)"  ]}

从死循环信息来看：

死循环发生在主线程。
主线程相对于整个进程，CPU 占用率非常高，大量抢占了子线程的 CPU 时间片。
堆栈里没有业务堆栈，因此暂时无法定位到问题代码。只能看出是发生了属性动画泄露，需要增加监控能力。

监控能力增强

ANRCanary 在感知到发生属性动画泄露以后，需要将发生泄露的属性动画揪出来。大致方案为：

从系统 AnimationHandler 类入手，获取到当前运行中的属性动画实例列表。
从属性动画实例中提取关键信息，并附加到 ANRCanary 日志中上报。

能力增强后的 ANRCanary 抓到的上报信息如下：


"case:-647468375":{  "attachInfo":{    "animatorList":[      {        "duration":1200,        "propertyList":[          {            "clazz":"IntPropertyValuesHolder",            "message":"alpha:  25  255  "          }        ],        "repeatCount":-1,        "target":"android.graphics.drawable.LayerDrawable",              "viewPath":"TextView:recording|RelativeLayout:0|RelativeLayout:0"      },      ...  },  "name":"main",  "threadCPURate":0.*,  "threadStackList":[    "android.graphics.drawable.LayerDrawable.setAlpha(LayerDrawable.java:1364)",    "android.animation.ObjectAnimator.animateValue(ObjectAnimator.java:990)",    "android.animation.ValueAnimator.animateBasedOnTime(ValueAnimator.java:1349)",    "android.animation.ValueAnimator.doAnimationFrame(ValueAnimator.java:1481)",    "android.animation.AnimationHandler.doAnimationFrame(AnimationHandler.java:146)",    "android.animation.AnimationHandler$1.doFrame(AnimationHandler.java:54)",    "android.view.Choreographer.doCallbacks(Choreographer.java:1047)",    "android.view.Choreographer.doFrame(Choreographer.java:914)",    "android.os.Handler.dispatchMessage(Handler.java:100)",    "android.os.Looper.loop(Looper.java:214)",    "android.app.ActivityThread.main(ActivityThread.java:7659)",    "com.android.internal.os.ZygoteInit.main(ZygoteInit.java:938)"  ]}

从附加信息来看，泄露的属性动画为：

duration：该动画时长为 1200 毫秒。
propertyList：

clazz：属性值的类型为 int 。
message：属性名为 alpha，属性变化值为从 25 到 255。

repeatCount：循环次数为 -1 ，即无限循环永远不停止，难怪会发生泄露。
target：alpha 属性所属的对象类型为：LayerDrawable 。
viewPath：

LayerDrawable 所属的 View 类型为 TextView。
该 TextView 的 viewId 为 recording 。
该 TextView 的父辈节点均为 RelativeLayout 类型。

基于 viewId 、动画时长、属性变化值等信息，快速定位到问题代码，确认了导致泄露的原因并修复。

案例 4：定时任务执行异常导致死循环

本案例为一个隐蔽且复杂的死循环问题，解决过程极具挑战性，耗时甚长。

初步分析

ANRCanary 抓到的上报信息如下：


"case:-2147483648":{  "name":"Timer-0",  "threadCPURate":0.*,  "threadStackList":[    "android.os.MessageQueue.enqueueMessage(MessageQueue.java:577)",    "android.os.Handler.enqueueMessage(Handler.java:662)",    "android.os.Handler.sendMessageAtTime(Handler.java:631)",    "android.os.Handler.sendMessageDelayed(Handler.java:601)",    "android.os.Handler.postDelayed(Handler.java:429)",    "de.executor(SourceFile:31)",    "tm.query(SourceFile:268)",    "mk.start(SourceFile:166)",    "mk$1.run(SourceFile:93)",    "java.util.TimerThread.mainLoop(Timer.java:555)",    "java.util.TimerThread.run(Timer.java:505)"  ]}

从死循环信息来看：

发生死循环的线程名为：Timer-0 。
该线程相对于整个进程，CPU 占用率也很高。
死循环的原因看起来是某个消息队列被打满导致。

因为 Handler 的消息队列被打满之后，每次 postDelayed 调用都要执行一次插入排序遍历整个队列。

监控能力增强

经过翻阅代码，确认代码中有一个周期性任务。周期性任务的实现方式采用的是 Java 提供的 Timer 类。正常情况下应该不会导致消息队列被打满才对。

ANRCanary 在感知到消息队列疑似被打满以后，需要收集更多信息来进行确认情况。大致方案为：

获取当前进程全部的线程对象，逐个遍历。
如果线程为 HandlerThread 类及其子类，则包含有消息队列，可以尝试获取其消息队列长度。
如果消息队列长度超过一定阈值，则可以判定为消息队列被打满。
对消息队列中的消息进行遍历聚合，分析出 Top 级消息内容。
允许存在多个线程的消息队列被打满的情况。

能力增强后的 ANRCanary 抓到的上报信息如下：


"case:-2147483648":{  "attachInfo":{    "messageQueueList":[      {        "repeatRate":1,        "repeatSignature":"android.os.Handler|jlh",        "threadName":"TaskHandlerThread",        "totalCount":****      }    ]  },  "name":"Timer-0",  "threadCPURate":0.*,  "runTime":***,  "threadStackList":[    "android.os.MessageQueue.enqueueMessage(MessageQueue.java:577)",    "android.os.Handler.enqueueMessage(Handler.java:662)",    "android.os.Handler.sendMessageAtTime(Handler.java:631)",    "android.os.Handler.sendMessageDelayed(Handler.java:601)",    "android.os.Handler.postDelayed(Handler.java:429)",    "de.executor(SourceFile:31)",    "tm.query(SourceFile:268)",    "mk.start(SourceFile:166)",    "mk$1.run(SourceFile:93)",    "java.util.TimerThread.mainLoop(Timer.java:555)",    "java.util.TimerThread.run(Timer.java:505)"  ]}

从附加信息来看：

repeatRate：消息队列重复率为 100%，说明均为同一类消息。
repeatSignature：重复消息的 Runnable 类型混淆后为：jlh，确实为监控模块的周期性任务。
threadName：消息队列所属的线程名为：TaskHandlerThread
totalCount：消息队列长度远远超出正常消息队列的长度，确实被打满。
runTime：进程存活时长并不大。正常消息队列应该只有几条消息，而不应该被打满。

看来 Timer 的间隔能力确实失效了，死循环问题是真实存在的。

最终定位

对于 Timer 的运行机制进行深入分析以后发现问题：


private void mainLoop() {  while (true) {    TimerTask task;    boolean taskFired;    long currentTime, executionTime;    // 1.从运行队列中获取头部的周期性任务    task = queue.getMin();    // 2.获取系统时间（关键点！！！）    currentTime = System.currentTimeMillis();    // 3.获取周期性任务期望执行时间    executionTime = task.nextExecutionTime;    taskFired = executionTime <= currentTime;    // 4.用两个时间的比较结果，决定是否执行周期性任务    if (taskFired) {      task.run();    }  }}

如以上代码片段第 9 行所示，Timer 的间隔时间是基于系统时间戳的。也就是说，修改手机系统时间会影响 Timer 周期性任务的执行。

写一个简单的 Demo 验证以后得出结论：

如果往前修改系统时间，周期性任务将停止执行。
如果往后修改系统时间，间隔时间会失效，周期性任务开始连续不停地执行。

至此终于定位到该死循环的根因。修改方案就是把 Timer 替换为 ScheduleExecutorService 来实现周期性任务，将不受系统时间变更的影响。

总结

长久以来，线程死循环问题经常是偶现的，比较隐蔽难以发现，钉钉自研的 ANRCanary 通过将高 CPU 占用和堆栈比较相结合的方案，突破了线程死循环问题感知难，定位难的瓶颈。通过该监控能力，团队持续对潜在风险进行优化治理，线程死循环问题基本得到根治。

提升用户体验是一条漫漫长路，唯有从点滴做起，方能逐步做到卓越。