Centos RES 内存不断增加并超过 java 的初始和最大内存答案

【问题标题】：Centos RES memory keep increasing and crossed initial and maximum memory for javaCentos RES 内存不断增加并超过 java 的初始和最大内存
【发布时间】：2013-04-03 19:41:33
【问题描述】：

我们有一个在 Centos 6.4 上运行的 java 应用程序，我们注意到 RES 大约为 378m，大于分配的最大值 256m。这是否意味着我们的应用程序正在泄漏？到目前为止，还没有发生 GC，但有很多 YGC？这说明什么？

下面是我的 jstat 结果和 MAT 结果。

Timestamp         S0     S1     E      O      P     YGC     YGCT    FGC    FGCT     GCT   
      2331438.3  56.95   0.00  62.79  82.79  80.37   1362   54.337     0    0.000   54.337
      2331443.3  56.95   0.00  62.79  82.79  80.37   1362   54.337     0    0.000   54.337
      2331448.4  56.95   0.00  62.79  82.79  80.37   1362   54.337     0    0.000   54.337
      2331453.4  56.95   0.00  62.79  82.79  80.37   1362   54.337     0    0.000   54.337
      2331458.4  56.95   0.00  62.79  82.79  80.37   1362   54.337     0    0.000   54.337
      2331463.4  56.95   0.00  62.79  82.79  80.37   1362   54.337     0    0.000   54.337
      2331468.4  56.95   0.00  62.79  82.79  80.37   1362   54.337     0    0.000   54.337
      2331473.4  56.95   0.00  63.24  82.79  80.37   1362   54.337     0    0.000   54.337
      2331478.4  56.95   0.00  63.24  82.79  80.37   1362   54.337     0    0.000   54.337
      2331483.4  56.95   0.00  63.78  82.79  80.37   1362   54.337     0    0.000   54.337
      2331488.4  56.95   0.00  63.78  82.79  80.37   1362   54.337     0    0.000   54.337
      2331493.4  56.95   0.00  63.79  82.79  80.37   1362   54.337     0    0.000   54.337
      2331498.4  56.95   0.00  63.79  82.79  80.37   1362   54.337     0    0.000   54.337
      2331503.4  56.95   0.00  63.79  82.79  80.37   1362   54.337     0    0.000   54.337

MAT成绩

java.lang.ref.Finalizer @ 0xf5e19670 40 92,688 
next java.lang.ref.Finalizer @ 0xf5e1a6a8 40 93,024 
next java.lang.ref.Finalizer @ 0xf5e1bda0 40 122,768 


Suspect 1.

The class "java.lang.ref.Finalizer", loaded by "<system class loader>", occupies 1,337,176 (30.93%) bytes. The memory is accumulated in one instance of "java.lang.ref.Finalizer" loaded by "<system class loader>".

Keywords
java.lang.ref.Finalizer


Suspect 2
 6 instances of "com.mysql.jdbc.JDBC4Connection", loaded by "sun.misc.Launcher$ExtClassLoader @ 0xf58bf000" occupy 432,624 (10.01%) bytes. 

Biggest instances:

•com.mysql.jdbc.JDBC4Connection @ 0xf61c54f8 - 94,864 (2.19%) bytes. 
•com.mysql.jdbc.JDBC4Connection @ 0xf61c4678 - 86,600 (2.00%) bytes. 
•com.mysql.jdbc.JDBC4Connection @ 0xf61c4bf8 - 85,456 (1.98%) bytes. 
•com.mysql.jdbc.JDBC4Connection @ 0xf626c348 - 68,000 (1.57%) bytes. 
•com.mysql.jdbc.JDBC4Connection @ 0xf626c7d0 - 68,000 (1.57%) bytes. 


Keywords
com.mysql.jdbc.JDBC4Connection
sun.misc.Launcher$ExtClassLoader @ 0xf58bf000

【问题讨论】：

标签： java linux garbage-collection

【解决方案1】：

-Xmx 仅限制 JVM 的堆内存空间除了堆空间，JVM 正在为

分配内存

Perm 空间（类元数据）默认高达 64 MiB
线程堆栈（每个线程 256k，可配置）
应用程序显式分配的 I/O 缓冲区和堆外缓冲区

【讨论】：

那么这是 RES 增长的正常行为吗？当你说堆不是我的java程序应该使用堆内存运行？
378MiB for -Xmx256m 似乎足够了。如果它会增长到 1GiB，那很可能是个问题。
Java 代码在堆中运行。但是 JVM 本身正在使用额外的内存。 Java 代码也可以使用 NIO API 在堆外分配内存（尽管这种堆外内存也是有限的）。
在可能的问题发生之前，我是否可以使用 jstat 或任何其他工具进行一些分析，以便在崩溃之前找出问题所在？
JVM 通常会在达到堆限制时崩溃。 RES会大一些，但没关系。您可以使用基于 jstat 或 JMX 的监控来监控堆使用情况。