java 内存溢出

初步了解到这些,待以后详细解决

 

 

 

java.lang.OutOfMemoryError PermGenspace Permanent Generation space

JSP进行precompile的时候。如果你的WEBAPP下都用了大量的第三方jar,

应用有太多的class文件而恰好MaxPermSize设置较小，超出了也会导致这块内存的占用过多造成溢出，

或者tomcat热部署时侯不会清理前面加载的环境，只会将context更改为新部署的，非堆存的内容就会越来越多。

内存中加载的数据量过于庞大，如一次从数据库取出过多数据

  集合类中有对对象的引用，使用完后未清空，使得JVM不能回收；

 代码中存在死循环或循环产生过多重复的对象实体；

使用的第三方软件中的BUG；

 启动参数内存值设定的过小；

java.lang.OutOfMemoryError:Javaheapspace

其默认空间(即-Xms)是物理内存的1/64，最大空间(-Xmx)是物理内存的1/4

如果内存剩余不到40%，JVM就会增大堆到Xmx设置的值，内存剩余超过70%，JVM就会减小堆到Xms设置的值

所以服务器的Xmx和Xms设置一般应该设置相同避免每次GC后都要调整虚拟机堆的大小

那么JVM内存的最大值跟操作系统有关，一般32位机是1.5g到3g之间，而64位的就不会有限制了。

 

如果Xms超过了Xmx值，或者堆最大值和非堆最大值的总和超过了物理内存或者操作系统的最大限制都会引起服务器启动不起来。

 

 

当应用程序线程空闲；另一个是java内存堆不足时，会不断调用GC，若连续回收都解决不了内存堆不足的问题时，

就会报outofmemory错误。因为这个异常根据系统运行环境决定，所以无法预期它何时出现。

根据GC的机制，程序的运行会引起系统运行环境的变化，增加GC的触发机会。

　　为了避免这些问题，程序的设计和编写就应避免垃圾对象的内存占用和GC的开销。

显式调用System.GC()只能建议JVM需要在内存中对垃圾对象进行回收，但不是必须马上回收，

一个是并不能解决内存资源耗空的局面，另外也会增加GC的消耗。

内存查看工具有许多，比较有名的有：Optimizeit Profiler、JProbe Profiler、JinSight

和Java1.5的Jconsole等。它们的基本工作原理大同小异，都是监测Java程序运行时所有对象的申请、

释放等动作，将内存管理的所有信息进行统计、分析、可视化。开发人员可以根据这些信息判断程序是否有内存泄漏问题。

一般来说，一个正常的系统在其启动完成后其内存的占用量是基本稳定的，而不应该是无限制的增长的。

持续地观察系统运行时使用的内存的大小，可以看到在内存使用监控窗口中是基本规则的锯齿形的图线，

如果内存的大小持续地增长，则说明系统存在内存泄漏问题。通过间隔一段时间取一次内存快照，

然后对内存快照中对象的使用与引用等信息进行比对与分析，可以找出是哪个类的对象在泄漏。

 

-server -Xms1024 -Xmx1024m  -XX:PermSize=128M -XX:MaxNewSize=256m -XX:MaxPermSize=256m