JVM内存模型以及垃圾回收

时间:2022-12-27 07:53:02
以hotspot虚拟机为例
JAVA堆的结构可以用下图来描述:

JVM内存模型以及垃圾回收

内存由 Perm 和 Heap 组成. 其中 Heap = {Old + NEW = { Eden , from, to } }
JVM内存模型中分两大块,一块是 NEW Generation, 另一块是Old Generation.
在New Generation中,有一个叫Eden的空间,主要是用来存放新生的对象。
还有两个Survivor Spaces(from,to), 它们用来存放每次垃圾回收后存活下来的对象。
在Old Generation中,主要存放应用程序中生命周期长的内存对象。
还有个Permanent Generation,有的也叫(方法区),主要用来放类加载器加载的类的类型信息。 垃圾回收描述:
在New Generation块中,垃圾回收一般用Copying的算法,速度快。
每次GC的时候,存活下来的对象首先由Eden拷贝到某个Survivor Space, 
当Survivor Space空间满了后,剩下的live对象就被直接拷贝到Old Generation中去。
因此,每次GC后,Eden内存块会被清空。
在Old Generation块中,垃圾回收一般用mark-compact的算法,速度慢些,但减少内存要求.
垃圾回收分多级,0级为全部(Full)的垃圾回收,会回收OLD段中的垃圾;
1级或以上为部分垃圾回收,只会回收NEW中的垃圾。
内存溢出通常发生于OLD段或Perm段垃圾回收后,仍然没有内存空间容纳新的Java对象的情况。

以一个web应用为例,当一个URL被访问时,不考虑类加载的过程,内存申请过程如下:
A. JVM会试图为相关Java对象在Eden中初始化一块内存区域
B. 当Eden空间足够时,内存申请结束。否则到下一步
C. JVM试图释放在Eden中所有不活跃的对象(这属于1或更高级的垃圾回收), 释放后若Eden空间仍然不足以放入新对象,则试图将部分Eden中活跃对象放入Survivor区
D. Survivor区被用来作为Eden及OLD的中间交换区域,当OLD区空间足够时,
Survivor区的对象会被移到Old区,否则会被保留在Survivor区
E. 当OLD区空间不够时,JVM会在OLD区进行完全的垃圾收集(0级)
F. 完全垃圾收集后,若Survivor及OLD区仍然无法存放从Eden复制过来的部分对象,
导致JVM无法在Eden区为新对象创建内存区域,则出现”out of memory错误”

JVM调优建议:
ms/mx:定义YOUNG+OLD段的总尺寸,ms为JVM启动时YOUNG+OLD的内存大小;
mx为最大可占用的YOUNG+OLD内存大小。
在用户生产环境上一般将这两个值设为相同,以减少运行期间系统在内存申请上所花的开销。
JVM默认在堆内存不足40%的时候会增加到mx设定的值,在堆内存空闲到达70%的时候,会将内存缩小到ms的值。
NewSize/MaxNewSize:定义YOUNG段的尺寸,NewSize为JVM启动时YOUNG的内存大小;
MaxNewSize为最大可占用的YOUNG内存大小。
在用户生产环境上一般将这两个值设为相同,以减少运行期间系统在内存申请上所花的开销。
PermSize/MaxPermSize:定义Perm段的尺寸,PermSize为JVM启动时Perm的内存大小;
MaxPermSize为最大可占用的Perm内存大小。
在用户生产环境上一般将这两个值设为相同,以减少运行期间系统在内存申请上所花的开销。
SurvivorRatio:设置Survivor空间和Eden空间的比例

