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