Booster 系列之——多线程优化

项目地址：github.com/didi/booste…

对于开发者来说，线程管理一直是最头疼的问题之一，尤其是业务复杂的 APP，每个业务模块都有着几十甚至上百个线程，而且，作为业务方，都希望本业务的线程优先级最高，能够在调度的过程中获得更多的 CPU 时间片，然而，过多的竞争意味着过多的资源浪费在了线程调度上。

如何能有效的解决上述的多线程管理问题呢？大多数人可能想到的是「使用统一的线程管理库」，当然，这是最理想的情况，而往往现实并非总是尽如人意。随着业务的高速迭代，积累的技术债也越来越多，面对错综复杂的业务逻辑和历史遗留问题，架构师如何从容应对？

在此之前，我们通过对线程进行埋点监控，发现了以下的现象：

在某种场景下会无限制的创建新线程，最终导致 OOM
在某一时间应用内的线程数达到数百甚至上千
即使在空闲的时候，线程池中的线程一直在 WAITING ，一直不会销毁

这些现象最终导致的问题是：

OOM
无法分辨出线程所属的业务线，导致排查问题效率低下

针对这些问题，如果采用上面提到的「统一线程管理库」的方案，对于业务方来说，任何大范围的改造都意味着风险和成本，那有没有低成本的解决方案呢？经过反复思考和论证，最终我们选择了字节码注入方案，具体思路是：

对线程进行重命名

重命名线程的主要目的是为了区分该线程是由哪个模块、哪个业务线创建的，这样，线程监控埋点的聚合能够做到更加精确
对线程池的参数进行调优
- 限制线程池的 minPoolSize 和 maxPoolSize
- 允许核心线程在空闲的时候自动销毁

线程重命名

经过分析发现，APP 中的线程创建主要是通过以下几种方式：

Thread 及其子类
TheadPoolExecutor 及其子类、Executors、ThreadFactory 实现类
AsyncTask
Timer 及其子类

以 Thread 类为例，可以通过以下构造方法进行线程的实例化：

Thread()
Thread(runnable: Runnable)
Thread(group: ThreadGroup, runnable: Runnable)
Thread(name: String)
Thread(group: ThreadGroup, name: String)
Thread(runnable: Runnable, name: String)
Thread(group: ThreadGroup, runnable: Runnable, name: String)
Thread(group: ThreadGroup, runnable: Runnable, name: String, stackSize: long)

我们的目标就是将以上这些方法调用替换成对应的 ShadowThread 的静态方法：

ShadowThread.newThread(prefix: String)

public static Thread newThread(final String prefix) {return new Thread(prefix);
}
复制代码

ShadowThread.newThread(target: Runnable, prefix: String)

public static Thread newThread(final Runnable target, final String prefix) {return new Thread(target, prefix);
}
复制代码

ShadowThread.newThread(group: ThreadGroup, target: Runnable, prefix: String)

public static Thread newThread(final ThreadGroup group, final Runnable target, final String prefix) {return new Thread(group, target, prefix);
}
复制代码

ShadowThread.newThread(name: String, prefix: String)

public static Thread newThread(final String name, final String prefix) {return new Thread(makeThreadName(name, prefix));
}
复制代码

ShadowThread.newThread(group: ThreadGroup, name: String, prefix: String)

public static Thread newThread(final ThreadGroup group, final String name, final String prefix) {return new Thread(group, makeThreadName(name, prefix));
}
复制代码

ShadowThread.newThread(target: Runnable, name: String, prefix: String)

public static Thread newThread(final Runnable target, final String name, final String prefix) {return new Thread(target, makeThreadName(name, prefix));
}
复制代码

ShadowThread.newThread(group: ThreadGroup, target: Runnable, name: String, prefix: String)

public static Thread newThread(final ThreadGroup group, final Runnable target, final String name, final String prefix) {return new Thread(group, target, makeThreadName(name, prefix));
}
复制代码

ShadowThread.newThread(group: ThreadGroup, target: Runnable, name: String, prefix: String)

public static Thread newThread(final ThreadGroup group, final Runnable target, final String name, final long stackSize, final String prefix) {return new Thread(group, target, makeThreadName(name, prefix), stackSize);
}
复制代码

细心的读者可能会发现，ShadowThread 类的这些静态方法的参数比替换之前多了一个 prefix，其实，这个 prefix 就是调用 Thread 的构造方法的类的 className，而这个类名，是在 Transform 的过程中扫描出来的，下面用一个简单的例子来说明，比如我们有一个 MainActivity 类：

package com.didiglobal.booster.demo;public class MainActivity extends AppCompatActivity {public void onCreate(Bundle savedInstanceState) {new Thread(new Runnable() {public void run() {doSomething();}}).start();}}
复制代码

在未重命名之前，其创建的线程的命名是 Thread-{N}，为了能让 APM 采集到的名字变成 com.didiglobal.booster.demo.MainActivity#Thread-{N}，我们需要给线程的名字加一个前缀来标识，这个前缀就是 ShadowThread 的静态方法的最后一个参数 prefix 的来历。

线程池参数优化

理解了线程重命名的实现原理，线程池参数优化也就能理解了，同样也是将调用 ThreadPoolExecutor 类的构造方法替换为 ShadowThreadPoolExecutor 的静态方法，如下所示：

public static ThreadPoolExecutor newThreadPoolExecutor(final int corePoolSize, final int maxPoolSize, final long keepAliveTime, final TimeUnit unit, final BlockingQueue<Runnable> workQueue, final String name) {final ThreadPoolExecutor executor = new ThreadPoolExecutor(1, MAX_POOL_SIZE, keepAliveTime, unit, workQueue, new NamedThreadFactory(name));executor.allowCoreThreadTimeOut(keepAliveTime > 0);return executor;
}
复制代码

以上示例中，将线程池的核心线程数设置为 0，最大线程数设置为 MAX_POOL_SIZE^[1]，并且，允许核心线程在空闲时销毁，避免空闲线程占用过多的内存资源。

JDK Bug

经过以上对线程池的优化后中，我们信心满满的的准备灰度发布，但是，当我们在进行功耗测试时，发现 CPU 负载异常竟然高达 60%以上，经过一步步排查，最终发现问题出在 ScheduledThreadPool 的 minPoolSize 上，竟然命中了 JDK 的两个 bug，而且这两个 bug 直到 JDK 9 才修复：