JAVA堆的结构可以用下图来描述：
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大小 |