java.lang.OutOfMemoryError

本文详细介绍了三种常见的Java内存溢出问题:堆溢出、永久代溢出和栈溢出,并提供了具体的解决方法及JVM参数调整建议。

Java内存溢出详解

 

一、常见的Java内存溢出有以下三种:

 

1. java.lang.OutOfMemoryError: Java heap space ----JVM Heap(堆)溢出
JVM在启动的时候会自动设置JVM Heap的值,其初始空间(即-Xms)是物理内存的1/64,最大空间(-Xmx)不可超过物理内存。

可以利用JVM提供的-Xmn -Xms -Xmx等选项可进行设置。Heap的大小是Young Generation 和Tenured Generaion 之和。

在JVM中如果98%的时间是用于GC,且可用的Heap size 不足2%的时候将抛出此异常信息。

解决方法:手动设置JVM Heap(堆)的大小。  

 

2. java.lang.OutOfMemoryError: PermGen space  ---- PermGen space溢出。 
PermGen space的全称是Permanent Generation space,是指内存的永久保存区域。

为什么会内存溢出,这是由于这块内存主要是被JVM存放Class和Meta信息的,Class在被Load的时候被放入PermGen space区域,它和存放Instance的Heap区域不同,sun的 GC不会在主程序运行期对PermGen space进行清理,所以如果你的APP会载入很多CLASS的话,就很可能出现PermGen space溢出。

解决方法: 手动设置MaxPermSize大小

 

3. java.lang.StackOverflowError   ---- 栈溢出
栈溢出了,JVM依然是采用栈式的虚拟机,这个和C和Pascal都是一样的。函数的调用过程都体现在堆栈和退栈上了。
调用构造函数的 “层”太多了,以致于把栈区溢出了。
通常来讲,一般栈区远远小于堆区的,因为函数调用过程往往不会多于上千层,而即便每个函数调用需要 1K的空间(这个大约相当于在一个C函数内声明了256个int类型的变量),那么栈区也不过是需要1MB的空间。通常栈的大小是1-2MB的。
通常递归也不要递归的层次过多,很容易溢出。

解决方法:修改程序。

 

 

二、解决方法

 

在生产环境中tomcat内存设置不好很容易出现jvm内存溢出。

 

1、 linux下的tomcat:  

修改TOMCAT_HOME/bin/catalina.sh 
在“echo "Using CATALINA_BASE: $CATALINA_BASE"”上面加入以下行: 
JAVA_OPTS="-server -Xms256m -Xmx512m -XX:PermSize=64M -XX:MaxPermSize=128m" 

 

2、 如果tomcat 5 注册成了windows服务,以services方式启动的,则需要修改注册表中的相应键值。

修改注册表HKEY_LOCAL_MACHINE\SOFTWARE\Apache Software Foundation\Tomcat Service Manager\Tomcat5\Parameters\Java,右侧的Options
原值为
-Dcatalina.home="C:\ApacheGroup\Tomcat 5.0"
-Djava.endorsed.dirs="C:\ApacheGroup\Tomcat 5.0\common\endorsed"
-Xrs
加入 -Xms256m -Xmx512m 
重起tomcat服务,设置生效

 

3、如果tomcat 6 注册成了windows服务,或者windows2003下用tomcat的安装版,

在/bin/tomcat6w.exe里修改就可以了 。


 

 

 

4、 如果要在myeclipse中启动tomcat,上述的修改就不起作用了,可如下设置:

Myeclipse->preferences->myeclipse->servers->tomcat->tomcat×.×->JDK面板中的

Optional Java VM arguments中添加:-Xms256m -Xmx512m -XX:PermSize=64M -XX:MaxPermSize=128m

 

 

 

三、jvm参数说明:

 

-server:一定要作为第一个参数,在多个CPU时性能佳 
-Xms:java Heap初始大小。 默认是物理内存的1/64。
-Xmx:java heap最大值。建议均设为物理内存的一半。不可超过物理内存。

 


-XX:PermSize:设定内存的永久保存区初始大小,缺省值为64M。(我用visualvm.exe查看的)

-XX:MaxPermSize:设定内存的永久保存区最大 大小,缺省值为64M。(我用visualvm.exe查看的)

 

-XX:SurvivorRatio=2  :生还者池的大小,默认是2,如果垃圾回收变成了瓶颈,您可以尝试定制生成池设置

 

-XX:NewSize: 新生成的池的初始大小。 缺省值为2M。

-XX:MaxNewSize: 新生成的池的最大大小。   缺省值为32M。

如果 JVM 的堆大小大于 1GB,则应该使用值:-XX:newSize=640m -XX:MaxNewSize=640m -XX:SurvivorRatio=16,或者将堆的总大小的 50% 到 60% 分配给新生成的池。调大新对象区,减少Full GC次数。

 

 

 

 

 

+XX:AggressiveHeap 会使得 Xms没有意义。这个参数让jvm忽略Xmx参数,疯狂地吃完一个G物理内存,再吃尽一个G的swap。 
-Xss:每个线程的Stack大小,“-Xss 15120” 这使得JBoss每增加一个线程(thread)就会立即消耗15M内存,而最佳值应该是128K,默认值好像是512k. 

