Java 完全GC实时比用户+；系统时代

我们有一个在JBoss上运行的基于Web Java的应用程序，允许的最大堆大小约为1.2 GB（总机器物理内存为2 GB）。在某个时刻，应用程序停止响应（客户端）几分钟。经过分析，我们发现罪魁祸首是全部GC。下面是详细GC日志的摘录：

74477.402:[完整GC[PSYoungGen:3648K->0K（332160K）][PSOldGen:778476K->589497K（819200K）]782124K->589497K（1151360K）[PSPermGen:102671K->102671K（171328K）]，646.1546860秒][次数：用户=3.84系统=3.72，真实=646.17秒

我不明白的是，在完整GC上花费的实时时间大约为11分钟（646秒），而用户+系统时间仅为7.5秒。7.5秒对我来说，花在清洁上的时间要合理得多 其他时间都到哪里去了

您的应用程序很可能导致虚拟内存抖动。基本上，您的应用程序需要的虚拟内存页面远远多于可以容纳它们的物理页面。因此，它将大部分时间花在等待vm页面从光盘读取和写入光盘上

有关更多信息，请阅读

解决方法是减少虚拟内存使用或增加系统上的物理内存量。例如，您可以：

• 在计算机上运行更少的应用程序
• 减少Java应用程序堆大小，或
• 如果在虚拟机中运行，请增加虚拟机的物理内存分配

---

（但是请注意，减小JVM堆大小可能是一把双刃剑。如果将堆大小减小太多，应用程序将要么死于OutOfMemoryErrors，要么花费太多时间进行垃圾收集，要么无法有效缓存内容。）

另一种方法可能是减少长寿命对象，因为短命的物体会被更快地回收利用。例如，对象池在Java.True中是一种糟糕的做法。我把重点放在OP可以很快解决问题的事情上。你确定吗？我希望一个JVM进程在等待一个pagein时在sys=。@eckes-是的，我是。

sys

时间组件是执行系统级代码所花费的CPU时间，而不是等待物理I/O所花费的实时时间。@StephenC我们也遇到了这个问题，但我们根本没有使用交换，也没有看到任何高io效用。你认为可能的原因是什么？