【问题现象】：自动化用例跑了约三个多小时后，界面响应时间长，界面出现500错误。
之后再点击时，页面重定向至首页。
查看jboss 下的server.log 文件发现内存溢出的OutOfMemory 异常。
【出现的问题日志】：ng.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] ng.OutOfMemoryError:unable to create new native thread【问题定位】：对于一般的内存泄漏导致的堆栈溢出，通常的错误信息主要有以下几种。
1. ng.OutOfMemoryError: Java heap space2. ng.OutOfMemoryError: PermGen space3. ng.OutOfMemoryError: Requested array size exceeds VM limit4. ng.OutOfMemoryError: <reason> <stack trace> (Native method)回复次数：1∙∙ luozhangwen ∙(我不懒--押宝党实习生) ∙等 级： ∙ #1楼 得分：0回复于：2010-12-27 16:06:51而在出现内存泄露的机器上，其日志显示是无法创建本地线程的原因所引起的。
这里的异常信息 是：ng.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 threadsMaxProcessMemory 指的是一个进程的最大内存JVMMemory JVM内存ReservedOsMemory 保留的操作系统内存ThreadStackSize 线程栈的大小【解决方法】:针对无法创建更多本地线程的情况，调整线程栈的大小，添加-Xss选项，设置为256k后再跑自动化，发现问题解决。
JAVA_OPTS="-Xms2048M -Xmx2048M -Xmn512M -Xss256k-XX:PermSize=512M….”星期一早上到了公司，据称产品环境抛出了最可爱的异常—OutOfMemory, 它是这样来描述他自己的：ng.OutOfMemoryError: unable to create new native thread而且这位仁兄竟然还堂而皇之地同时出现在了3个application里面，所有应用全部遭殃。
那可爱的OOM是如何产生的呢？直接原因是创建的线程太多了，根本原因是某个地方的内存限制了。
搜罗了一下在网上找到了一个计算公式：(MaxProcessMemory - JVMMemory – ReservedOsMemory) / (ThreadStackSize) = Number of threadsMaxProcessMemory：进程最大的寻址空间，但我想这个值应该也不会超过虚拟内存和物理内存的总和吧。
关于不同系统的进程可寻址的最大空间，可参考下面表格：JVMMemory: Heap + PermGenReservedOSMemory：Native heap，JNI便可推导出单个JVM Instance可支持的最大线程数的估计值：(MaxProcessMemory<固定值> – Xms<初始化值，最小值> – XX:PermSize<初始化值，最小值> – 100m<估算值>) / Xss = Number of threads<最大值>在本地(32bit windows)试了试，可达的线程的最大值差不多就是这个数，它不受物理内存的限制，会利用虚拟内存，从任务管理器看到memory已经是5500 m 左右了（开了两个jvm），我机器的物理内存是2g，也不知道这个准不准，后来还抛出了“unable to create new native thread”的兄弟“Exception in thread "CompilerThread0" ng.OutOfMemoryError: requested 471336 bytes for Chunk::new. Out of swap space?“。
本地测完了后，就该轮到dev环境了，linux2.6，64bit，双核，8G（虚拟机），总的物理内存是16g。
在上面整了一下，创建到了15000多个线程的时候挂掉了。
此时其他application也不能创建新的线程，而且db也报错了，操作系统不能fork新的线程了。
这应该是操作系统的哪里限制了新线程的创建，∙max thread，linux2.6似乎是32000∙最大可用内存：物理内存+虚拟内存∙配置，在linux可以限制可用资源的大小，show一下这些参数为了进一步确定在linux上一个jvm因为达到了最大寻址空间OOM了，不会影响其他jvm，我在Linux做了进一步测试，一开始用Sun文档中说的最大寻址空间3G试了一下，发现根本不对，达到了3G后还是非常high地在创建新的线程。
于是出动超级无敌变态的JVM初始化配置。
结果在create 3379个线程后，“unable to create new native thread”出现了，这时其他jvm都是可以create新线程的。
如果按照上面公式计算，linux 64bit，2.6kernel，它的最大寻址空间肯定超过了300g，当然应该还没有达到可用内存的限制，因为其他JVM还能create新线程。
我还怀疑是不是oracle application server上的某个配置参数限制了总的线程数，影响了所有application，但我们的产品环境一个application就是一个单独的application server。
现在基本上可以确定是操作系统哪里设置错了，我想System team的帅哥们应该把产品环境的某个参数配置错了，系统本身的影响肯定不会有了，因为产品环境上我们只create了800左右个线程，就OOM了，那应该就是配置的问题了，怀疑的参数有下面四个max user processes (-u) 2048virtual memory (kbytes, -v) unlimitedmax memory size (kbytes, -m) unlimitedstack size (kbytes, -s) 10240最后发现只有max user processes 和virtual memory对总的线程数有影响，我把max user processes降到2048后，发现此时只能创建 2000左右个线程了(Xms64m, Xss1m)，进一步地把virtual memory下调到2048000K发现能创建的就更少了1679（Xms64m, Xss1m），而它只会对当前shell起作用，而多个application server应该是不同的shell,所以他是打酱油的。
另外两个参数好像就是来做做俯卧撑的，操作系统stack size是不应该会有什么影响，我们把它上调到102400，还是可以创建2000左右的线程数（max user processes），因为java有自己的线程模型，它的栈的大小是用Xss来控制的。
Max memory size 不知道是啥东东，照理说如果是最大内存应该不会只在旁边做俯卧撑，那这个参数到底是春哥还是曾哥，查了一下man ulimit，有下面解释-a All current limits are reported-c The maximum size of core files created-d The maximum size of a process data segment-f The maximum size of files created by the shell-l The maximum size that may be locked into memory-m The maximum resident set size (has no effect on Linux)-n The maximum number of open file descriptors (most systems do not allow this value to be set)-p The pipe size in 512-byte blocks (this may not be set)-s The maximum stack size-t The maximum amount of cpu time in seconds-u The maximum number of processes available to a single user-v The maximum amount of virtual memory available to the shell“Has no effect on Linux”就足以证明它确实只是来做做俯卧撑的。