-verbose:gc 现实垃圾收集信息 
-Xloggc:gc.log 指定垃圾收集日志文件 
-Xmn:young generation的heap大小,一般设置为Xmx的3、4分之一 
-XX:+UseParNewGC :缩短minor收集的时间 
-XX:+UseConcMarkSweepGC :缩短major收集的时间 此选项在Heap Size 比较大而且Major收集时间较长的情况下使用更合适。

-XX:userParNewGC 可用来设置并行收集【多CPU】
-XX:ParallelGCThreads 可用来增加并行度【多CPU】
-XX:UseParallelGC 设置后可以使用并行清除收集器【多CPU】

 

<think>嗯,用户问的是Java中的OutOfMemoryError错误的原因和解决方法。我需要先回忆一下相关的知识,并结合提供的引用内容来组织答案。 首先,根据引用内容,这个错误常见的原因包括JVM内存不足、程序不严谨导致内存泄漏或者对象过多,还有资源未及时释放。比如引用1提到程序不健壮,没有及时释放无用对象;引用2提到JVM内存过小和程序问题;引用4也提到物理内存过小,默认的64MB可能不够用。 接下来需要整理原因部分。常见的原因可能有:堆内存不足、内存泄漏、大对象或过多数据加载、Metaspace/PermGen空间不足、线程过多导致栈溢出、直接内存不足等。引用3提到String太大超过JVM内存,引用5提到用HeapDump参数帮助诊断。 解决方法方面,需要包括调整JVM参数(比如-Xmx)、检查内存泄漏、优化代码、处理大文件或数据分页,以及使用工具分析dump文件。引用1和5都提到了调整JVM参数和分析dump,引用4建议增加内存,引用1还提到释放资源。 然后要确保回答结构清晰,分点列出原因和解决方法。同时用户可能需要相关的问题,比如如何诊断内存泄漏,或者不同内存区域溢出的表现。 需要注意的是,用户可能对JVM内存结构不太熟悉,所以在解释原因时可以简要提及堆、栈、Metaspace等区域。另外,引用中多次提到程序问题,比如死循环、未关闭连接,这些需要强调代码优化的重要性。 最后,生成的相关问题要围绕用户可能进一步想知道的内容,比如具体参数设置、工具使用、不同错误类型等。确保引用标记正确,比如引用1到5的信息要对应到正确的位置。</think>### Java.lang.OutOfMemoryError 原因及解决方案分析 #### 一、核心原因 1. **JVM内存分配不足** - 默认堆内存较小(如64MB),无法满足应用需求[^4] - 未根据业务场景合理设置`-Xmx`(最大堆内存)和`-Xms`(初始堆内存)参数 2. **内存泄漏(Memory Leak)** - 未释放无用对象(如静态集合持续增长)[^1] - 资源未关闭(数据库连接、文件流未释放)[^1] 3. **大对象/过量数据加载** - 一次性加载超大文件到内存(如数GB的CSV文件) - 不合理缓存策略(如使用`String`存储超长文本)[^3] 4. **元空间/Metaspace溢出** - 动态生成大量类(如反射、CGLIB代理) - JVM参数`-XX:MaxMetaspaceSize`设置过小 5. **线程栈溢出** - 线程数量过多(`-Xss`设置过大导致总栈内存超出限制) #### 二、解决方案 **1. JVM参数调优** ```shell # 设置堆内存(生产环境建议4G起步) java -Xms4g -Xmx4g -XX:+HeapDumpOnOutOfMemoryError -jar app.jar ``` - `-XX:+HeapDumpOnOutOfMemoryError`:生成堆转储文件用于分析[^5] - `-XX:MaxMetaspaceSize=256m`:控制元空间上限 **2. 代码优化** - 及时释放资源(使用`try-with-resources`语法) ```java try (Connection conn = dataSource.getConnection(); PreparedStatement ps = conn.prepareStatement(sql)) { // 操作逻辑 } ``` - 避免静态集合滥用(使用WeakHashMap或定期清理) - 分页处理大数据(如流式读取文件) **3. 内存分析工具** - **MAT(Memory Analyzer Tool)**:分析堆转储文件定位泄漏点 - **VisualVM**:实时监控堆/线程/metaspace使用情况 - **jstat**:命令行查看GC统计信息 **4. 架构层面优化** - 引入分布式缓存(Redis/Memcached)替代本地缓存 - 使用内存池技术管理大对象(如ByteBuffer.allocateDirect) #### 三、典型错误场景 | 错误类型 | 表现特征 | 解决方案 | |---------|---------|---------| | `java.lang.OutOfMemoryError: Java heap space` | 堆内存不足 | 增大`-Xmx` + 检查对象生命周期 | | `java.lang.OutOfMemoryError: Metaspace` | 类元数据溢出 | 调整`MaxMetaspaceSize` + 检查类加载器 | | `java.lang.OutOfMemoryError: Requested array size exceeds VM limit` | 数组过大 | 分块处理数据 | | `java.lang.OutOfMemoryError: unable to create new native thread` | 线程数过多 | 减少线程数 + 调整`-Xss` | [^1]: 需通过代码审查确保资源释放 [^4]: JVM参数需根据服务器物理内存合理设置 : 阿里推荐使用HeapDump参数快速定位问题
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

macrobn

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值