当Java程序申请内存，超出VM可分配内纯的时候，ＶＭ首先可能会ＧＣ，如果ＧＣ完还是不够，或者申请的直接超够ＶＭ可能有的，就会抛出内 存溢出异常。从ＶＭ规范中我们可以得到，一下几种异常。

java.lang.StackOverflowError:（很少）
java.lang.OutOfMemoryError：heap space(比较常见)
java.lang.OutOfMemoryError: PermGen space (经常出现)

java.lang.OutOfMemoryError: GC overhead limit exceeded（某项操作使用大量内存时发生）

以下分别解释一下，从最常见的开始：

java.lang.OutOfMemoryError: PermGen space 这个异常比较常见，是说ＪＶＭ里的Perm内 存区的异常溢出，由于JVM在默认的情况下，Perm默认为64M，而很多程序需要大量的Perm区内 存，尤其使用到像Spring等框架的时候，由于需要使用到动态生成类，而这些类不能被GC自动释放，所以导致OutOfMemoryError: PermGen space异常。解决方法很简单，增大JVM的 -XX:MaxPermSize 启动参数，就可以解决这个问题，如过使用的是默认变量通常是64M[5.0 and newer: 64 bit VMs are scaled 30% larger; 1.4 amd64: 96m; 1.3.1 -client: 32m.]，改成128M就可以了，-XX:MaxPermSize=128m。如果已经是128m（Eclipse已经是128m了），就改成 256m。我一般在服务器上为安全起见，改成256m。

java.lang.OutOfMemoryError：heap space或其它OutOfMemoryError，这个异常实际上跟上面的异常是一个异常，但解决方法不同，所以分开来写。上面那个异常是因为JVM的perm区内 存区分少了引起的（JVM的内 存区分为 young,old,perm三种）。而这个异常是因为JVM堆内 存或者说总体分少了。解决方法是更改 -Xms -Xmx 启动参数，通常是扩大1倍。xms是管理启动时最小内 存量的，xmx是管里JVM最大的内 存量的。
注：OutOfMemoryError可能有很多种原因，根据JVM Specification, 可能有一下几种情况，我先简单列出。stack：stack分区不能动态扩展，或不足以生成新的线程。Heap:需要更多的内 存，而不能获得。Method Area :如果不能满足分配需求。runtime constant pool(从Method Area分配内 存)不足以创建class or interface。native method stacks不能够动态扩展，或生成新的本地线程。

java.lang.OutOfMemoryError: GC overhead limit exceeded，这个是JDK6新添的错误类型。这个hotspot VM1.6定义的一个策略，是一种保护机制，通过计算GC时间来预测是否需要OOM了，提前抛出异常，防止OOM的发生，官方的定义是：并行/并发回收器在GC回收时间过长会抛出OutOfMemoryError（过长的定义是超过98%的时间用来GC并回收了不到2%的堆内存，用来避免内存过小造成应用不能正常工作。我在JSP导大Excel的时候碰到过。最终解决方案是，关闭该功能，使用—— -XX:-UseGCOverheadLimit，预测OOM有啥用呢？虽然可能不能最终拯救你的应用，但是可以在挂掉前做最后的挣扎，比如数据保存和保存现场（Heap Dump），当然这个策略会带来比如加载某一个大内存时频繁OOM。加入生产环境遇到这个问题，在不知道原因的情况下不要简单规避这个问题，可以通过-verbose:gc -XX:+PrintGCDetails看一下到底是什么原因造成的异常。通常原因都是因为年老代（old区）占用过多导致频繁FullGC，最终导致GC overhead limit exceed。如果gc log不够可以借助JProfile等工具查看内存占用，old区是否有内存泄漏。。分析内存泄漏有一个方法 -XX:HeapDumpOnOutOfMemoryError， 这样OOM时会自动做Heap Dump，可以拿MAT来排查了。另外留意新生代（young区），如果有过多短暂对象分配，可能也会导致这个异常。

最后说说java.lang.StackOverflowError，老实说这个异常我也没碰见过，但JVM Specification就提一下，规范上说有一下几种境况可能抛出这个异常，一个是Stacks里的线程超过允许的时候，另一个是当native method要求更大的内 存，而超过native method允许的内 存的时候。根据SUN的文档，提高-XX:ThreadStackSize=512的值。

总的来说调优JVM的内 存，组要目的就是在使用内 存尽可能小的，使程序运行正常，不抛出内 纯溢出的bug。而且要调好最小内 存，最大内 存的比，避免GC时浪费太多时间，尤其是要尽量避免FULL GC。

补充：由于JDK1.4新增了nio，而nio的buffer分配内存比较特殊（读写流可以共享内存）。如果有大量数据交互，也可能导致java.lang.OutOfMemoryError。相应的JDK新增了一个特殊的参数：-XX:MaxDirectMemorySize 默认是64M，可以改大些如128M。

-XX:MaxDirectMemorySize=<size>
Specifies the maximum amount of memory in bytes that the Java™ NIO library can allocate for direct memory buffers. The default is 64 megabytes, which corresponds to
-XX:MaxDirectMemorySize=64m . The use of direct memory buffers can minimize the copying cost when doing I/O operations.

