作者：明义、光线
部门：业务技术
一、前言
随着应用不断的迭代更新，零售工程内异步任务逐渐增多，包括网络请求、本地 DB 操作、轮询等任务使用的都是同一个线程池，线程池极易打满（比如网络一慢就容易阻塞线程池），导致任务堆积，造成「操作卡顿」的现象。用户看到操作没反应，可能会更频繁的尝试操作，再加上不断轮询的任务，应用的线程池队列会快速积压更多的任务，「卡顿」现象加剧，单一线的线程池已经无法支撑业务需求：
- 任务没有隔离，异步任务相互影响主要是长耗时影响短耗时任务
- 轮回任务开销大：没有统一的轮询处理方式，业务方需要自己创建线程或线程池（有些干脆就在默认的 I/O 线程池进行轮询），应用中存在大量的自建线程 池，增加无谓的资源消耗
- 缺少监控：缺乏线程池的监控和日志，线程池的运行状况和健康度无法衡量，一旦出现「卡顿」问题，排查非常困难，完全不知道是哪些任务造成的问题，伤害用户体验的同时，也极大的消耗开发人员的精力
图注：短时间任务暴涨的情况，在几毫秒内触发多次任务
二、整体设计
目标：
- 任务隔离，避免耗时任务影响交互
- 统一轮询，减少资源开销
- 任务监控，防止业务方使用错误
- 信息采集与监控，快速定位排查问题
优化的核心在于分离和监控
分离：
对原有的 I/O 线程池进行拆分，分离出不适合放在这个线程池的任务，保证 I/O 线程池能对大量、快速的本地任务给予更好的支持，而分离的关键就在于分离出「慢」和「多」的任务:
- 避免耗时短的任务等待耗时长的任务
- 避免频繁、大量执行的任务占据大量的线程池资源
具体的策略包括:
- 将网络请求的线程分离出来，放入单独的线程池中，避免因网络任务慢阻塞本地的快速任务
- 将轮询任务分离出来，当轮询的任务耗时过长或者线程池打满的场景下，会极速加剧线程池的恶化，最终让主流程完全瘫痪，轮询任务不适合放在通用的线程池中，通过将它放入通用的轮询任务线程池，统一化的对轮询任务进行管理
监控：
除了已知的网络任务&轮询任务需要分离出 I/O 线程池之外，还需要增加对线程池的监控，进一步分离出不适合放在I/O线程池的任务（同样是「慢」和「多」）
- 通过监控每个任务执行的时长，分离出长耗时（即「慢」）的任务，分析出是因为逻辑 bug 还是本身的复杂度正常占用，如果是正常占用就考虑是否合适继续放在默认的 I/O 线程池，最终目标是达成对「慢」的优化
- 另外零售工程中还存在短时间大量重复任务堆积的现象，当线程池接近或达到负荷状态时，监控线程池中的任务，找到批量的任务，然后进行优化，最终目标是达成对「多」的优化
- 通过上面的方式将「慢」的任务分离出去之后，并不代表这样就完事了，这些任务可能会消耗大量的系统资源，所以同样需要统一对这个线程池进行监控（主要是网络任务的监控），把慢网络请求找出来，达到对「慢」的进一步优化
- 通过 API 监控业务方使用合理性，比如：使用多线程轮询的合理性
三、技术实现
2.1 线程管理库
目标：
- 管理工程内所有线程池与线程创建
- 子线程任务监控
- 线程池隔离任务分开执行，使用不同线程池执行不同任务
- 轮询任务的统一与异常任务的过滤
- 线程池的自动最优设置
线程库结构图
线程池管理，目前会提供三种线程池：
- 网络线程池：针对网络任务。更改方式：直接在网络库替换业务方无感知
- IO 线程池：针对本地异步任务。更改方式：App 启动时 Hook RxJava 线程池替换业务方无感知
- 轮询线程池：针对轮询任务，需要业务方的接入
线程池 API 定义
3.2 轮询任务统一
- 禁止时间间隔小于 1 秒轮询任务，防止高频轮询消耗资源
- 所有轮询任务巡检间隔 1 秒检测一次
- 轮询检测是独立的线程，只做轮询检测，有任务时死循环间隔检测，没有任务时则睡眠等待下次注册执行，根据结果轮询执行或睡眠
- 线程任务模式有两种：
单线程回调: 表示最多占用一个线程。例：1 秒轮询回调 1 次，再回调前会判断上个任务是执行完成，如果没有执行完成则回调 pollTaskExceptionCallback()，如果已经执行完成则回调 pollTaskCallback()
多线程回调：表示最多占用 30 个线程。例：1 秒轮询回调 1 次，再回调前会判断当前任务占用线程总量，如果没有执行完成则回pollTaskExceptionCallback()，如果已经执行完成则回调。pollTaskCallback() 默认是单线程回调
5.业务方可以指定轮询次数，或设置无限轮询
6.轮询线程池动态扩容：初始线程为 30 个，如果使用线程等于核心线程则动态扩容 2 倍，最大限制 120 个核心线程
轮询任务流程图
轮询 API 定义
任务过滤：
轮询正常回调 pollTaskCallback() 方法，如果异常这时将回调到 pollTaskExceptionCallback() 方法。
异常任务过滤的实现:
- 记录所有任务。
- 每次执行任务时会进行校验，校验监听者是否已经把自己申请的线程全部使用，如果已经全部占用将回调异常方法，直接到任务有一个释放后再继续回调。
- 任务执行完后重设记录数据。
轮询异常回调有三种触发场景:
- 单线程任务没有释放超时。
- 多线程任务占用线程超过最大数量。
- 轮询线程池被全部占满超时。
任务过滤-流程图
四、工程更改
工程更改主要分为 5 块：
- 网关请求线程池的替换，在构建 RxJava observable 替换成自定义网络线程池。
- RxJava 默认线程池的替换，App 启动时把 RxJava Hook 设置成自定义 IO 线程池。
- 轮询业务接入统一轮询。
- 网线线程池使用错误拦截，目的防止线程使用错误，禁止 IO 线程网络请求，通过拦截器方式实现。
- 线程任务监听设置给 APM ，通过 APM 分析上报。
备注：只有轮询需要业务方逐个替代其它都正常使用不感知。
五、信息采集与监控
- 任务提交之后记录每个任务的调用栈信息以及任务提交的时间，之后在任务真正开始执行时会记录任务开始的时间，任务执行完成后即可算出一个任务完整的执行时间、任务等待时间等，这样就可以抓取出「慢」的任务
- 在任务执行完成时，如果线程池已满并且任务的等待时间超过阈值，则会拉出线程池任务栈的信息，用于查找出异常的任务
线程池监听 API
任务监听实现流程
改善效果：
卡顿定义：包含主线程超过300ms慢方法、ANR、本地子线程操作超过1s、线程池阻塞、页面渲染时间超过200ms。
卡顿次数趋势图
图注：卡顿次数下降 76%
六、未来规划
- 支持更多维度的任务监控，并增加自动报警能力
- 针对不同的机型进行最优线程池配置，最大化复用系统资源
- 逐渐完善 pthread、线程任务数量等监控能力
强力驱动