最大堆长度整理
JVM 有一片它自己管理的内存空间。对象存活（或消亡）所在的那部分空间就叫做 堆空间。对象在堆空间中创建，又由 JVM 垃圾收集器在不同的时机围绕着堆空间对其进行迁移。例如，当对堆进行碎片整理（或者紧缩）时，便需要移动对象。对象在堆中也会消亡。一个死去的对象也就是应用程序再也不能访问的对象。JVM 垃圾收集器寻找这些死去的对象，并回收这些对象所占用的空间，以便让这些空间能为新的对象所用。如果垃圾收集器无法进一步通过回收死去的对象来释放出空间，那么就说这个堆已 满。
一个已满的堆会引发问题。如果堆是满的，而应用程序又试图创建更多的对象，JVM 就会向底层操作系统请求更多的内存。如果 JVM 得不到更多的内存，那么分配一个新对象的这一操作就会抛出 OutOfMemoryError 异常。除非应用程序极其完善，否则那就意味着该应用程序要崩溃。
那么，对此我们能做点什么呢？大多数 JVM 都有一个可选的参数，可用于指定堆所能达到的最大长度。如果堆已经达到了这个长度，JVM 就不能再向操作系统请求更多的内存。在 Sun 和 IBM 最近提供的 JVM 中，该参数可通过 -Xmx 选项指定。更老版本的 JVM 使用的是一个 -mx 选项，现在大多数 JVM 还能理解这个选项。应用服务器拥有它们自己的配置参数，可用于指定最大堆长度，这些参数通常是通过 -Xmx 参数指定的。如果没有显式地使用 -Xmx 参数，JVM 有一个默认的最大堆长度，当然这个默认值是特定于供应商和版本的。Sun 1.4 JVM 提供的最大堆长度的默认值是 64 兆字节。
那么，为了达到最佳性能，最大堆长度应该为多少呢？您可能会认为“越大越好”，因为这样的话就可以避开 out-of-memory 错误，并且可以尽量多地为应用程序分配所需的内存。然而，事实证明，如果堆太大的话可能会产生大问题，这是由操作系统的工作方式所致的。现代操作系统有两种内存模式，一种是 实（real）内存，一种是 虚拟（virtual）内存。虚拟内存可以制造出一种假象，让人认为拥有比实内存更多的内存，这是通过使用交换文件（swap file）中的磁盘空间补充实内存来办到的，在这里交换文件充当的是一种额外（overflow）内存。操作系统可以调出当前使用不多的页，将它们放在磁盘中，直到需要时才重新调回内存，这样便腾出了实内存（暂时地）以供他用。通过这种方式，可用的内存便表现得比实内存更大，从而允许更多或者更大的进程得以运行。相应的代价就是那些在磁盘中的页在需要时不得不重新调回内存，这样就降慢了速度。毕竟磁盘的速度比起内存来要慢得多。
如果您允许堆比系统的实内存（您机器上的物理内存）还要大的话，那么这个堆就要分页。分页本身没什么问题 ――毕竟，只是那些不经常使用的页才要被分派到磁盘中。但是，当遇到垃圾收集的时候，由于要对整个堆进行扫描，所有那些很少使用的页又要返回到实内存中，而其他的页则需要被移出实内存，送到磁盘上去，以便为那些老的页腾出空间。这是一个恶性循环，因为被移出到磁盘的页本身在堆中很可能使用得不多，作为垃圾收集的一部分，垃圾收集器要扫描这些页。其结果就是，比起真正要做的有用的事来，您需要花费更多的时间来将页移进和移出内存。
垃圾收集常常是一个应用程序的瓶颈所在。但是，如果您还要让堆大到令操作系统不得不频繁地使用分页技术以便 JVM 能执行垃圾收集，那么其结果就是一次又一次缓慢的调页动作，从而让应用程序慢如蠕动。因此，务必确保最大堆长度 小于可用的系统 RAM，要为需要同时运行的其他进程考虑，尽量防止这种调页灾难的发生。 1 楼 jiang_huatao 2009-08-25 不错，学习了。 2 楼 凤舞凰扬 2009-08-27 引用JVM 有一片它自己管理的内存空间。对象存活（或消亡）所在的那部分空间就叫做 堆空间。对象在堆空间中创建，又由 JVM 垃圾收集器在不同的时机围绕着堆空间对其进行迁移。
很多人的 误区，JVM的堆空间和我们常说的对象Heap是不等同的。JVM的堆空间是针对Java.exe这个进程而言的，它还包括PermGen空间，线程分配空间，以及本地方法,NIO的Bufffer等。
引用
例如，当对堆进行碎片整理（或者紧缩）时，便需要移动对象。对象在堆中也会消亡。一个死去的对象也就是应用程序再也不能访问的对象。JVM 垃圾收集器寻找这些死去的对象，并回收这些对象所占用的空间，以便让这些空间能为新的对象所用。如果垃圾收集器无法进一步通过回收死去的对象来释放出空间，那么就说这个堆已 满。
呵呵，死去的对象，不清楚楼主想说明的概念是什么样的。GC在工作时，会先扫描对象引用，对于不存在根引用的对象（或者是基于非强引用的对象）会mark成可回收。如果楼主所说的死去的对象是这个，那么就不存在回收不了。另外，GC不是seek所谓的死去的对象，而是根据算法，搜寻新增的对象（也就是我们常说的MinorGC）或者全部对象（FullGC)。
引用
一个已满的堆会引发问题。如果堆是满的，而应用程序又试图创建更多的对象，JVM 就会向底层操作系统请求更多的内存。如果 JVM 得不到更多的内存，那么分配一个新对象的这一操作就会抛出 OutOfMemoryError 异常。除非应用程序极其完善，否则那就意味着该应用程序要崩溃。
如果你所说的堆(object heap)是不是已经最大长度了，如果是的话，是不会再请求内存的。而堆已满的话，会执行GC，将NewGen中的需要保存的对象移到OldGen中，而无用的对象就会回收释放，如果OldGen已满，就会进行Full GC。
引用
那么，为了达到最佳性能，最大堆长度应该为多少呢？您可能会认为“越大越好”，因为这样的话就可以避开 out-of-memory 错误，并且可以尽量多地为应用程序分配所需的内存。然而，事实证明，如果堆太大的话可能会产生大问题，这是由操作系统的工作方式所致的。现代操作系统有两种内存模式，一种是 实（real）内存，一种是 虚拟（virtual）内存。虚拟内存可以制造出一种假象，让人认为拥有比实内存更多的内存，这是通过使用交换文件（swap file）中的磁盘空间补充实内存来办到的，在这里交换文件充当的是一种额外（overflow）内存。操作系统可以调出当前使用不多的页，将它们放在磁盘中，直到需要时才重新调回内存，这样便腾出了实内存（暂时地）以供他用。通过这种方式，可用的内存便表现得比实内存更大，从而允许更多或者更大的进程得以运行。相应的代价就是那些在磁盘中的页在需要时不得不重新调回内存，这样就降慢了速度。毕竟磁盘的速度比起内存来要慢得多。
绝大多数情况都不会有人把JVM的heapsize设置大于系统内存，即使在32位的桌面系统下，系统的寻址空间是4G，而JVM的大小最多也就2G。设置过大的heap size，会导致JVM的堆空间用于其它部分的不够，而同样出现Out of Memory或者Stack over flow的问题。
引用
如果您允许堆比系统的实内存（您机器上的物理内存）还要大的话，那么这个堆就要分页。分页本身没什么问题 ――毕竟，只是那些不经常使用的页才要被分派到磁盘中。但是，当遇到垃圾收集的时候，由于要对整个堆进行扫描，所有那些很少使用的页又要返回到实内存中，而其他的页则需要被移出实内存，送到磁盘上去，以便为那些老的页腾出空间。这是一个恶性循环，因为被移出到磁盘的页本身在堆中很可能使用得不多，作为垃圾收集的一部分，垃圾收集器要扫描这些页。其结果就是，比起真正要做的有用的事来，您需要花费更多的时间来将页移进和移出内存。
这个其实java进程在操作系统运行中带来的问题，与jvm本身并无关系。楼主关心JVM的设置，更多地应该是从JVM本身的设置出发的。
3 楼 fjlyxx 2009-08-27 引用
这个其实java进程在操作系统运行中带来的问题，与jvm本身并无关系。楼主关心JVM的设置，更多地应该是从JVM本身的设置出发的。
谢谢！
