近日，据报道，甲骨文已经与TikTok的中国所有者字节跳动进行了初步谈判，并认真考虑购买该应用在美国、加拿大、澳大利亚和新西兰的业务。知情人士还补充称，甲骨文正在与一群已经持有字节跳动股票的美国投资者合作，包括美国泛大西洋投资集团和红杉资本。
前言
当大家打开AndroidStudio的Profiler工具时，是否遇到过这种情况：
哇塞好几百个线程？？名字咋都是12345？怎么都在sleep或wait但就不销毁？
其实，当一个项目规模越来越大时，随着开发人员变更、老代码不规范、三方sdk引入越来越多，很难避免线程数量暴涨的问题。当线程过多时，不仅有oom风险，更会带来很多内存泄漏的隐患。但通过Profiler工具也只是知道线程数量，用Thread.getAllStackTraces()方法获取到的也只有线程的运行时堆栈，即到run()方法就结束了，并不知道start()是被谁调用的。所以也就无法得知当前线程所对应的业务逻辑，以及它在当前时刻是否本应该被销毁。
思路
那如何才能得知一个线程start()方法的调用栈呢？如果我们有个BaseThread，然后所有的线程都使用或继承于它，就好办了，我们可以在start()方法中获取堆栈信息：
@Synchronized
override fun start() {
val stackElements = Throwable().stackTrace
super.start()
}
想要做到这一点，可以使用asm编译期间改字节码来完成。这里简单介绍下asm，它可以通过自定义gradle插件，在代码被编译成class后、打包成dex前，把项目中的所有class文件（包括你自己写的，和三方jar包中的）遍历一遍，遍历期间你就可以通过asm任意修改class字节码，以达到各种不可告人的目的。那么我们就可以通过asm来把项目中的Thread都替换掉：
new Thread() -> new BaseThread()
extends Thread -> extends BaseThread
操作
现在有了调用栈，如何将调用栈和线程建立联系呢？其实Thread初始化时已经产生了线程id，我们可以在start()中把线程id和对应栈信息放到一个map中。另外我们还可以复写run()方法，当super.run()执行完后，线程即将销毁，我们可以在此时把map中对应信息移除掉。
好了！就是这么简单，接下来看线程池。线程池中的线程按刚刚的方法是替换不掉的，因为这些代码在framework层，asm管不着。并且对于线程池来说，我们需要的不是它的线程在哪被启动，而是线程正在执行的task是从哪里被添加的，这样我们才知道是哪个业务添加了task使得线程一直在运行。
线程池一般有两种创建方法，直接new和调用Executors.xxx，我们先看new出来的，按照上述套路，搞个BaseThreadPool，使用asm全部替换掉，然后在构造函数中获取线程池创建堆栈，再复写execute、submit、invokeAny等提交task的方法，在其中获取task添加堆栈。但获取到的堆栈如何跟线程对应上呢？我们知道提交的task都是Runnable或Callable形式，如果我们写个PoolRunnable把它包一层，把线程池名字和task添加栈传进去，然后在run()中调用Thread.currentThread()获取当前线程，就把线程池名、线程池创建栈、线程id、task添加栈都关联起来了。
class PoolRunnable constructor(
private val any: Any,
private val callStack: String,
private val poolName: String? = null
) : Runnable, Callable<Any>, Comparable<Any> {
override fun run() {
val threadId = Thread.currentThread().id
// 至此callStack、poolName、thread就可以全部关联上
// poolName和poolCreateStack可在外面事先创建关联
(any as Runnable).run()
// 任务已执行结束，callStack表示task添加栈，此时应为空代表线程当前无任务在运行
info.callStack = ""
}
override fun call(): Any {
// 类似run()方法
}
override fun compareTo(other: Any): Int {
// 省略代码
}
}
这里有一点要说明，有些task可能同时继承于Runnable、Callable、甚至Comparable，如果只包装成Runnable，当调用其他接口方法时会crash，所以这里要把已知的可能会继承的接口都实现。（当然如果后面发现没覆盖全，可以把新的接口继续加进来。至于用户自定义Runnable实现很多接口的情况不用担心。因为替换为PoolRunnable后都是系统代码在运行，主要看系统代码是否会调用call()、compareTo()等方法就好，上层随意调用被包装的runnable中各种自定义方法是没问题的）。
但是对于建立“线程-线程池”关系来说，这样要等到run()方法被执行时才能建立关系，感觉有点晚。这里可以更进一步，替换掉线程池中threadFactory，同样是自己包一层，在newThread()方法中即可及时拿到线程池创建的线程，这样就可以先和线程池建立关联，然后run()时再和堆栈建立关联。
好了！new方式创建的线程池搞定，接下来看看Executors.xxx怎么玩，我们可不可以自己写个ProxyExecutors，使用asm把所有Executors.xxx都替换成ProxyExecutors.xxx，然后把其中new ThreadPool都换成new BaseThreadPool呢？
object ProxyExecutors {
@JvmStatic
fun newFixedThreadPool(nThreads: Int): ExecutorService {
return BaseThreadPoolExecutor(
nThreads, nThreads,
0L, TimeUnit.MILLISECONDS,
LinkedBlockingQueue()
)
}
@JvmStatic
fun newCachedThreadPool(): ExecutorService {
return BaseThreadPoolExecutor(
0, Int.MAX_VALUE,
60L, TimeUnit.SECONDS,
SynchronousQueue()
)
}
@JvmStatic
fun newScheduledThreadPool(
corePoolSize: Int,
threadFactory: ThreadFactory?
): ScheduledExecutorService {
return BaseScheduledThreadPoolExecutor(corePoolSize, threadFactory)
}
}
对于某些线程池确实没啥问题，但当你继续写下去时，会出问题，比如：
@JvmStatic
fun newSingleThreadScheduledExecutor(): ScheduledExecutorService {
return BaseDelegatedScheduledExecutorService(
ScheduledThreadPoolExecutor(1)
)
}
DelegatedScheduledExecutorService是Executors的私有内部类，没办法方便的写出BaseDelegatedScheduledExecutorService。所以继续观察下，发现所有创建线程池方法都返回的都是ExecutorService或ScheduledExecutorService，既然这么统一，并且这两个都是接口，那我们就使用动态代理吧！通过代理，就可以拿到接口的各种方法以及方法参数，然后为所欲为。以ExecutorService接口为例：
object ProxyExecutors {
@JvmStatic
fun newFixedThreadPool(nThreads: Int): ExecutorService {
return proxy(Executors.newFixedThreadPool(nThreads))
}
}
private fun proxy(executorService: ExecutorService): ExecutorService {
if (executorService is ThreadPoolExecutor) {
// 这里和BaseThreadPoolExecutor一样，设置ThreadFactory为了尽早获取线程信息和线程池建立联系，而不用等到run时
executorService.threadFactory = BaseThreadFactory(
executorService.threadFactory,
toObjectString(executorService)
)
}
val handler = ProxyExecutorService(executorService)
return Proxy.newProxyInstance(
executorService.javaClass.classLoader,
AbstractExecutorService::class.java.interfaces,
handler
) as ExecutorService
}
// 这里使用java是因为kotlin在调用java变长参数方法时有坑
public class ProxyExecutorService implements InvocationHandler {
private ExecutorService executor;
private String poolName = null;
ProxyExecutorService(ExecutorService executor) {
this.executor = executor;
poolName = TrackerUtils.toObjectString(executor);
// 初始化时获取线程池信息
String createStack = TrackerUtils.getStackString(false);
// 省略部分代码
}
@Override
public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
// 因方法数众多，并且被代理的各类中方法也不一致
// 所以被调用方法中只要含有Runnable、Callable类型的参数，都替换成PoolRunnable代理
if (args != null) {
String callStack = TrackerUtils.getStackString(true);
for (int i = 0; i < args.length; i++) {
Object arg = args[i];
if ((arg instanceof Runnable || arg instanceof Callable) && !(arg instanceof PoolRunnable)) {
// execute submit 等情况
PoolRunnable any = new PoolRunnable(arg, callStack, poolName);
// 替换方法参数
args[i] = any;
} else if (arg instanceof Collection && !((Collection) arg).isEmpty()) {
// invokeAny invokeAll 等情况
Iterator iter = ((Collection) arg).iterator();
ArrayList<PoolRunnable> taskList = new ArrayList<>();
boolean allOk = iter.hasNext();
while (iter.hasNext()) {
Object it = iter.next();
if (it instanceof Runnable || it instanceof Callable) {
if (it instanceof PoolRunnable) {
taskList.add((PoolRunnable) it);
} else {
taskList.add(new PoolRunnable(it, callStack, poolName));
}
} else {
allOk = false;
break;
}
}
if (allOk) {
// 替换方法参数
args[i] = taskList;
}
}
}
}
if (method.getName().equals("shutdown") || method.getName().equals("shutdownNow")) {
ThreadInfoManager.getINSTANCE().shutDownPool(poolName);
}
return method.invoke(executor, args);
}
}
在invoke方法中，我们把所有参数为Runnable或Callable的都替换成自己的PoolRunnable，后面和new创建线程池的套路一样，在PoolRunnable的run()或call()方法中进行线程与堆栈的关联。完美！
但是考虑一个问题，如果有人不幸写出这样的代码，会发生什么呢？
val pool = Executors.newFixedThreadPool(3) as ThreadPoolExecutor
对了，会crash，因为我们动态代理后代理对象变成了ExecutorService，没办法向下转型成ThreadPoolExecutor，这也是动态代理的一个缺点，只能代理接口，如果一个类A除了实现接口还有很多自己的方法，动态代理对这些方法是无能为力的，代理后对象只是接口的实例，无法转成类A。这个问题可以使用cglib/javassist库解决，这里就不展开了。为了保险起见，我们可以把能用Base替换的都替换掉，只有类似newSingleThreadScheduledExecutor()这种不能用Base替换的才用动态代理：
object ProxyExecutors {
@JvmStatic
fun newFixedThreadPool(nThreads: Int): ExecutorService {
// 这里使用BaseThreadPoolExecutor主要是为了避免上层代码把ExecutorService转型成ThreadPoolExecutor的问题，如果使用proxy方法动态代理，上层这么做会crash
return BaseThreadPoolExecutor(
nThreads, nThreads,
0L, TimeUnit.MILLISECONDS,
LinkedBlockingQueue()
)
// return proxy(Executors.newFixedThreadPool(nThreads))
}
ok，线程池搞定了。但除了线程和线程池，Java和Android中还有很多封装了线程线程池的类。比如HandlerThread，Timer，ASyncTask等，我们先处理这几个常用类吧。
HandlerThread本质上就是Thread，采用和Thread类似的处理方式就好。
Timer内部有个私有的TimerThread成员，本质也是个Thread，看源码可知Timer在构造方法中便启动了这个Thread，所以调用栈也就是Timer被初始化的栈。我们可以新建BaseTimer，使用asm将代码中的Timer替换掉，然后构造方法中获取调用栈，再通过反射拿到内部Thread成员，获取其id等信息，与调用栈关联即可。
ASyncTask这个相对来说难办一些，这里面主要有两个Executor：THREAD_POOL_EXECUTOR和SERIAL_EXECUTOR，其中主要干活的是THREAD_POOL_EXECUTOR，而SERIAL_EXECUTOR并不是真正意义上的线程池，只是实现了Executor接口而已。SERIAL_EXECUTOR的execute()方法在向一个队列中添加任务，然后依次取出送入THREAD_POOL_EXECUTOR中执行，所以我们需要THREAD_POOL_EXECUTOR的线程池信息，关联SERIAL_EXECUTOR的execute()任务添加栈信息。
而外界又可以直接用THREAD_POOL_EXECUTOR添加任务，这种情况下就又需要THREAD_POOL_EXECUTOR的任务添加栈信息了，所以这里需要一些特殊处理。总体思路仍然是动态代理SERIAL_EXECUTOR和THREAD_POOL_EXECUTOR，然后把代理设置回ASyncTask，时机为app启动时。由于ASyncTask中这两个线程池对象是final的，所以需要通过反射修改modifiers去掉final位。这在5.0及以上系统没什么问题，但4.x的源码中modifiers是通过native获取的：
/**
* Returns the modifiers for this field. The {@link Modifier} class should
* be used to decode the result.
*
* @return the modifiers for this field
* @see Modifier
*/
public int getModifiers() {
return getFieldModifiers(declaringClass, slot);
}
private native int getFieldModifiers(Class<?> declaringClass, int slot);
对此暂未找到修改方式，所以如果要追踪ASyncTask，请使用Android 5.0及以上手机。
至此，线程/线程池溯源基本完成了，后续会继续完善IntentService、ForkJoinPool和Java/Android源码中封装的其他不太常用的线程/线程池封装类。
初版效果长这样：
可以看到界面中对用户代码做了高亮，帮助用户在迷乱的调用栈中一眼看到问题根源。其原理大致是在asm扫描class过程中，根据获取到的项目信息来记录哪些是用户写的代码（不能直接根据是否为jar包来判断，如果项目存在多个module，可能这些module最后也是以jar包形式被asm扫描），然后把相关class包名记下来，过滤掉包含有“已有短包名”的“较长包名”，把这些包名list通过asm写入到指定Java类的指定ArrayList成员中。在获取到调用栈后，可以和这些包名list对比，进行高亮。
总结
最后，此文作为抛砖引玉，提供一种线程溯源的思路。其实可以看出asm还是很强大的，能做什么就取决于大家的想象力了。后面会逐渐完善新功能，比如记录线程运行时间，根据线程各维度状态筛选/排序等，统计线程所属包名或jar文件名，看看那些三方库在为非作歹（特别是某些广告sdk，简直。。），甚至对线程/线程池运行状态可疑的给出警告和优化建议等等。
最最后，作为asm初学者，很多用法还比较初级，如果有更优雅的实现方式，欢迎疯狂pull requests；另外，该项目虽然目前在咕咚这个比较庞大复杂的app上可正常运行，但难免还有考虑不周全的地方，毕竟替换字节码是比较危险的操作。
想要了解更多可以点击我的[github]获取更多资料哦。(https://github.com/AndroidCot/Android)
网友评论