Question

这是运行约10分钟后的输出。

Heap
 PSYoungGen      total 7040K, used 0K [0x24060000, 0x247c0000, 0x26790000)
  eden space 6528K, 0% used [0x24060000,0x24060000,0x246c0000)
  from space 512K, 0% used [0x246c0000,0x246c0000,0x24740000)
  to   space 512K, 0% used [0x24740000,0x24740000,0x247c0000)
 ParOldGen       total 48896K, used 43303K [0x06990000, 0x09950000, 0x24060000)
  object space 48896K, 88% used [0x06990000,0x093d9d80,0x09950000)
 PSPermGen       total 12288K, used 3737K [0x02990000, 0x03590000, 0x06990000)
  object space 12288K, 30% used [0x02990000,0x02d366c0,0x03590000)
[GC [PSYoungGen: 0K->0K(7040K)] 43303K->43303K(55936K), 0.0005129 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
[Full GC (System) [PSYoungGen: 0K->0K(7040K)] [ParOldGen: 43303K->43303K(48896K)] 43303K->43303K(55936K) [PSPermGen: 3737K->3737K(12288K)], 0.1964557 secs] [Times: user=0.36 sys=0.00, real=0.19 secs]

提前致谢

Answer 1

我建议使用JConsole（JDK 1.5+）或jVisualVM（JDK1.6）之类的东西。 printgc的单个输出不足以提供良好的推荐。

通常有两个问题：你创建了太多的新对象，新世代迅速填满，因此gc将所有这些对象移动到Survivor Space甚至Perm Generation。如果发生这种情况（它们会被下一个完整的gc删除，这需要更长时间），我建议增加Young / New代。（-XX：新尺寸）。这允许对象被常规gc取消引用和删除。

如果你确实有许多长寿命的物体，我会检查是否真的有必要。这可能意味着您必须更改代码。

请记住，与小堆相比，大堆需要更长时间才能使用gc。

Answer 2

如果你的内存不足问题不是GC，问题是你使用了太多的对象而没有释放它们。

上次我担心Java的GC是在1998年。

Answer 3

可能与您的应用程序中创建（并且未发布）的太多大型对象有关吗？实际上不了解Java GC，但是来自.NET，大型对象被放置在一个单独的大对象堆上，而不是由GC压缩。在应用程序中，利用繁忙的分配模式，这可能导致LOB上的碎片 - ＆gt;这反过来经常导致那些令人讨厌的OutOfMemory（OOM）异常。此外，LOB集合始终是第2代集合。这意味着，它们很昂贵！因此，干净的解决方案是实现池化。为大型对象实现一个处理模式，并确保它们在使用后被释放到池中。通过从池中回收它们，将它们重新用于新对象。如果你有太多的大量分配，这只会适用。所以你可以先解决这个问题。

我有什么样的gc输出gc调整策略？

3 个答案: