1.背景: 上周五(7.17)日出现因为id过长导致数据库写入异常,最终定位原因是线程id的长度在达到万级别以后,会导致生成id中根据线程id生成的值超过4位,从而导致id长度超过了32位.
2.问题分析:
- 根据线上服务服务dump文件,分析当前线程id已经达到了7W级别
- 首先我们可以确定7w个线程是不可能同时存在的,因为一个线程在jvm中消耗的内存是1MB,然后7w个线程同时存在说明线程一定就OOM了
- 其次线程的id是一个全局自增的变量,每生成一个线程,那么id就会增加1,所以系统中的确是创建过7w+个线程
- 根据上述两点进行分析,如果线程不同时存在&的确生成过等量的线程,那么线程一定销毁过.
3.问题定位:
- 无论是underdow还是redis线程池或者数据库线程池,线程池都有初始线程数以及最大线程活跃数。
- 当请求的数量超过初始线程数时,线程池会创建新线程满足需求。
- 同时每个线程池是都有一个空闲时间,如果超过这个时间线程会进行销毁。
- 所以目前分析,导致线程id过高的原因是,频繁销毁线程,销毁线程后再重新创建线程导致。