今日头条 ANR 优化实践系列 - Barrier 导致主线程假死

字节跳动技术团队

于 2021-04-06 18:24:25 发布

阅读量8.8k

点赞数 7

CC 4.0 BY-SA版权

文章标签：队列 java 面试分布式 python

本文链接：https://blog.youkuaiyun.com/ByteDanceTech/article/details/115475302

简述：

前文，我们通过线上案例对影响 ANR 问题的六大场景进行剖析，这几类场景基本覆盖了线上大部分问题，详见ANR 案例分析集锦。同时我们选取了较多 NativePollOnce 场景的案例，便于大家更好理解，ANR 时看到的 NativePollOnce 场景的问题，并不是导致 ANR 的根本问题。

下面要介绍的这类问题，Trace 现场依然是 NativePollOnce 信息，但与前几类问题不同的是，这类问题真的发生在 NativePollOnce 场景，接下来就看看到底是什么原因导致的。

主线程 Trace 堆栈：

分析思路：

针对该类问题，当看到这个信息时，第一判断依然是主线程历史消息耗时严重，或者系统负载过重导致的问题，因为工作日常分析了太多这类场景的 ANR 问题，而且最后的结论也证明都与此场景无关。但分析这个问题时，进一步拆解大盘指标发现一段时间内 ANR 增加的量级，基本全部落在这个场景，这不太符合我们的预期。但是鉴于 Trace 信息有限，只好把目光转移到系统侧，看看是否有线索。

分析系统&进程负载：

观察系统负载： 在 ANR Info 中查看 Load 关键字，发现系统在前 1 分钟，前 5 分钟，前 15 分钟各个时段负载并不高。

观察进程 CPU 分布： 进一步观察"CPU usage from 0 ms to 24301 later"，看到 ANR 之后这 24S 多的时间，应用主进程 CPU 占使用率只有 15%，但是 com.meizu.mstore 应用 CPU 使用率达到 92%，user 与 kenel 比例分别为 71%，20%。与此同时 kswapd,mmc-cmdqd 等内核线程 CPU 使用率并不高，说明系统负载总体正常。如果根据我们前面案例分析得出的结论来看，这种场景难道是 com.meizu.mstore 进程严重抢占 CPU 导致的？带着这个疑惑，继续观察系统 CPU 分布。

观察系统 CPU 分布：

进一步分析系统负载，发现整体 CPU 使用率稍微有些高。user 占比 37%，kernel 占比 24%，iowait 占比 6.9%，说明这段时间系统 IO 确实有些繁忙。

系统侧结论： 通过观察系统负载和各个进程的 CPU 使用情况，发现系统环境比较正常，但是 com.meizu.mstore 进程 CPU 占比偏高，而且 kernel 层 cpu 使用率(20%)较高，与系统 iowait (6.9%)占用较高可能存在一定关联，那么 IO 负载较高对当前应用有多大影响呢？我们回到应用侧进一步分析。