内存溢出的可能性
1. OLD段溢出
这种内存溢出是最常见的情况之一,产生的原因可能是:
1) 设置的内存参数过小(ms/mx, NewSize/MaxNewSize)
2) 程序问题
单个程序持续进行消耗内存的处理,如循环几千次的字符串处理,对字符串处理应建议使用StringBuffer。
此时不会报内存溢出错,却会使系统持续垃圾收集,无法处理其它请求,相关问题程序可通过ThreadDump获取。
单个程序所申请内存过大,有的程序会申请几十乃至几百兆内存,此时JVM也会因无法申请到资源而出现内存溢出,对此首先要找到相关功能,然后交予程序员修改,要找到相关程序,必须在日志中寻找。
当Java对象使用完毕后,其所引用的对象却没有销毁,使得JVM认为他还是活跃的对象而不进行回收,这样累计占用了大量内存而无法释放。由于目前市面上还没有对系统影响小的内存分析工具,故此时只能和程序员一起定位。
2.Perm段溢出
通常由于Perm段装载了大量的Servlet类而导致溢出,目前的解决办法:
1) 将PermSize扩大,一般256M能够满足要求
2) 若别无选择,则只能将servlet的路径加到CLASSPATH中,但一般不建议这么处理
3. C Heap溢出
系统对C Heap没有限制,故C Heap发生问题时,Java进程所占内存会持续增长,直到占用所有可用系统内存

其他:

JVM有2个GC线程。第一个线程负责回收Heap的Young区。第二个线程在Heap不足时,遍历Heap,将Young 区升级为Older区。Older区的大小等于-Xmx减去-Xmn,不能将-Xms的值设的过大,因为第二个线程*运行会降低JVM的性能。

为什么一些程序频繁发生GC?有如下原因: l        程序内调用了System.gc()或Runtime.gc()。 l        一些中间件软件调用自己的GC方法,此时需要设置参数禁止这些GC。 l        Java的Heap太小,一般默认的Heap值都很小。 l        频繁实例化对象,Release对象。此时尽量保存并重用对象,例如使用StringBuffer()和String()。 如果你发现每次GC后,Heap的剩余空间会是总空间的50%,这表示你的Heap处于健康状态。许多Server端的Java程序每次GC后最好能有65%的剩余空间。 经验之谈: 1.Server端JVM最好将-Xms和-Xmx设为相同值。为了优化GC,最好让-Xmn值约等于-Xmx的1/3[2]。 2.一个GUI程序最好是每10到20秒间运行一次GC,每次在半秒之内完成。 注意: 1.增加Heap的大小虽然会降低GC的频率,但也增加了每次GC的时间。并且GC运行时,所有的用户线程将暂停,也就是GC期间,Java应用程序不做任何工作。 2.Heap大小并不决定进程的内存使用量。进程的内存使用量要大于-Xmx定义的值,因为Java为其他任务分配内存,例如每个线程的Stack等。 3.Stack的设定,每个线程都有他自己的Stack。

-Xss 每个线程的Stack大小

-Xss参数决定Stack大小,例如-Xss1024K。 3.硬件环境 硬件环境也影响GC的效率,例如机器的种类,内存,swap空间,和CPU的数量。 如果你的程序需要频繁创建很多transient对象,会导致JVM频繁GC。这种情况你可以增加机器的内存,来减少Swap空间的使用。 4.4种GC 第一种为单线程GC,也是默认的GC。,该GC适用于单CPU机器。 第二种为Throughput GC,是多线程的GC,适用于多CPU,使用大量线程的程序。第二种GC与第一种GC相似,不同在于GC在收集Young区是多线程的,但在Old区和第一种一样,仍然采用单线程。-XX:+UseParallelGC参数启动该GC。 第三种为Concurrent Low Pause GC,类似于第一种,适用于多CPU,并要求缩短因GC造成程序停滞的时间。这种GC可以在Old区的回收同时,运行应用程序。-XX:+UseConcMarkSweepGC参数启动该GC。 第四种为Incremental Low Pause GC,适用于要求缩短因GC造成程序停滞的时间。这种GC可以在Young区回收的同时,回收一部分Old区对象。-Xincgc参数启动该GC。