当Java程序申请内存，超出VM可分配内纯的时候，ＶＭ首先可能会ＧＣ，如果ＧＣ完还是不够，或者申请的直接超够ＶＭ可能有的，就会抛出内 存溢出异常。从ＶＭ规范中我们可以得到，一下几种异常。

java.lang.StackOverflowError:（很少）
java.lang.OutOfMemoryError：heap space(比较常见)
java.lang.OutOfMemoryError: PermGen space (经常出现)

java.lang.OutOfMemoryError: GC overhead limit exceeded（某项操作使用大量内存时发生）

以下分别解释一下，从最常见的开始：

java.lang.OutOfMemoryError: PermGen space 这个异常比较常见，是说ＪＶＭ里的Perm内 存区的异常溢出，由于JVM在默认的情况下，Perm默认为64M，而很多程序需要大量的Perm区内 存，尤其使用到像Spring等框架的时候，由于需要使用到动态生成类，而这些类不能被GC自动释放，所以导致OutOfMemoryError: PermGen space异常。解决方法很简单，增大JVM的 -XX:MaxPermSize 启动参数，就可以解决这个问题，如过使用的是默认变量通常是64M[5.0 and newer: 64 bit VMs are scaled 30% larger; 1.4 amd64: 96m; 1.3.1 -client: 32m.]，改成128M就可以了，-XX:MaxPermSize=128m。如果已经是128m（Eclipse已经是128m了），就改成 256m。我一般在服务器上为安全起见，改成256m。

java.lang.OutOfMemoryError：heap space或其它OutOfMemoryError，这个异常实际上跟上面的异常是一个异常，但解决方法不同，所以分开来写。上面那个异常是因为JVM的perm区内 存区分少了引起的（JVM的内 存区分为 young,old,perm三种）。而这个异常是因为JVM堆内 存或者说总体分少了。解决方法是更改 -Xms -Xmx 启动参数，通常是扩大1倍。xms是管理启动时最小内 存量的，xmx是管里JVM最大的内 存量的。
注：OutOfMemoryError可能有很多种原因，根据JVM Specification, 可能有一下几种情况，我先简单列出。stack：stack分区不能动态扩展，或不足以生成新的线程。Heap:需要更多的内 存，而不能获得。Method Area :如果不能满足分配需求。runtime constant pool(从Method Area分配内 存)不足以创建class or interface。native method stacks不能够动态扩展，或生成新的本地线程。

java.lang.OutOfMemoryError: GC overhead limit exceeded，这个是JDK6新添的错误类型。这个hotspot VM1.6定义的一个策略，是一种保护机制，通过计算GC时间来预测是否需要OOM了，提前抛出异常，防止OOM的发生，官方的定义是：并行/并发回收器在GC回收时间过长会抛出OutOfMemoryError（过长的定义是超过98%的时间用来GC并回收了不到2%的堆内存，用来避免内存过小造成应用不能正常工作。我在JSP导大Excel的时候碰到过。最终解决方案是，关闭该功能，使用—— -XX:-UseGCOverheadLimit，预测OOM有啥用呢？虽然可能不能最终拯救你的应用，但是可以在挂掉前做最后的挣扎，比如数据保存和保存现场（Heap Dump），当然这个策略会带来比如加载某一个大内存时频繁OOM。加入生产环境遇到这个问题，在不知道原因的情况下不要简单规避这个问题，可以通过-verbose:gc -XX:+PrintGCDetails看一下到底是什么原因造成的异常。通常原因都是因为年老代（old区）占用过多导致频繁FullGC，最终导致GC overhead limit exceed。如果gc log不够可以借助JProfile等工具查看内存占用，old区是否有内存泄漏。。分析内存泄漏有一个方法 -XX:HeapDumpOnOutOfMemoryError， 这样OOM时会自动做Heap Dump，可以拿MAT来排查了。另外留意新生代（young区），如果有过多短暂对象分配，可能也会导致这个异常。

最后说说java.lang.StackOverflowError，老实说这个异常我也没碰见过，但JVM Specification就提一下，规范上说有一下几种境况可能抛出这个异常，一个是Stacks里的线程超过允许的时候，另一个是当native method要求更大的内 存，而超过native method允许的内 存的时候。根据SUN的文档，提高-XX:ThreadStackSize=512的值。

总的来说调优JVM的内 存，组要目的就是在使用内 存尽可能小的，使程序运行正常，不抛出内 纯溢出的bug。而且要调好最小内 存，最大内 存的比，避免GC时浪费太多时间，尤其是要尽量避免FULL GC。

补充：由于JDK1.4新增了nio，而nio的buffer分配内存比较特殊（读写流可以共享内存）。如果有大量数据交互，也可能导致java.lang.OutOfMemoryError。相应的JDK新增了一个特殊的参数：-XX:MaxDirectMemorySize 默认是64M，可以改大些如128M。

-XX:MaxDirectMemorySize=<size>
Specifies the maximum amount of memory in bytes that the Java™ NIO library can allocate for direct memory buffers. The default is 64 megabytes, which corresponds to
-XX:MaxDirectMemorySize=64m . The use of direct memory buffers can minimize the copying cost when doing I/O operations.