在《JVM性能悖论：硬件越多 错误越多（上）》中，我们分析了垃圾回收机制如何运作以及内存分配和垃圾回收的性能悖论。下面我们将提供解决方法。

　　内存分配和垃圾回收的性能悖论问题有多糟糕？

　　“你可以选择在300G的内存中运行每一个JVM，如Sun、Hotspot、OpenJDK。之所以没人在上面部署2到3、或4、或6G的东西，是因为JVM会定期暂停或者停止，停止的大小和长度取决于堆栈的大小。所以，2G的JVM，预计大约每隔15秒暂停一次。4G JVM预计半分钟暂停一次。10G JVM大约会90秒暂停一次，” Gil Tene说，他是Azul系统公司首席技术总监兼创始人。

　　当然，最令人烦恼的事情是，在整个环境中，你不能准确地预测出JVM何时停止，只是知道它会终止。

　　“它就像是企业架构中的一个定时炸弹。通常你可以调整JVM使它延后，但是你不能让它消失。所以，你可以使它发生的频率是平时的一半，或者一小时发生一次，但是，它仍然会发生。没有避免Java内存压缩、分裂的方法。这是在Java世界中公认的事实。”

　　人们运行关键的应用程序在做什么？它高度依赖应用程序做的事情。JVM做的工作越多，停止运转的点就会越早到达。

　　“华尔街的人们改变它的大小，使它可以通过一个交易日，但是，如果是一个忙碌的交易日，就会发生在收盘前。没人能够承受应用程序每隔一会就停止一分钟。所以，在不解决垃圾回收的问题时，没有人具有转化10G内存的能力。”

　　整个垃圾回收的问题限制了生产环境上JVM的大小。除了暂停的问题，其他大问题是，如果我们不限制我们堆栈的大小，我们的应用程序会运行的非常、非常的快，甚至JVM偶尔会冻结。

　　“有大量的迹象表明，JVM分配了越多的内存，性能就会越好，运行时也会越快。”

　　所以基本上，我们进入了一个另人讨厌的性能拉据站。实际上，为JVM分配一大块内存，会让你的应用程序运行的更快，并且能更好的利用所有服务器上的资源，包括内存、硬盘和处理器周期。但是，你仍然无法摆脱垃圾回收的问题。

　　解决方案

　　低成本解决方案只是把服务器的内存切成片分给JVM，使每个空间的大小为2、或3G，然后在这上面部署应用程序。你可以在这上面做自己的线性代数，但是这些JVM是浮动的，在你知道之前，管理那五、六百个JVM进程启动到服务器真正把内存托管到你的应用程序上的开销，更不要试图管理那些行为不端的应用程序，或者从一堆日志文件中挖掘数据。

　　GNU GPL授权的JVM可扩展性问题的解决方案？

　　有一些商业的可用的解决方案，但是，也许在这个全行业的提高运行时管理问题中最耀眼的是Azul系统开放提议。管理运行时提议，更具体的说，OpenJDK管理运行时项目（“MRI-J”)，允许发送GNU GPL授权的解决方案到Java运行时问题。

　　“增强的OpenJDK运行时项目演示了高度优化的模块如何在系统堆栈加强接口中实现令人侧目的性能和可扩展性的改进。第一个发布的版本，包含了所有基于OpenJDK 6的增强版本实用的JVM。核心的JVM功能包括减少垃圾回收，提高了两个数量级（100X）的对象分配率（并支持改变堆的大小），显著提高了可扩展性和一致性。”

　　这是一个大胆的、雄心勃勃的项目，它已经得到了Java之父James Gosling的关注和赞同。“看到管理运行时提议我很高兴，Azul建立了开源社区，”James Gosling说，“这个提议有助于把新的功能引入到系统堆栈、释放管理运行时中，以继续他们的成长和演变。”

　　管理运行时提议是新概念，今年6月份刚刚发布。但是，它能解决Java运行时和环境的可扩展性的实际问题，如果我们想有效的利用硬件，这是必不可少的，在现代基于Java的应用程序中也是可用的。