我们的负载测试我们的DEV环境设计的Java应用程序1.6。 JVM堆分配是2GB，-Xms2048m -Xmx2048m。 在负载测试，应用程序运行流畅，绝不会比堆1.25GB使用更多的，和垃圾回收是完全正常的。
在我们的UAT环境下，我们运行具有相同参数的负载测试，唯一的区别就是JVM，它的分配4GB，-Xms4096m -Xmx4096m，否则，硬件是完全与DEV相同。 但负载测试中，性能是可怕的，应用程序消耗了几乎整个堆和垃圾收集猖獗。
我们一遍又一遍的运行这些测试，消除了可能影响性能的所有可能出现的症状，但结果是一样的。 在什么情况下可以这样的话？
罪魁祸首可能是垃圾收集，正常的“头痛医头的世界”型集合给我们造成了一些性能问题; 服务器软件运行速度非常慢，但服务器的负载也很低。 最后，我们发现，有一个单一的“头痛医头的世界” -garbage收集线程阻碍了整个软件运行在某些情况下（操作产生的垃圾负载）所有的时间。
移动到并发垃圾回收缓解了问题，启动参数-XX:+UseParallelOldGC -XX:ParallelGCThreads=8 。 我们使用的测试和生产的“唯一”的2GB堆，但它也是值得指出的是，时间的GC花费的金额上升较大的堆（即使你从来没有软件的实际使用全部的话）的。
你可能想了解更多关于不同的垃圾收集-options和调整从这里： Java SE 6的热点[TM]虚拟机垃圾收集调优 。
此外，在这个问题的答案可以提供一些帮助： Java的非常大的堆大小 。
也有一些是在生产和UAT环境的应用程序不同。
从症状上看，它是（IMO）不可能是一个硬件，操作系统性能调整或在JVM版本的差异。 不言而喻，这是不太可能是由于其应用更多的内存。
（这是不难想象，你的应用程序可能会做一些奇怪的事情...等的施胶基础上，最大堆大小一些数据结构，并得到了算盘打错了，但我想你会意识到这种可能性，所以让我们暂时忽略它。）
这可能与在OS环境的差异; 例如，不同版本的操作系统或某些应用程序，在网络的不同，在不同的语言环境，等等的。 但底线是，它是99％一定会出现在你的应用程序内存泄漏时对UAT运行，而内存泄漏是什么嚼起来堆内存和超载的GC。
我的建议是把这个作为存储泄漏问题，并使用标准工具/技术来跟踪问题的原因。 在这个过程中，你将最有可能能够找出为什么这个只发生在你的UAT。
这将是值得来分析两个堆转储这些机器并理解不同消费堆中的这2个环境。 直方图会有所帮助。
