之前和大家聊过一次pthread oom
问题。基于当时的场景以及对Rxjava的分析,只能说解决了一小部分问题。但是实际上只要我们滥用了线程,特别是华为设备,还是有可能发生对应的问题的。
所以这次打算再展开下,顺便把自己最近做的一些这方面相关的给大家做一次简单的分享。
这一次我们从两方面入手,看看能不能有效的解决这部分问题。
- 通过
debug
工具hook所有DefaultThreadFactory
创建的无名线程 - 通过
plugin+asm
进行线程池替换,把违法乱纪人员逮捕起来
正文
如果你的线上已经开始出现了这部分问题,从哪里开始下手其实是非常头疼的,因为光从线上的堆栈上来看,你很难分析出问题,同时因为是偶发线上,所以也没办法稳定复现这部分问题。
插句嘴,这篇文章没法帮你解决native端的线程溢出问题
这种对对开发来说,就是一个非常棘手的问题了。
我的看法是先能把当前的未命名的线程池都抓出来,然后将每个线程池都进行命名,这样当我们再次碰到类似的问题的时候就可以通过线程名来计数,看看谁是开启线程最多的人。之后看看这群大佬能不能优化下自己的代码。
Epic Hook
我在线上通过bugly排查过线程oom问题,这种问题并不能孤立起来看,最后一个堆栈只是压死骆驼的最后一根稻草而已。我看了下其他相邻线程的情况,并罗列了下发现其中有很多pool-x-thread-x
这种相关的,这些就是默认的线程池构造中的ThreadFactory
导致的创建的线程。
之前在iocanary
文章内和大家介绍过一部分过于动态hook的能力,我们这次的调试工具也是基于Epic,当然和xhook
还是有点差别的。
Epic提供了hook构造函数和方法的能力,这里我们主要要用的就是hoo