博客访问： 42530
博文数量： 7
博客积分： 153
博客等级： 入伍新兵
技术积分： 95
注册时间：
IT168企业级官微
微信号：IT168qiye
系统架构师大会
微信号：SACC2013
分类： Java
最近做毕设时，遇到了一点小问题。在解析dblp.xml文件时（该文件很大，最新版本为977MB），老是报错：java.lang.OutOfMemoryError: Java heap space最后通过查资料才知道，这是由于JVM堆内存不足造成的。JVM在启动动的时候一般会设置JVM Heap的值。其初始空间(即-Xms)是物理内存的1/64，最大空间(-Xmx)不可超过物理内存。在JVM中如果98％的时间是用于GC，且可用的Heap size 不足2％的时候将抛出此异常信息。出现这种问题可以通过修改JVM heap大小解决。如：java -Xms64M -Xmx512M className以上设置JVM初始化堆内存为64M，最大可用堆内存为512M。（1）在命令行中设置的方法就如上面所述。（2）在Eclipse中可以这样设置：在eclipse的 Run->Run Configurations->Arguments下的VM Arguments中设置：-Xms64M -Xmx512M另外可以使用 java -X查看其它JVM参数情况：D:\work>java -X
mixed mode execution (default)
interpreted mode execution only
-Xbootclasspath:
set search path for bootstrap classes and resources
-Xbootclasspath/a:
append to end of bootstrap class path
-Xbootclasspath/p:
prepend in front of bootstrap class path
-Xnoclassgc
disable class garbage collection
enable incremental garbage collection
log GC status to a file with time stamps
disable background compilation
set initial Java heap size
set maximum Java heap size
set java thread stack size
output cpu profiling data
enable strictest checks, anticipating future default
reduce use of OS signals by Java/VM (see documentation)
-Xcheck:jni
perform additional checks for JNI functions
-Xshare:off
do not attempt to use shared class data
-Xshare:auto
use shared class data if possible (default)
-Xshare:on
require using shared class data, otherwise fail.The -X options are non-standard and subject to change without notice.可以通过java.lang.Runtime的一些方法查看jvm的内存使用情况：System.out.println("Total Memory: " + Runtime.getRuntime().totalMemory() / (1024 * 1024 + "MB");System.out.println("Free Memory: " + Runtime.getRuntime().freeMemory() / (1024 * 1024) + "MB");System.out.println("Max Memory: " + Runtime.getRuntime().maxMemory() / (1024 * 1024) + "MB");maxMemory()这个方法返回的是java虚拟机（这个进程）能构从操作系统那里挖到的最大的内存，以字节为单位.totalMemory()这个方法返回的是java虚拟机现在已经从操作系统那里挖过来的内存大小，也就是java虚拟机这个进程当时所占用的所有内存。freeMemory为当前jvm中没有使用的内存。附：jvm参数说明 （转自/blog/1116989）-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】
阅读(4975) | 评论(0) | 转发(0) |
相关热门文章
给主人留下些什么吧！~~
请登录后评论。java内存不足是怎么回事_百度知道
java内存不足是怎么回事
有时下来了一些java软件打开以后就显示“程序因内存不足而退出”是怎么回事、、、怎么解决
我用的是手机
可以把虚似内存加大JAVA在运行时很占内存，2.可以花钱加大物理内存。1，你电脑如果内存比较小的而虚似内存设的小就会不足
其他类似问题
为您推荐：
其他2条回答
在运行java时，或者是，想办法对你的电脑内存进行扩展可能是你的电脑内存太小了
你是用手机？
您可能关注的推广
内存不足的相关知识
等待您来回答
下载知道APP
随时随地咨询
出门在外也不愁Android Studio的JVM内存不足问题怎么解决？
昨天使用AS正常完成了一个小程序，然后从1.2更新到了1.3，结果今天一打开就报错了，试了网上各种办法都没效果，还有网上说的以前设置过的gradle的VM Options现在根本找不到了啊！！&img src=&/88e88f0e47b908eac2bca9d_b.png& data-rawwidth=&785& data-rawheight=&289& class=&origin_image zh-lightbox-thumb& width=&785& data-original=&/88e88f0e47b908eac2bca9d_r.png&&&img src=&/54f78cc70424faa9eeaffe0ba563e56b_b.png& data-rawwidth=&803& data-rawheight=&147& class=&origin_image zh-lightbox-thumb& width=&803& data-original=&/54f78cc70424faa9eeaffe0ba563e56b_r.png&&&br&已经试过设置以下参数，都没用啊！！！阿西吧&br&&img src=&/dc9a01dfa87348ba3fee_b.png& data-rawwidth=&700& data-rawheight=&394& class=&origin_image zh-lightbox-thumb& width=&700& data-original=&/dc9a01dfa87348ba3fee_r.png&&&img src=&/6fb838e72da32a3b51eef_b.png& data-rawwidth=&792& data-rawheight=&316& class=&origin_image zh-lightbox-thumb& width=&792& data-original=&/6fb838e72da32a3b51eef_r.png&&也试过删掉.gradle文件重启，还是不行
昨天使用AS正常完成了一个小程序，然后从1.2更新到了1.3，结果今天一打开就报错了，试了网上各种办法都没效果，还有网上说的以前设置过的gradle的VM Options现在根本找不到了啊！！已经试过设置以下参数，都没用啊！！！阿西吧…
按投票排序
JVM多分点呗
安装目录/bin/idea64(studio).vmoptions设置内存
工具栏-&File-&Invalidate Caches/Restart
我只是想知道怎样限制虚拟机的内存。就像AndroidStudio可以限制它的最大占用内存一样。谁知道方法？！良辰在此先谢过，日后必有重谢!
找到gradle.propreties、打开添加蓝字提示的那句话、直接添加，不要加#符号
楼主你的问题解决了吗，我也遇到了同样的问题
根据我用/写java的经验来看一定有个文件配置jvm内存大小的。基本上无脑设置成当前机器的一般。注意最大内存跟最小设置一样，防止gc浪费时间。
已有帐号？
无法登录？
社交帐号登录java中使用堆外内存，关于内存回收需要注意的事和没有解决的遗留问题(等大神解答)
JVM可以使用的内存分外2种：堆内存和堆外内存，堆内存完全由JVM负责分配和释放，如果程序没有缺陷代码导致内存泄露，那么就不会遇到java.lang.OutOfMemoryError这个错误。使用堆外内存，就是为了能直接分配和释放内存，提高效率。JDK5.0之后，代码中能直接操作本地内存的方式有2种：使用未公开的Unsafe和NIO包下ByteBuffer。
关于Unsafe对象的简介和获取方式，可以参考我的另一篇博客
java获取Unsafe类的实例和取消eclipse编译的错误
使用ByteBuffer分配本地内存则非常简单，直接ByteBuffer.allocateDirect(10 * 1024 * 1024)即可。
C语言的内存分配和释放函数malloc/free，必须要一一对应，否则就会出现内存泄露或者是野指针的非法访问。java中我们需要手动释放获取的堆外内存吗？
1、首先我们看下NIO中提供的ByteBuffer
import java.nio.ByteB
public class TestDirectByteBuffer
// -XX:MaxDirectMemorySize=40M
public static void main(String[] args) throws Exception
while (true)
ByteBuffer buffer = ByteBuffer.allocateDirect(10 * 1024 * 1024); }}}
我们将最大堆外内存设置成40M，运行这段代码会发现：程序可以一直运行下去，不会报OutOfMemoryError。如果使用了-verbose:gc -XX:+PrintGCDetails，会发现程序频繁的进行垃圾回收活动。于是我们可以得出结论：ByteBuffer.allocateDirect分配的堆外内存不需要我们手动释放，而且ByteBuffer中也没有提供手动释放的API。也即是说，使用ByteBuffer不用担心堆外内存的释放问题，除非堆内存中的ByteBuffer对象由于错误编码而出现内存泄露。
2、接下来我们看下直接在方法体中使用Unsafe的效果
import sun.misc.U
public class TestUnsafeMemo
// -XX:MaxDirectMemorySize=40M
public static void main(String[] args) throws Exception
Unsafe unsafe = GetUsafeInstance.getUnsafeInstance();
while (true)
long pointer = unsafe.allocateMemory(1024 * 1024 * 20);
System.out.println(unsafe.getByte(pointer + 1));
// 如果不释放内存,运行一段时间会报错java.lang.OutOfMemoryError
// unsafe.freeMemory(pointer);
}这段程序会报OutOfMemoryError错误，也就是说allocateMemory和freeMemory，相当于C语音中的malloc和free，必须手动释放分配的内存。
3、类似于ByteBuffer，将Unsafe分配内存封装到一个类中
import sun.misc.U
public class ObjectInHeap
private long address = 0;
private Unsafe unsafe = GetUsafeInstance.getUnsafeInstance();
public ObjectInHeap()
address = unsafe.allocateMemory(2 * 1024 * 1024);
// Exception in thread "main" java.lang.OutOfMemoryError
public static void main(String[] args)
while (true)
ObjectInHeap heap = new ObjectInHeap();
System.out.println("memory address=" + heap.address);
这段代码会抛出OutOfMemoryError。这是因为ObjectInHeap对象是在堆内存中分配的，当该对象被垃圾回收的时候，并不会释放堆外内存，因为使用Unsafe获取的堆外内存，必须由程序显示的释放，JVM不会帮助我们做这件事情。由此可见，使用Unsafe是有风险的，很容易导致内存泄露。
4、正确释放Unsafe分配的堆外内存
虽然第3种情况的ObjectInHeap存在内存泄露，但是这个类的设计是合理的，它很好的封装了直接内存，这个类的调用者感受不到直接内存的存在。那怎么解决ObjectInHeap中的内存泄露问题呢？可以覆写Object.finalize()，当堆中的对象即将被垃圾回收器释放的时候，会调用该对象的finalize。由于JVM只会帮助我们管理内存资源，不会帮助我们管理数据库连接，文件句柄等资源，所以我们需要在finalize自己释放资源。
import sun.misc.U
public class RevisedObjectInHeap
private long address = 0;
private Unsafe unsafe = GetUsafeInstance.getUnsafeInstance();
// 让对象占用堆内存,触发[Full GC
private byte[] bytes =
public RevisedObjectInHeap()
address = unsafe.allocateMemory(2 * 1024 * 1024);
bytes = new byte[1024 * 1024];
protected void finalize() throws Throwable
super.finalize();
System.out.println("finalize." + bytes.length);
unsafe.freeMemory(address);
public static void main(String[] args)
while (true)
RevisedObjectInHeap heap = new RevisedObjectInHeap();
System.out.println("memory address=" + heap.address);
我们覆盖了finalize方法，手动释放分配的堆外内存。如果堆中的对象被回收，那么相应的也会释放占用的堆外内存。这里有一点需要注意下：
// 让对象占用堆内存,触发[Full GC
private byte[] bytes =
这行代码主要目的是为了触发堆内存的垃圾回收行为，顺带执行对象的finalize释放堆外内存。如果没有这行代码或者是分配的字节数组比较小，程序运行一段时间后还是会报OutOfMemoryError。这是因为每当创建1个RevisedObjectInHeap对象的时候，占用的堆内存很小（就几十个字节左右），但是却需要占用2M的堆外内存。这样堆内存还很充足（这种情况下不会执行堆内存的垃圾回收），但是堆外内存已经不足，所以就不会报OutOfMemoryError。
虽然改进后的RevisedObjectInHeap不会有堆外内存泄露，但是这种解决方法却无端地浪费了堆内存。简单的看了下ByteBuffer的，它内部分配堆外内存也是通过unsafe.allocateMemory()实现的。那ByteBuffer又是怎么实现的堆外内存释放呢？难道也是通过第4种类似RevisedObjectInHeap的做法吗？欢迎大神指点迷津啊！
(window.slotbydup=window.slotbydup || []).push({
id: '2467140',
container: s,
size: '1000,90',
display: 'inlay-fix'
(window.slotbydup=window.slotbydup || []).push({
id: '2467141',
container: s,
size: '1000,90',
display: 'inlay-fix'
(window.slotbydup=window.slotbydup || []).push({
id: '2467143',
container: s,
size: '1000,90',
display: 'inlay-fix'
(window.slotbydup=window.slotbydup || []).push({
id: '2467148',
container: s,
size: '1000,90',
display: 'inlay-fix'是一个Java类热启动的工具，使Java开发（特别是Web开发）可以实现像PHP开发那样即时刷新的效果，这样再也不用修改java文件之后频繁的去重启Web Server了，用起来非常的顺手。
最近JRebel好像更新也非常频繁，8月份刚发布3.0版本，11月份就发布了3.5版本，而且这个新版本用下来非常给力，针对了spring增加了许多扩展（默认是打开的），比如可以实时更新所有Spring的配置文件等等，手痒痒的同学可以下载下来试试。BTW，我用的是正式版，:)
安装的方法也非常简单，就在vm后面增加一个-noverify 参数：
-noverify -javaagent:E:\UsualTools\JRebel\jrebel.jar
当然还是记得将上面的路径修改成你自己本机JRebl的存放路径。
上面的都不是本文的重点，这里需要说一下的就是，或许3.5版本增加的功能特性太多的缘故（特别是针对Spring），刚开始启动的时候速度非常的慢，开始的时候我怀疑是spring插件的问题，于是使用 -Djrebel.spring_plugin=false将spring插件关闭了，之后启动的速度可以接受了，但是运行程序的时候速度非常非常的慢，点一个按钮要等半天。如果不使用JRebel的话程序运行正常，所以排除了程序本身的问题。
刚开始一直在怀疑是不是新版本的问题，因为用2.x和3.0的时候都很正常，所以在这方面查了很多资料，都没有发现好的解决办法。后来，无意中发现程序出现了“java.lang.OutOfMemoryError: PermGen space”的错误，突然才想到是否是给JRebel分配的内存太小了，于是使用下面的参数增加了内存：
-noverify -javaagent:E:\UsualTools\JRebel\jrebel.jar -Xmx512M -Xms512M -XX:MaxPermSize=1024m
然后在运行的时候发现速度是非一般的快啊，使用JRebel的spring插件之后启动速度也非常的块了，看来就是这个问题，后来在JRebel官方上的Q&A上面也得到了印证。
需要说明一点的是，如果上面的参数无法启动，需要将内存数设置小一些；还有，增加Eclipse的内存对JRebl是没有任何效果的，虽然现在想起来和可笑，但是当时在这个方面也浪费了不少时间。BTW，Eclipse3.3+内置了一个内存查看的工具，可以在“Windows”-“Preferences”中，选择左边的”General”，然后选择右边的”Show heap status”。
参考资料：
Related Posts:
***text***
* Listitem
2016年七月
2016年三月
2016年一月
2015年十月
2015年七月
2015年五月
2015年四月
2015年三月
2014年十二月
2014年八月
2014年七月
2014年五月
2014年二月
2013年十二月
2013年八月
2013年六月
2013年五月
2013年四月
2013年三月
2013年一月
2012年十月
2012年九月
2012年八月
2012年二月
2011年十二月
2011年十月
2011年九月
2011年一月
2010年十二月
2010年十一月
2010年九月
2010年八月
2010年七月
2010年三月
2010年一月
2009年十二月
2009年九月
2009年六月
2009年五月
2009年三月
2009年二月
2008年十月
2008年七月
2008年六月
2008年四月
2008年三月
2008年二月
2008年一月
2007年十二月
2007年十一月
2007年十月
2007年九月
2007年七月
2007年六月
2007年五月
2007年四月
2007年三月
2007年二月
2007年一月
2006年十二月
2006年十一月
2006年十月
2006年九月
2006年八月
2006年七月
2006年六月
2006年五月
2006年四月
2006年三月
&copy Java堂}