在tomcat中配置
set JAVA_OPTS=-Xms1024m -Xmx1024m -verbose:gc -Xloggc:gc.log -XX:+PrintGCDetails -XX:+HeapDumpOnOutOfMemoryError
系统运行两天后出现Unloading class sun.reflect.GeneratedMethodAccessor*，然后系统停止运行了，也没有抛出oom的异常，观察了系统的gc日志，更加的奇怪，前面full gc非常少，最后竟然有一堆的full gc，且时间都非常长，实在是没办法分析系统中，什么地方出现了内存泄露，大家帮忙看看。
问题补充：
我现在的系统属于典型的生产者、消费者系统，所有产生的数据集都是放入到队列中进行处理，这种情况，如果发生堵塞或者处理的效率过低，gc的效果应该是不大的吧，另外，在配置启动参数时，是不是可以设置较大的年轻态space？？
用jmap把停止时的Heap镜像拿出来分析一下看看。
http://www.sun.com/bigadmin/hubs/multilingual/simp_chinese/content/monitoring.jsp
对你应该有帮助。
这文章调优实战
http://www.iteye.com/topic/212967
GC日志应该可以看出内存的消耗规律来的,内存是越来越少还是保持平衡突然出现大量的内存增加,有了这个分析才好定位问题的所在.
越来越少可能是某处对象没有释放.突然变化就要分析引起突然变化的原因,执行了某项操作,还是突然有大量用户涌入.
full gc执行时间长只能说明内存回收的很吃力.也就是当时留给Gc运作的条件有限,如CPU被大量占用或内存几乎没有了,gc运转都吃力.
GC日志分析的好帖子,请参考
[quote]
主题：通过GC输出分析内存泄露问题
http://www.iteye.com/topic/256701[/quote]