《javalangOutOfMemoryErrorunabletocreatenewnativethread内存泄漏分析.docVIP

【问题现象】：自动化用例跑了约三个多小时后，界面响应时间长，界面出现500错误。之后再点击时，页面重定向至首页。查看jboss下的server.log文件发现内存溢出的OutOfMemory异常。【出现的问题日志】：java.lang.OutOfMemoryErrorat java.util.zip.ZipFile.open(Native Method)at java.util.zip.ZipFile.init(ZipFile.java:203)at java.util.jar.JarFile.init(JarFile.java:132)at java.util.jar.JarFile.init(JarFile.java:97)2010-11-24 15:32:48,377 ERROR [STDERR] Exception in thread Thread-5271? 2010-11-24 15:32:48,377 ERROR [STDERR] java.lang.OutOfMemoryError: unable to create new native thread【问题定位】：对于一般的内存泄漏导致的堆栈溢出，通常的错误信息主要有以下几种。1. java.lang.OutOfMemoryError: Java heap space2. java.lang.OutOfMemoryError: PermGen space3. java.lang.OutOfMemoryError: Requested array size exceeds VM limit4. java.lang.OutOfMemoryError: reason stack trace (Native method) 回复次数：1 luozhangwen (我不懒--押宝党实习生) 等　级： #1楼 得分：0回复于：2010-12-27 16:06:51 而在出现内存泄露的机器上，其日志显示是无法创建本地线程的原因所引起的。这里的异常信息 是：java.lang.OutOfMemoryError: unable to create new native thread，对应上述内存溢出的第4种场景。尽管可以初步怀疑是虚拟机参数的设置导致的问题，但实际上还是需要确认系统在自动化场景下有没有其他内存泄 露问题。重新跑自动化，并中间使用“jstat –gcutil 进程ID 1000 3 jstat.txt”命令，每隔3秒查看一下虚拟机堆空间的回收情况。在运行了三个多小时后，发行server.log种已经出现了该 OutOfMemory的异常信息。此时查看了jstat.txt文件，发现从自动化开始运行一直到堆栈溢出，内存回收都很正常。全部垃圾回收时间花费了 5秒左右，且未有full gc，全为young gc的时间。持久区（Perm）、年老区(Old)，分别占用了25%、19%左右的空间。且使用“top”命令监测中间CPU和内存占用都比较稳定，没 有激增的现象。使用“jmap –hito 进程ID”查看内存对象统计，发现没有业务逻辑相关的类导致的泄露问题。系统中创建最多的就是与Sting相关的char数组对象。这个也是正常情况，排除程序级别的内存泄漏问题。也就是说堆栈溢出不是1和2的两种情况。此时再分析server.log种的日志信息，得知是无法创建本地线程所致的问题。也就是说在压力环境下拥有大量的线程，或者本地内存耗尽时，企图创建新的线程时抛出。而系统能创建的线程数的计算公式如下：? (MaxProcessMemory - JVMMemory - ReservedOsMemory) / (ThreadStackSize) = Number of threads? MaxProcessMemory 指的是一个进程的最大内存JVMMemory JVM内存ReservedOsMemory 保留的操作系统内存ThreadStackSize 线程栈的大小【解决方法】:针对无法创建更多本地线程的情况，调整线程栈的大小，添加-Xss选项，设置为256k后再跑自动化，发现问题解决。?JAVA_OPTS=-Xms2048M -Xmx2048M -Xmn512M -Xss256k -XX:PermSize=512M….” —OutOfMemory, 它是这样来描述他自己的： java.lang.OutOfMemoryError: unable to create new native thread 而且这位仁兄竟然还堂而皇之地同时出现在了3个application里面，所有应用全部遭殃