Bendi新闻
>
最佳实践|一文讲解端线程死循环的治理

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


阿里妹导读


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

引言

钉钉作为一个用户数超 7 亿,服务企业与组织数超过了 2500 万的企业级智能办公平台,终端团队一直将打造极致用户体验作为我们的理念。对于 Android 设备来说,线程死循环问题可能会导致高耗电,界面卡顿,耗尽内存等性能问题。与此同时,死循环问题还具有隐蔽性高,黑盒测试无法感知的特点。针对潜在的线程死循环风险我们进行了专项的治理优化。
本文旨在介绍钉钉 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 占用和堆栈比较相结合的方案,突破了线程死循环问题感知难,定位难的瓶颈。通过该监控能力,团队持续对潜在风险进行优化治理,线程死循环问题基本得到根治。
提升用户体验是一条漫漫长路,唯有从点滴做起,方能逐步做到卓越。


微信扫码关注该文公众号作者

来源:阿里云开发者

相关新闻

Java线程池的实现原理及其在业务中的最佳实践全面解析 Jenkins 部署架构:高效持续集成的最佳实践探索Docker Compose:轻松管理多容器应用的最佳实践Ansible Playbook 与 Handler 深入解析:高效管理和自动化运维的最佳实践深入SpringMVC聊跨域问题的最佳实践使用 RBD 作为 Kubernetes 存储解决方案的最佳实践指南AI辅助内部研发效率提升,昇腾大模型推理的最佳实践Kimi or 豆包?谁是你浏览器的最佳AI助手|AI 横评Go应用性能优化的8个最佳实践,快速提升资源利用效率!创始人pk流量明星,谁才是品牌的最佳代言人?|中国案例守门者的产业与治理|章启明提升性能的利器!探索Redis集群的强大功能与最佳实践探索 IT 架构治理之道:微众银行的实践与思考在你的镜头里,校园有种别样的美|短视频大赛最佳创作奖揭晓独家|中国品牌升级加速,这16个最佳实践案例值得收藏!一文带你检查Kubernetes应用是否为最佳实践转发|友社茶话会“国家视角下的全球治理与青年使命” 欢迎参与对话|长安汽车董事长朱华荣:当下是中国车企成长为世界级品牌的最佳机会渡十娘| 公立向左,私立往右——进入留学围城的最佳时机到底是几岁?Cloudflare 的 ML 和 AI 之旅:MLOps 平台和最佳实践深度探索大模型时代的软件架构最佳范式,攻略就绪、就等你来|ArchSummit九年记录,诗意救赎 |《胡阿姨的花园》斩获金爵奖最佳纪录片!2024全球最佳旅游国家出炉|美国登顶!中国排第八,因其独特的旅游魅力…西安路演|金鸡奖最佳中小成本故事片《冰下的鱼》超前点映暨导演交流
logo
联系我们隐私协议©2024 bendi.news
Bendi新闻
Bendi.news刊载任何文章,不代表同意其说法或描述,仅为提供更多信息,也不构成任何建议。文章信息的合法性及真实性由其作者负责,与Bendi.news及其运营公司无关。欢迎投稿,如发现稿件侵权,或作者不愿在本网发表文章,请版权拥有者通知本网处理。