一个艰难的java垃圾收集转向我，我真的陷入其中

Question

背景：

我在opensuse13.1 64bitsOS中有一个java Web项目（使用springMVC redis activeMQ等JDK版本：1.7.0_79 64位）。

Tomcat Bootstrap选项为：-Xms8192m -Xmx8192m -XX：PermSize = 256m -XX：MaxPermSize = 256m

GC算法：ParallelGC

情况：

当我通过jstat检查这个项目时：

jstat -gcutil 16782 1s 1000
  S0     S1     E      O      P     YGC     YGCT    FGC    FGCT     GCT   
  ......
  0.00  14.00  74.53  95.53  24.44 199887 11634.417   167  931.848 12566.265
  0.00  14.00  74.53  95.53  24.44 199887 11634.417   167  931.848 12566.265
  0.00  14.00  74.53  95.53  24.44 199887 11634.417   167  931.848 12566.265 
  ......

我发现gc使用的时间太长（每个STW为5.57s），所以我想对此进行一些优化。

这个项目可以运行很长时间，似乎没有内存泄漏（我观察内存占用60天，它不会记忆了）。

首先，我认为可能会过于频繁地分配一些临时对象。

所以我抛弃了两个bin文件：一个是75％的旧空间，一个是gc 57％的旧空间，我用MAT比较这两个文件使用keep unreachable模式和unkeep模式。

伊甸园空间快速增加，每个小的gc都会将一些物体移动到旧空间。

经过分析，我发现了一些令我很困惑的有趣事情： 看来我的代码没有使用这些移动到旧空间的对象，它们都是LinkedHashMap条目，而条目键是一个类文件，值是一个java.io.ExpiringCache $ Entry对象。

我跟踪GC路径，它也没有被我的代码使用（它由java.io.File对象和ContainerBackgroundProcessor [StandardEngine [Catalina]]使用。）

无法到达的物体： LinkedHashMap条目： path2gc

问题：

LinkedHashMap条目和java.io.ExpiringCache $ Entry的目标是什么？

为什么伊甸园空间增长如此之快？

是否有可能使较小的gc扫除这些无法访问的对象但是完整的gc？

请给我一些帮助，非常感谢。

Answer 1

这似乎是G1收集器的一个用例。如果您有许多短暂的物体，伊甸园的增加可能是正常的。尝试设置-XX：+ UseG1GC。这可以收集堆的大部分，STW阶段非常短。