再聊聊pthread oom 问题 | 性能优化

之前和大家聊过一次pthread oom问题。基于当时的场景以及对Rxjava的分析，只能说解决了一小部分问题。但是实际上只要我们滥用了线程，特别是华为设备，还是有可能发生对应的问题的。

所以这次打算再展开下，顺便把自己最近做的一些这方面相关的给大家做一次简单的分享。

这一次我们从两方面入手，看看能不能有效的解决这部分问题。

1. 通过debug工具hook所有DefaultThreadFactory创建的无名线程
2. 通过plugin+asm进行线程池替换，把违法乱纪人员逮捕起来

正文

如果你的线上已经开始出现了这部分问题，从哪里开始下手其实是非常头疼的，因为光从线上的堆栈上来看，你很难分析出问题，同时因为是偶发线上，所以也没办法稳定复现这部分问题。

插句嘴，这篇文章没法帮你解决native端的线程溢出问题

这种对对开发来说，就是一个非常棘手的问题了。

我的看法是先能把当前的未命名的线程池都抓出来，然后将每个线程池都进行命名，这样当我们再次碰到类似的问题的时候就可以通过线程名来计数，看看谁是开启线程最多的人。之后看看这群大佬能不能优化下自己的代码。

Epic Hook

我在线上通过bugly排查过线程oom问题，这种问题并不能孤立起来看，最后一个堆栈只是压死骆驼的最后一根稻草而已。我看了下其他相邻线程的情况，并罗列了下发现其中有很多pool-x-thread-x这种相关的，这些就是默认的线程池构造中的ThreadFactory导致的创建的线程。

之前在iocanary文章内和大家介绍过一部分过于动态hook的能力，我们这次的调试工具也是基于Epic，当然和xhook还是有点差别的。