修改MyEclipse/eclipse文件夹中配置文件eclipse.ini中的内存分配就哦了&===================================&一般的ini文件设置主要包括以下几项：-vmargs-Xms40m-Xmx256m-XX:PermSize=64M-XX:MaxPermSize=128M以下解释其意思。-vmargs：说明后面是VM的参数-Xms40m：虚拟机占用系统的最小内存-Xmx256m：虚拟机占用系统的最大内存-XX:PermSize：最小堆大小。一般报内存不足时,都是说这个太小,&&&&&&&&&&&&&&&&&&&&&& 堆空间剩余小于5%就会警告,建议把这个稍微设&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& 大一点,不过要视自己机器内存大小来设置-XX:MaxPermSize：最大堆大小。这个也适当大些&&&& 所以若出现问题，首先请调整 -Xms40m：将其设置的小一些，就ok了，1g内存推荐设置为：-vmargs-Xms128M-Xmx512M-XX:PermSize=256M-XX:MaxPermSize=512M其中-XX:PermSize=64M可以设置大一些，但不能超过MaxPermSize-Xmx512M的5%为25.6M，理论上要求-Xmx的数值与-XX:MaxPermSize必须大于25.6M===================================最终还是要看你机器的具体配置了&参考一下下面的文章在配置吧
Eclipse文件夹下有个Eclipse.ini文件
Views(...) Comments()1223人阅读
java的最大好处是自动垃圾回收，这样就无需我们手动的释放对象空间了，但是也产生了相应的负效果，gc是需要时间和资源的，不好的gc会严重影响系统的系能，因此良好的gc是JVM的高性能的保证。JVM堆分为新生代，旧生代和年老代，新生代可用的gc方式有：串行gc（Serial Copying），并行回收gc(Parellel Scavenge)，并行gc(ParNew)，旧生代和年老代可用的gc方式有串行gc(Serial MSC),并行gc(Parallel MSC)，并发gc（CMS）。
回收方式的选择
jvm有client和server两种模式，这两种模式的gc默认方式是不同的：
client模式下，新生代选择的是串行gc，旧生代选择的是串行gc
server模式下，新生代选择的是并行回收gc，旧生代选择的是并行gc
一般来说我们系统应用选择有两种方式：吞吐量优先和暂停时间优先，对于吞吐量优先的采用server默认的并行gc方式，对于暂停时间优先的选用并发gc（CMS）方式。
CMS，全称Concurrent Low Pause Collector，是jdk1.4后期版本开始引入的新gc算法，在jdk5和jdk6中得到了进一步改进，它的主要适合场景是对响应时间的重要性需求大于对吞吐量的要求，能够承受垃圾回收线程和应用线程共享处理器资源，并且应用中存在比较多的长生命周期的对象的应用。CMS是用于对tenured generation的回收，也就是年老代的回收，目标是尽量减少应用的暂停时间，减少full gc发生的几率，利用和应用程序线程并发的垃圾回收线程来标记清除年老代。在我们的应用中，因为有缓存的存在，并且对于响应时间也有比较高的要求，因此希望能尝试使用CMS来替代默认的server型JVM使用的并行收集器，以便获得更短的垃圾回收的暂停时间，提高程序的响应性。
CMS并非没有暂停，而是用两次短暂停来替代串行标记整理算法的长暂停，它的收集周期是这样：
初始标记(CMS-initial-mark) -& 并发标记(CMS-concurrent-mark) -& 重新标记(CMS-remark) -& 并发清除(CMS-concurrent-sweep) -&并发重设状态等待下次CMS的触发(CMS-concurrent-reset)。
其中的1，3两个步骤需要暂停所有的应用程序线程的。第一次暂停从root对象开始标记存活的对象，这个阶段称为初始标记；第二次暂停是在并发标记之后，暂停所有应用程序线程，重新标记并发标记阶段遗漏的对象（在并发标记阶段结束后对象状态的更新导致）。第一次暂停会比较短，第二次暂停通常会比较长，并且 remark这个阶段可以并行标记。
而并发标记、并发清除、并发重设阶段的所谓并发，是指一个或者多个垃圾回收线程和应用程序线程并发地运行，垃圾回收线程不会暂停应用程序的执行，如果你有多于一个处理器，那么并发收集线程将与应用线程在不同的处理器上运行，显然，这样的开销就是会降低应用的吞吐量。Remark阶段的并行，是指暂停了所有应用程序后，启动一定数目的垃圾回收进程进行并行标记，此时的应用线程是暂停的。
full gc是对新生代，旧生代，以及持久代的统一回收，由于是对整个空间的回收，因此比较慢，系统中应当尽量减少full gc的次数。
如下几种情况下会发生full gc：
Gc日志参数
通过在tomcat启动脚本中添加相关参数生成gc日志
Opentsdb打开Gc参数
GCARGS=&-XX:+PrintGCDetails
-XX:+PrintGCTimeStamps -XX:+PrintGCDateStamps\
&-XX:+PrintTenuringDistribution
-Xloggc:/tmp/tsd-gc-`date
+%s`.log&
-t 0; then
FIX_DNS='-Dsun.net.inetaddr.ttl=600'
JVMARGS=&$JVMARGS
$GCARGS $FIX_DNS&
常用JVM参数
分析gc日志后，经常需要调整jvm内存相关参数，常用参数如下
下面对如下的参数进行分析：
JAVA_OPTS=&-server -Xms2000m -Xmx2000m -Xmn800m -XX:PermSize=64m -XX:MaxPermSize=256m -XX:SurvivorRatio=4
-verbose:gc -Xloggc:$CATALINA_HOME/logs/gc.log
-Djava.awt.headless=true
-XX:+PrintGCTimeStamps -XX:+PrintGCDetails
-Dsun.rmi.dgc.server.gcInterval=600000 -Dsun.rmi.dgc.client.gcInterval=600000
-XX:+UseConcMarkSweepGC -XX:MaxTenuringThreshold=15&
Xms，即为jvm启动时得JVM初始堆大小,Xmx为jvm的最大堆大小，xmn为新生代的大小，permsize为永久代的初始大小，MaxPermSize为永久代的最大空间。
SurvivorRatio为新生代空间中的Eden区和救助空间Survivor区的大小比值，默认是32，也就是说Eden区是 Survivor区的32倍大小，要注意Survivo是有两个区的，因此Surivivor其实占整个young genertation的1/34。调小这个参数将增大survivor区，让对象尽量在survitor区呆长一点，减少进入年老代的对象。去掉救助空间的想法是让大部分不能马上回收的数据尽快进入年老代，加快年老代的回收频率，减少年老代暴涨的可能性，这个是通过将-XX:SurvivorRatio
设置成比较大的值（比如65536)来做到。
将虚拟机每次垃圾回收的信息写到日志文件中，文件名由file指定，文件格式是平文件，内容和-verbose:gc输出内容相同。
Headless模式是系统的一种配置模式。在该模式下，系统缺少了显示设备、键盘或鼠标。
设置gc日志的格式
指定rmi调用时gc的时间间隔
采用并发gc方式，经过15次minor gc 后进入年老代
一些常见问题
Prommotion failed的日志输出大概是这样：
[ParNew (promotion failed): 320138K-&3920K), 0.2365970 secs]: [CMS: 1139969K-&1120688K( 166784K), 9.2214860 secs] 1458785K-&20704K), 9.4584090 secs]
这个问题的产生是由于救助空间不够，从而向年老代转移对象，年老代没有足够的空间来容纳这些对象，导致一次full gc的产生。解决这个问题的办法有两种完全相反的倾向：增大救助空间、增大年老代或者去掉救助空间。
Concurrent mode failed的日志大概是这样的：
(concurrent mode failure): 1228795K-&28800K), 7.6748280 secs] 1911483K-&11488K), [CMS Perm : 225407K-&2144K)], 7.6751800 secs]
问题的产生原因是由于CMS回收年老代的速度太慢，导致年老代在CMS完成前就被沾满，引起full gc，避免这个现象的产生就是调小-XX:CMSInitiatingOccupancyFraction参数的值，让CMS更早更频繁的触发，降低年老代被沾满的可能。
Gc日志分析工具
直接点击gchisto.jar就可以运行，点add载入gc.log
统计了总共gc次数，youngGC次数，FullGC次数，次数的百分比，GC消耗的时间，百分比，平均消耗时间，消耗时间最小最大值等
GCLogViewer
点击run.bat运行
整个过程gc情况的趋势图，还显示了gc类型，吞吐量，平均gc频率，内存变化趋势等
Tools里还能比较不同gc日志:
工具很强大，但只能打开由以下参数生成的GC log， -verbose:gc -Xloggc:gc.log,添加其他参数生成的gc.log无法打开。
这个工具用的挺多的，但只能在JDK1.5以下的版本中运行，1.6以后没有对应。
garbagecat
其它监控方法
Jvisualvm动态分析jvm内存情况和gc情况，插件：visualGC
jvisualvm还可以heapdump出对应hprof文件（默认存放路径：监控的服务器 /tmp下），利用相关工具，比如HPjmeter可以对其进行分析
grep Full gc.log粗略观察FullGC发生频率
jstat –gcutil [pid] [intervel] [count]
jmap -histo pid可以观测对象的个数和占用空间
jmap -heap pid可以观测jvm配置参数，堆内存各区使用情况
如果要分析的dump文件很大的话，就需要很多内存，很容易crash。
所以在启动时，我们应该加上一些参数： Java –Xms512M –Xmx1024M –Xss8M
参考资料：
探秘Java虚拟机——内存管理与垃圾回收
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：32532次
排名：千里之外
原创：23篇
转载：51篇
(1)(2)(1)(1)(5)(4)(6)(1)(1)(7)(1)(1)(2)(1)(1)(1)(2)(1)(3)(1)(2)(2)(2)(3)(1)(4)(1)(1)(6)(1)(2)(6)(1)【jvm深入了解的高手回答下啊】jvm Perm区gc回收问题
[问题点数：40分，结帖人fhqibjg]
【jvm深入了解的高手回答下啊】jvm Perm区gc回收问题
[问题点数：40分，结帖人fhqibjg]
不显示删除回复
显示所有回复
显示星级回复
显示得分回复
只显示楼主
相关推荐：
匿名用户不能发表回复！|
每天回帖即可获得10分可用分！小技巧：
你还可以输入10000个字符
(Ctrl+Enter)
请遵守CSDN，不得违反国家法律法规。
转载文章请注明出自“CSDN（www.csdn.net）”。如是商业用途请联系原作者。Perm Generation OOM，并请教关于 jmap -permstat 的输出内容 - 高级语言虚拟机 - ITeye群组
服务Perm Gen OOM了
jmap -heap 20598 发现 Perm Generation 使用量持续增长
翻看过相关资料，标记为dead后将被GC回收，但是我触发Full GC后，jmap -permstat 20598 的输出片段中，仍然有大量DelegatingClassLoader标记为dead
0xfe628&&&&& 2&&&&&& 3472&&& 0xc1370&&&&& dead&&& sun/reflect/DelegatingClassLoader@0x7700
0x81a0&&&&& 1&&&&&& 3088&&& 0x8088&&&&& dead&&& sun/reflect/DelegatingClassLoader@0x7700
0xeb7d28&&&&& 1&&&&&& 3088&&& 0xead9a8&&&&& dead&&& sun/reflect/DelegatingClassLoader@0x7700
0xacf0&&&&& 1&&&&&& 3088&&& 0x6ea8&&&&& dead&&& sun/reflect/DelegatingClassLoader@0x7700
0xa3e8&&&&& 2&&&&&& 3488&&& 0xc1370&&&&& dead&&& sun/reflect/DelegatingClassLoader@0x7700
0xe1870&&&&& 1&&&&&& 3088&&& 0xc1370&&&&& dead&&& sun/reflect/DelegatingClassLoader@0x7700
0x41e0&&&&& 1&&&&&& 3088&&& 0x4138&&&&& dead&&& sun/reflect/DelegatingClassLoader@0x7700
0x10e8&&&&& 2&&&&&& 3488&&& 0xc1370&&&&& dead&&& sun/reflect/DelegatingClassLoader@0x7700
比较困惑 Perm Generation 中的对象回收策略具体是什么
谁来解答下啊.我也遇到了相同的问题,头疼啊.查看dump信息.10万多的DelegatingClassLoader.FGC也不回收怎么办?
查到个连接,有需要的自己看下把
JDK的一个bug
nothingismao 写道查到个连接,有需要的自己看下把
/bugdatabase/view_bug.do?bug_id=4957990
JDK的一个bug
您说的是个非常老的bug了。相信只要您在用最新的JDK6或者JDK7都不会碰到它。
而如果您以及是在用最新的JDK6/7但还是遇到这种问题，那多半就不是这个bug。这个bug的成因是HotSpot VM在运行时收集的profile信息（称为methodDataOop或者MDO）有可能持有对klassOop，而之前某些老版本里MDO被当作强引用的根，所以出现了内存泄漏的问题。那个bug已经修好了。
long.xie 写道0xfe628&&&&& 2&&&&&& 3472&&& 0xc1370&&&&& dead&&& sun/reflect/DelegatingClassLoader@0x7700
jmap -permstat功能由Serviceability Agent（SA）的PermStat类实现，源码可以参考这里：
（JDK7u版）
可见标记ClassLoader的死活用的是RevPtrs。而SA的RevPtrs其实并不保证覆盖所有引用，所以它说是dead其实不一定真的是dead（虽然真的是dead的可能性很高）。这个得具体情况具体分析。关于RevPtrs的使用例子，可以参考我之前的一篇笔记：
还是得先问您用的JDK版本是什么，启动参数是什么。
long.xie 写道比较困惑 Perm Generation 中的对象回收策略具体是什么
PermGen通常随着Full GC回收。使用CMS（-XX:+UseConcMarkSweepGC）时，如果打开了-XX:+CMSClassUnloadingEnabled，那么在CMS并发收集周期中也会有一个阶段收集PermGen。跟普通Java对象一样，PermGen里的对象也是要在没有活的强引用、足够强度的弱引用所引用的时候才可以回收。
类对象比较特别，一个ClassLoader实例加载的所有类都死掉的时候，这个ClassLoader及其加载的所有类才可以一起死掉。所以说一个类要死掉的话，必须有：
1、这个类已经没有任何活的实例；
2、这个类自身没有被别的地方引用（主要是指这个类对应的java.lang.Class对象不能被别的活引用所引用）；
3、这个类的ClassLoader及其所加载的所有其它类都没有被活引用所引用（注意这里对同一ClassLoader加载的其它所有类都要满足上面两条）
条件还挺苛刻的嗯。
nothingismao 写道查看dump信息.10万多的DelegatingClassLoader
出现大量DelegatingClassLoader意味着您在大量使用反射调用不同的方法。请参考我之前写的关于JDK反射调用的笔记：
nothingismao 写道FGC也不回收怎么办?
如果接连触发两次full GC都啥也回收不掉的话那问题是比较严重。
要从外部连续触发两次full GC的话，可以从外部执行两次jmap -histo:live。
多谢 RednaxelaFX 的恢复，已经被这个问题折腾的死去活来了。
引用还是得先问您用的JDK版本是什么，启动参数是什么。
JDK版本：Java(TM) SE Runtime Environment (build 1.6.0_31-b05)
启动参数：-Xms4069m -Xmx8192m& -XX:PermSize=512m -XX:MaxPermSize=1024m -XX:NewSize=128m -Xss256k -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:MaxNewSize=128m -XX:SurvivorRatio=8 -Xdebug
使用Tomcat5.5作为服务容器，有JSP也有FLEX
运行状况，在服务启动的前几天PermSize空间在200M~350M之间波动，FGC有效，但时间长了以后发现PermSize一直增长FGC无法回收。
nothingismao 写道启动参数：-Xms4069m -Xmx8192m& -XX:PermSize=512m -XX:MaxPermSize=1024m -XX:NewSize=128m -Xss256k -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:MaxNewSize=128m -XX:SurvivorRatio=8 -Xdebug
请把PermSize和MaxPermSize设到同一个值。CMS有个bug在OpenJDK里还没修好，在PermSize和MaxPermSize不一样的时候会出问题。
RednaxelaFX 写道
请把PermSize和MaxPermSize设到同一个值。CMS有个bug在OpenJDK里还没修好，在PermSize和MaxPermSize不一样的时候会出问题。
之前就是设置-XX:PermSize=512m -XX:MaxPermSize=512m 的因为Perm发生OOM才将 Max调大的。
之前JDK没贴全
java version "1.6.0_31"
Java(TM) SE Runtime Environment (build 1.6.0_31-b05)
Java HotSpot(TM) 64-Bit Server VM (build 20.6-b01, mixed mode)
使用的是sun的jdk
此问题已解决,问题的现象是YGC过于频繁,导致无法进入Perm空间的回收事件.原来系统YGC的频率为1.5一次.调整年轻代空间后,YGC的频率达到30秒一次,Perm空间的回收也变正常了.