我们有一个位于负载均衡器后面的服务器池。该池中的机器每6秒平均进行一次垃圾收集。垃圾收集需要几乎半秒的时间。在垃圾收集期间，我们也看到CPU峰值。Java垃圾回收CPU峰值 - 连接建立时间更长
客户端计算机在平均一次时间内连接到服务器的时间看起来几乎是10％。
理论：CPU忙于执行GC，这就是为什么它无法更快分配连接的原因。
这是一个有效的理论吗？
JVM：IBM GC算法：GENCON 苗圃：5 GB 堆大小：18 GB
我与许多分配所有的赌注都关闭说 - 它会随着时间的推移绝对变得更糟，我这意味着如果你整天每6秒做一次GC，看起来有问题。
您是否有权访问该代码？是否可以重写它以重用对象并更加智能地进行分配？我已经完成了一些嵌入式系统，诀窍是一旦系统启动并运行，就永远不会调用新的系统（如果您可以控制整个系统，那么可以做到这一点）
如果您无权访问代码，检查一些可用的GC调优选项（包括选择使用的垃圾回收器） - 这两种方法都是通过JDK和第三方选项分发的。您可以通过一些命令行修改来提高性能。
我们增加了堆的大小，并且似乎减少了经常发生的CPU峰值。我们正在尝试剖析应用程序，以了解我们在哪里使用这么多的内存。 – 2012-02-02 18:33:34
在循环中寻找“新”，可以实例化整个对象树，只是为了得到一些小部分，然后在下一次迭代中忘记它。一个好的分析器也会有很大的帮助。祝你好运。 – 2012-02-03 16:12:54
这是可能的，我猜。
鉴于垃圾回收是如此密集的过程，是否有任何理由每6秒发生一次？我不熟悉IBM JVM或您正在使用的特定集合算法，因此我无法对这些算法发表评论。但是，Sun提供了一些很好的调整文档（现在由Oracle提供），讨论不同类型的收集器以及何时使用它们。有些想法见this link。
证明理论的一种方法是添加一些代码，记录连接请求的时间以及实际分配的时间。如果GC相关的CPU峰值似乎与分配连接时间较长一致，那么这就证明了你的理论。你的问题将变成如何解决它。
当GC发生时，CPU需要做一些工作，听起来好像有很多GC发生（半秒钟），这很可能是CPU周期。 – Deco 2012-01-11 01:05:08
托儿所GC的时间是1/2秒还是终身？ – AngerClown 2012-01-11 02:00:41
适合苗圃。苗圃一直填满这么快。所以它必须在峰值负载期间每6秒运行一次GC。 – 2012-01-11 13:57:43