java lang OutOfMemoryError unable to create new native thread内存泄漏分析
outofmemoryerror的5种原因及解决方案
outofmemoryerror的5种原因及解决方案[OutOfMemoryError的5种原因及解决方案]文章长度要求为3000-6000字，属于一篇相对较长的文章，请您谅解在这个自动写作平台上很难一步一步地提供如此详细和完整的答案。
然而，我将尽力为您简要介绍OutOfMemoryError的5种常见原因，并为每种原因提供一些解决方案作为参考。
1. 内存泄漏（Memory Leak）内存泄漏是指在程序运行过程中申请的内存空间没有被正确释放，导致内存不断积累而最终达到内存限制。
常见的内存泄漏情景包括未及时关闭打开的文件或数据库连接、未释放的对象引用、不合理的缓存使用等。
解决方案：- 确保在使用完内存后及时释放资源，如关闭文件或数据库连接。
- 使用弱引用（WeakReference）或软引用（SoftReference）来管理对象，以便垃圾回收器更容易回收不再需要的对象。
- 避免不必要的缓存使用，合理设置缓存的大小和过期时间。
- 使用内存分析工具（如Eclipse Memory Analyzer）检测和修复内存泄漏问题。
2. 不合理的内存分配内存不足可能是由于分配给应用程序的内存空间不足引起的。
这种情况通常发生在需要大量内存的应用程序或者在多个内存密集型应用程序共享同一台机器的情况下。
解决方案：- 增加Java虚拟机的内存限制，使用-Xmx参数调整堆内存大小。
- 优化算法和数据结构，减少内存使用量。
- 避免多个内存密集型应用程序共享同一台机器，尽量将它们部署在不同的服务器上。
3. 过大的内存对象如果程序中存在单个过大的内存对象，它可能会占用大量的堆内存空间，导致OutOfMemoryError。
解决方案：- 对于大型的数据集或者文件，考虑使用流式处理，避免一次性将所有数据加载到内存中。
- 使用分页加载或者分片处理数据，减少内存占用。
4. 递归调用过深递归调用在每次调用时都会产生新的栈帧，而栈空间是有限的，因此如果递归调用过深，就容易导致栈溢出异常，进而触发OutOfMemoryError。
java的oom解决方法
java的oom解决方法Java的OOM（Out of Memory）错误是指在程序运行过程中，JVM（Java Virtual Machine）的堆内存不足以分配对象所需的内存空间，导致程序无法继续执行的错误。
在Java开发中，OOM错误是一个常见的问题，尤其是在处理大数据量、复杂算法或者并发请求等场景下。
为了解决OOM 错误，我们可以采取一系列的措施来优化代码，增加内存的使用效率。
本文将分步介绍如何解决Java的OOM问题。
第一步：找出内存泄漏的原因内存泄漏是造成OOM错误的主要原因之一，因此首先需要找出内存泄漏的具体原因。
我们可以通过一些工具来帮助我们分析程序的内存使用情况，比如使用Java自带的jmap、jstat、jvisualvm等工具，或者使用一些第三方的内存分析工具，比如Eclipse Memory Analyzer等。
这些工具可以帮助我们检测出程序中存在的内存泄漏，并给出相应的提示和建议。
第二步：调整堆内存大小一旦确定了程序存在内存泄漏的问题，我们可以尝试调整JVM的堆内存大小来缓解OOM错误。
默认情况下，JVM的堆内存大小是有限制的，可以通过-Xms和-Xmx参数来指定。
其中，-Xms参数用于指定JVM的初始堆内存大小，-Xmx参数用于指定JVM的最大堆内存大小。
我们可以根据程序对内存的需求，适当调整这些参数的值。
通常情况下，增大堆内存大小能够缓解OOM错误，但也需要注意不要设置得过大，避免浪费资源。
第三步：优化代码逻辑除了调整堆内存大小，我们还可以通过优化代码逻辑来减少内存的占用。
在编写代码的过程中，我们应该尽量避免创建过多的对象，尤其是一些大对象。
例如，在循环中创建对象的操作应该尽量避免，可以考虑将对象的创建操作移到循环外部，或者重用已经创建好的对象。
另外，对于一些大容量的数据结构，如集合类，可以根据实际需求选择合适的集合类型，避免不必要的内存占用。
第四步：优化垃圾回收垃圾回收是JVM中重要的一环，对内存占用的优化有着关键的作用。
Java内存溢出（OOM）异常完全指南
Java内存溢出（OOM）异常完全指南本⽂分析什么情况会导致这些异常出现，提供⽰例代码的同时为您提供解决指南。
Nikita Salnikov-TarnovskiPlumbr Co-Founder and VP of Engineering本⽂内容来源于，对原⽂内容有删减和补充这也许是⽬前最为完整的Java OOM异常的解决指南。
1、ng.OutOfMemoryError:Java heap spaceJava应⽤程序在启动时会指定所需要的内存⼤⼩，它被分割成两个不同的区域：Heap space（堆空间）和Permgen（永久代）：JVM内存模型⽰意图这两个区域的⼤⼩可以在JVM（Java虚拟机）启动时通过参数-Xmx和-XX:MaxPermSize设置，如果你没有显式设置，则将使⽤特定平台的默认值。
当应⽤程序试图向堆空间添加更多的数据，但堆却没有⾜够的空间来容纳这些数据时，将会触发ng.OutOfMemoryError: Java heap space异常。
需要注意的是：即使有⾜够的物理内存可⽤，只要达到堆空间设置的⼤⼩限制，此异常仍然会被触发。
原因分析触发ng.OutOfMemoryError: Java heap space最常见的原因就是应⽤程序需要的堆空间是XXL号的，但是JVM提供的却是S号。
解决⽅法也很简单，提供更⼤的堆空间即可。
除了前⾯的因素还有更复杂的成因：流量/数据量峰值：应⽤程序在设计之初均有⽤户量和数据量的限制，某⼀时刻，当⽤户数量或数据量突然达到⼀个峰值，并且这个峰值已经超过了设计之初预期的阈值，那么以前正常的功能将会停⽌，并触发ng.OutOfMemoryError: Java heap space异常。
内存泄漏：特定的编程错误会导致你的应⽤程序不停的消耗更多的内存，每次使⽤有内存泄漏风险的功能就会留下⼀些不能被回收的对象到堆空间中，随着时间的推移，泄漏的对象会消耗所有的堆空间，最终触发ng.OutOfMemoryError: Java heap space错误。
Java中的OutOfMemoryError和JVM内存结构
转自OutOfMemoryError在开发过程中是司空见惯的，遇到这个错误，新手程序员都知道从两个方面入手来解决：一是排查程序是否有BUG导致内存泄漏；二是调整JVM启动参数增大内存。
OutOfMemoryError有好几种情况，每次遇到这个错误时，观察OutOfMemoryError 后面的提示信息，就可以发现不同之处，如：ng.OutOfMemoryError: Java heap spaceng.OutOfMemoryError: unable to create new native threadng.OutOfMemoryError: PermGen spaceng.OutOfMemoryError: Requested array size exceeds VM limit虽然都叫OutOfMemoryError，但每种错误背后的成因是不一样的，解决方法也要视情况而定，不能一概而论。
只有深入了解JVM的内存结构并仔细分析错误信息，才有可能做到对症下药，手到病除。
JVM规范JVM规范对Jav a运行时的内存划定了几块区域（详见这里），有：JVM栈（Java Virtual Machine Stacks）、堆（Heap）、方法区（Method Area）、常量池（Runtime Constant Pool）、本地方法栈（Native Method Stacks），但对各块区域的内存布局和地址空间却没有明确规定，而留给各JVM厂商发挥的空间。
HotSpot JVMSun自家的HotSpot JVM实现对堆内存结构有相对明确的说明。
按照HotSpot JVM的实现，堆内存分为3个代：Young Generation、Old(Tenured) Generation、Permanent Generation。
众所周知，GC（垃圾收集）就是发生在堆内存这三个代上面的。
Young用于分配新的Java对象，其又被分为三个部分：Eden Space和两块Survivor Space(称为From和To)，Old用于存放在GC过程中从Young Gen中存活下来的对象，Permanent用于存放JVM加载的class等元数据。
OutOfMemoryError_8种典型案例分享
然后在 SpringMVC的拦截器(Interceptor)实现类中, 在 preHandle 方法里, 将 request 对象保存到 ThreadLocal 中:
/** * 登录拦截器 */ public class LoginCheckInterceptor implements HandlerInterceptor { private List<String> excludeList = new ArrayList<String>(); public void setExcludeList(List<String> excludeList) { this.excludeList = excludeList; } private boolean validURI(HttpServletRequest request){ // 如果在排除列表中 String uri = request.getRequestURI(); Iterator<String> iterator = excludeList.iterator(); while (iterator.hasNext()) { String exURI = iterator.next(); if(null != exURI && uri.contains(exURI)){ return true; } } // 可以进行登录和权限之类的判断 LoginUser user = ControllerBase.getLoginUser(request); if(null != user){ return true; } // 未登录,不允许 return false; } private void initRequestThreadLocal(HttpServletRequest request){ ControllerBase.setRequest(request); request.setAttribute("basePath", ControllerBase.basePathLessSlash(request)); } private void removeRequestThreadLocal(){ ControllerBase.setRequest(null); } @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { initRequestThreadLocal(request); // 如果不允许操作,则返回false即可 if (false == validURI(request)) { // 此处抛出异常,允许进行异常统一处理 throw new NeedLoginException(); } return true; } @Override public void postHandle(HttpServletRequest request, HttpServletResponse response, Object handler, ModelAndView modelAndView) throws Exception { removeRequestThreadLocal();
java out of memory解决方法
java out of memory解决方法摘要：1.Java 内存溢出的原因2.Java 内存溢出的后果3.Java 内存溢出的解决方法4.总结正文：一、Java 内存溢出的原因Java 内存溢出是指Java 程序在运行过程中，申请的内存超过了Java 虚拟机（JVM）能够分配的最大内存，导致程序无法正常运行的现象。
Java 内存溢出的原因有很多，以下是一些常见的原因：1.程序中存在大量的对象实例，导致内存占用过高。
2.程序循环过程中，频繁地创建和销毁对象，导致内存分配和回收的开销过大。
3.程序中存在内存泄漏，导致部分内存无法被及时回收。
4.JVM 启动参数配置不合理，导致JVM 分配的内存过小。
二、Java 内存溢出的后果Java 内存溢出会导致程序运行异常，甚至直接崩溃。
严重的内存溢出可能导致JVM 崩溃，进而影响整个系统的稳定性。
此外，内存溢出还会影响程序的性能，导致程序运行速度变慢。
三、Java 内存溢出的解决方法要解决Java 内存溢出的问题，需要从以下几个方面入手：1.优化程序代码- 减少不必要的对象实例，尽量使用局部变量和静态变量。
- 减少循环中对象的创建和销毁，尽量使用对象池技术。
- 定期检查程序内存使用情况，查找内存泄漏问题，并及时修复。
2.合理配置JVM 参数- 调整JVM 启动参数，增加堆内存的大小（-Xmx 参数）。
- 调整垃圾回收器（Garbage Collector, GC）的配置，优化内存回收策略。
3.使用内存分析工具- 使用Java 内存分析工具（如VisualVM、JProfiler 等）分析程序的内存使用情况，找出内存泄漏和瓶颈。
- 根据分析结果，优化程序代码和内存管理策略。
4.调整服务器硬件配置- 提高服务器的内存容量，以满足程序运行所需的内存需求。
- 优化服务器的硬件配置，提高服务器性能，降低内存使用压力。
四、总结Java 内存溢出问题需要综合考虑程序代码、JVM 参数、内存分析工具和服务器硬件配置等多方面因素。
Java.lang.OutOfMemoryError是什么
ng.OutOfMemoryError是什么ng.OutOfMemory是ng.VirtualMachineError的一个子类，当Java虚拟机中断，或是超出可用资源时抛出。
很明显，OutOfMemory是在Java 虚拟机资源耗尽的情况下无法分配对象时抛出的。
不过很不幸，Java的说明文档并没有对该异常进行进一步的阐述。
Java虚拟机包括六个不同的运行时数据区域(内存区域)：1. 程序计数器(Program Counter Register)2. Java虚拟机栈(Java VM Stack)3. Java堆(Heap)4. 方法区(Java VM Method Area)5. 常量池(Runtime Constant Pool)6. 本地方法栈(Native Method Stack)程序计数器又称为PC寄存器，是存放当前正在被执行的Java 字节码操作指令的地址。
（这里加些说明：对于一个运行中的Java 程序而言, 其中的每个线程都有它自己的PC(程序计数器)寄存器，它是在该线程启动时创建的。
PC寄存器的大小是一个字长，因此它既能够持有一个本地指针，也能够持有一个return Address.）Java虚拟机栈是由栈帧（stack frame）组成，帧则是用来存储线程在执行过程中的参数，返回值，以及中间结果等。
如果在没有足够的内存给Java VM栈，或者没足够的内存来生成新的线程时，Java虚拟机将抛出OutOfMemoryError。
Heap是用来存储Java类实例或数组的。
当没有足够的内存给新生实例或数组时，Java虚拟机将抛出OutOfMemoryError。
方法区则是用来存储类型相关的信息, 如该类型的常量池，字段或方法信息。
当方法区没有足够内存时也会出现OutOfMemoryError。
（这里加些说明：类型中的类(静态)变量同样也是存储在方法区中，一个到ClassLoader的引用，一个到Class类的引用）运行时常量池包括字段引用以及常量。
java.lang.OutOfMemoryError
JVM MAX MEMORY: 70M
JVM IS USING MEMORY:1M
String has used memory:768.0k
JVM IS USING MEMORY:5.9375M
MemoryError:ng.OutOfMemoryError
开始JVM使用的内存是1M，当String为768k，JVM使用了5M多时
System.out.println("MemoryError:"+o);
break;
}
}
}
}
然后我ห้องสมุดไป่ตู้用JVM的默认参数执行（我的机器内存是128M）
java testString
结果：
JVM MAX MEMORY: 128M
JVM IS USING MEMORY:1M
String has used memory:12M
case 2: unit = "M"; break;
default : unit = "byte";
}
System.out.println("String has used memory:"+size+unit);
System.out.println("JVM IS USING MEMORY:"+(float)Runtime.getRuntime().totalMemory()/1024/1024+"M");
JVM溢出。
大家还可以改变 -mx参数，来进一步做实验。
以上两个实验证明,String是没有长度限制的，而是有JVM的内存限制了String的长度。同时说明，并不会抛出任何Exception而只会抛出Error.
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
【问题现象】：自动化用例跑了约三个多小时后，界面响应时间长，界面出现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”就足以证明它确实只是来做做俯卧撑的。