java.lang.OutOfMemoryError

【问题现象】：
自动化用例跑了约三个多小时后，界面响应时间长，界面出现500错误。之后再点击时，页面重定向至首页。查看jboss下的server.log文件发现内存溢出的OutOfMemory异常。

【出现的问题日志】：
java.lang.OutOfMemoryError
at 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 space
2. java.lang.OutOfMemoryError: PermGen space
3. java.lang.OutOfMemoryError: Requested array size exceeds VM limit

4. java.lang.OutOfMemoryError: <reason> <stack trace> (Native method)

而在出现内存泄露的机器上，其日志显示是无法创建本地线程的原因所引起的。这里的异常信息是：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….”

---------------------------------------------------------------------------------------------------------------------

MaxProcessMemory 在32位的 windows下是 2G
JVMMemory   eclipse默认启动的程序内存是64M
ReservedOsMemory  一般是130M左右
ThreadStackSize 32位 JDK 1.6默认的stacksize 325K左右
公式如下：
(2*1024*1024-64*1024-130*1024)/325 = 5841
公式计算所得5841，和实践5602基本一致（有偏差是因为ReservedOsMemory不能很精确）

由公式得出结论：你给JVM内存越多，那么你能创建的线程越少，越容易发生java.lang.OutOfMemoryError: unable to create new native thread。