最大堆长度整理

JVM有一片它自己管理的内存空间。对象存活（或消亡）所在的那部分空间就叫做堆空间。对象在堆空间中创建，又由JVM垃圾收集器在不同的时机围绕着堆空间对其进行迁移。例如，当对堆进行碎片整理（或者紧缩）时，便需要移动对象。对象在堆中也会消亡。一个死去的对象也就是应用程序再也不能访问的对象。JVM垃圾收集器寻找这些死去的对象，并回收这些对象所占用的空间，以便让这些空间能为新的对象所用。如果垃圾收集器无法进一步通过回收死去的对象来释放出空间，那么就说这个堆已满。

一个已满的堆会引发问题。如果堆是满的，而应用程序又试图创建更多的对象，JVM就会向底层操作系统请求更多的内存。如果JVM得不到更多的内存，那么分配一个新对象的这一操作就会抛出OutOfMemoryError异常。除非应用程序极其完善，否则那就意味着该应用程序要崩溃。

那么，对此我们能做点什么呢？大多数JVM都有一个可选的参数，可用于指定堆所能达到的最大长度。如果堆已经达到了这个长度，JVM就不能再向操作系统请求更多的内存。在Sun和IBM最近提供的JVM中，该参数可通过-Xmx选项指定。更老版本的JVM使用的是一个-mx选项，现在大多数JVM还能理解这个选项。应用服务器拥有它们自己的配置参数，可用于指定最大堆长度，这些参数通常是通过-Xmx参数指定的。如果没有显式地使用-Xmx参数，JVM有一个默认的最大堆长度，当然这个默认值是特定于供应商和版本的。Sun1.4JVM提供的最大堆长度的默认值是64兆字节。

那么，为了达到最佳性能，最大堆长度应该为多少呢？您可能会认为“越大越好”，因为这样的话就可以避开out-of-memory错误，并且可以尽量多地为应用程序分配所需的内存。然而，事实证明，如果堆太大的话可能会产生大问题，这是由操作系统的工作方式所致的。现代操作系统有两种内存模式，一种是实（real）内存，一种是虚拟（virtual）内存。虚拟内存可以制造出一种假象，让人认为拥有比实内存更多的内存，这是通过使用交换文件（swapfile）中的磁盘空间补充实内存来办到的，在这里交换文件充当的是一种额外（overflow）内存。操作系统可以调出当前使用不多的页，将它们放在磁盘中，直到需要时才重新调回内存，这样便腾出了实内存（暂时地）以供他用。通过这种方式，可用的内存便表现得比实内存更大，从而允许更多或者更大的进程得以运行。相应的代价就是那些在磁盘中的页在需要时不得不重新调回内存，这样就降慢了速度。毕竟磁盘的速度比起内存来要慢得多。

如果您允许堆比系统的实内存（您机器上的物理内存）还要大的话，那么这个堆就要分页。分页本身没什么问题――毕竟，只是那些不经常使用的页才要被分派到磁盘中。但是，当遇到垃圾收集的时候，由于要对整个堆进行扫描，所有那些很少使用的页又要返回到实内存中，而其他的页则需要被移出实内存，送到磁盘上去，以便为那些老的页腾出空间。这是一个恶性循环，因为被移出到磁盘的页本身在堆中很可能使用得不多，作为垃圾收集的一部分，垃圾收集器要扫描这些页。其结果就是，比起真正要做的有用的事来，您需要花费更多的时间来将页移进和移出内存。

垃圾收集常常是一个应用程序的瓶颈所在。但是，如果您还要让堆大到令操作系统不得不频繁地使用分页技术以便JVM能执行垃圾收集，那么其结果就是一次又一次缓慢的调页动作，从而让应用程序慢如蠕动。因此，务必确保最大堆长度小于可用的系统RAM，要为需要同时运行的其他进程考虑，尽量防止这种调页灾难的发生。