当你懂了以下的技巧，优化创建的几百个线程不是问题 _线程

近日，据报道，甲骨文已经与TikTok的中国所有者字节跳动进行了初步谈判，并认真考虑购买该应用在美国、加拿大、澳大利亚和新西兰的业务。知情人士还补充称，甲骨文正在与一群已经持有字节跳动股票的美国投资者合作，包括美国泛大西洋投资集团和红杉资本。
/ 前言 /当大家打开AndroidStudio的Profiler工具时，是否遇到过这种情况：

文章插图

哇塞好几百个线程？？名字咋都是12345？怎么都在sleep或wait但就不销毁？
其实，当一个项目规模越来越大时，随着开发人员变更、老代码不规范、三方sdk引入越来越多，很难避免线程数量暴涨的问题。当线程过多时，不仅有oom风险，更会带来很多内存泄漏的隐患。但通过Profiler工具也只是知道线程数量，用Thread.getAllStackTraces()方法获取到的也只有线程的运行时堆栈，即到run()方法就结束了，并不知道start()是被谁调用的。所以也就无法得知当前线程所对应的业务逻辑，以及它在当前时刻是否本应该被销毁。
/ 思路 /那如何才能得知一个线程start()方法的调用栈呢？如果我们有个BaseThread，然后所有的线程都使用或继承于它，就好办了，我们可以在start()方法中获取堆栈信息：
@Synchronizedoverride fun start() {val stackElements = Throwable().stackTracesuper.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()时再和堆栈建立关联。