由多线程内存溢出产生的实战分析.docxVIP

由多线程内存溢出产生的实战分析 2021-09-11 一日凌晨，手机疯狂报警，短信以摧枯拉朽之势霎时以百条的速度到达，我在睡梦中被惊醒，看到短信的部分内容如下： Caused by: java.lang.OutOfMemoryError: unable to create new native thread at java.lang.Thread.start0(Native Method) at java.lang.Thread.start(Thread.java:597) at java.util.Timer.init(Timer.java:154) 看到这个错误，我的第一感觉是创建了大量的线程，并且资源没有被回收，但是报错的却是其中一台应用服务器，表象看不太像是程序的问题，而此时在凌晨并发量也不应当会有这么大啊？同时我们不能由于报错暂停服务使用，而影响商户，所以打算要先处理问题，于是接受必宰技重启这台服务器，观看一小时内存溢出消逝，问题临时处理。 其次天白天这个问题并没有复现，我认为这是偶发大事，就没有过于在意，于是当晚再次消灭内存溢出，并且还是随机某一台服务器爆出，我紧急找到监控部和系统部要求拿到栈信息内容和dump文件，然而并没有。。。。我们紧急开会做代码走查，发觉这个应用其实是一个格外简约的应用，里面没有使用线程，也没有很简单的规律，只是简约的增删改操作，那会是什么缘由呢？ 接下来我们的分析之路开头了。。。。。 一、现状情况 无法找到OOM时的javacore和heapdump文件。 无法还原问题发生时候系统内存被各个进程使用的占比，CPU的占比。 日志没有特别堆栈信息。 二、处理思路 1、要能够验证Tomcat配置内存溢出时打印堆栈并验证可行性，并保证在上线和重启不被擦除。现状：当前只配置-XX:+HeapDumpOnOutOfMemoryError，没有配置路径，不晓得是被重启删除还是没有产生。 2、实现脚本，在消灭OOM的时候，重启前，打印jstack栈信息和dump文件。现状：目前是人工使用jmap和jstack打印CPU和内存信息给应急人员看。 3、实现JVM内存监控，在JVM内存紧急的时候提前报警，人工干涉。现状：无 4.、监控或者实现脚本收集java进程OOM的时候，各个进程对内存的占比等，以及监控cache, buffer等。现状：依据凌晨OOM的情况，错误堆栈表明，start0是JVM申请系统内存时内存不够，并非jvm堆内存不够而导致，需要上面信息查看具体的系统。 5、争辩底层，查找java.lang.OutOfMemoryError: unable to create new native thread错误的引发缘由有哪些。 6、针对项目进行压测发觉问题点。 三、深层次测试争辩 测试环境 操作系统：centos 7 64bit Linux内核：Linux centos 3.10.0-327.10.1.el7.x86_64 配置：1G内存 虚拟机工具：virtual box 64bit JDK： openjdk version 1.8.0_71 OpenJDK Runtime Environment (build 1.8.0_71-b15) OpenJDK 64-Bit Server VM (build 25.71-b15, mixed mode) 代码如下： /** * PROJECT_NAME: test * CREATE BY: chao.cheng **/ public class OOMTest { public static void main(String[] args) throws IOException { if (args.length 1) { System.out.println(please input thread numbers!); return; } int threadNumber = Integer.parseInt(args[0]); try { for (int i = 0; i threadNumber; i++) { new Thread() { public void run() { while (true) { try {