jdk1.7.0中的内存泄漏

Posted 2023-03-06

【中文标题】jdk1.7.0中的内存泄漏

【英文标题】：Memory leak in jdk1.7.0

【发布时间】：2011-12-19 08:40:45

【问题描述】：

我们已经尝试过 jdk 1.7.0_02。运行 10 天，以下对象出现 420 MB 内存泄漏： - java.lang.management.MemoryUsage, - [C（字符数组）， - java.util.HashMap$Entry, - [Ljava.util.HashMap$Entry（HashMap$Entry 数组）， 和其他一些人。

这不会发生在 jdk1.6.x 上。

“jmap -histo:live”命令的第一个输出：

 num     #instances         #bytes  class name
----------------------------------------------
   1:        229527       14926888  [C
   2:        289290       13885920  java.lang.management.MemoryUsage
   3:        321029       10272928  java.util.HashMap$Entry
   4:         69923       10262184  <constMethodKlass>
   5:         69923        9527672  <methodKlass>
   6:          7048        7787040  <constantPoolKlass>
   7:        241693        7734176  java.lang.String
   8:          2038        5898408  [Ljava.util.concurrent.ConcurrentHashMap$HashEntry;
   9:          7048        5479056  <instanceKlassKlass>
  10:          5954        4499552  <constantPoolCacheKlass>
  11:         67844        4091672  [Ljava.util.HashMap$Entry;
  12:         41250        3942848  [B
  13:         65649        3151152  java.util.HashMap
  14:         71891        2875640  java.util.TreeMap$Entry
...
Total       2320965      138000120

“jmap -histo:live”命令的最后一次输出在第一次之后的 10 天内完成：

 num     #instances         #bytes  class name
----------------------------------------------
   1:       3147110      151061280  java.lang.management.MemoryUsage
   2:       3178875      101724000  java.util.HashMap$Entry
   3:       1087332       53822632  [C
   4:       1099503       35184096  java.lang.String
   5:        639442       31529224  [Ljava.util.HashMap$Entry;
   6:        637247       30587856  java.util.HashMap
   7:        629422       25176880  [Ljava.lang.management.MemoryUsage;
   8:        314711       17623816  com.sun.management.GcInfo
   9:         70107       10292776  <constMethodKlass>
  10:        631864       10109824  java.util.HashMap$EntrySet
  11:        314711       10070752  sun.management.GcInfoCompositeData
  12:         70107        9552696  <methodKlass>
  13:          7075        7817080  <constantPoolKlass>
  14:        314713        7554128  [Ljava.lang.Integer;
  15:          2048        5898744  [Ljava.util.concurrent.ConcurrentHashMap$HashEntry;
  16:          7075        5497200  <instanceKlassKlass>
  17:        315792        5052672  java.lang.Integer
  18:         47680        4912352  [B
...
Total      13206419      558217856

我还有 8 个其他直方图，是在每天测试后制作的。它们显示对象的线性数量增加。这绝对不是噪音。这是每天 42 MB 的稳定泄漏。

您是否观察到类似的行为？在什么场景下？你是如何应对的？

【问题讨论】：

-1 没问题；如果这是一个错误报告：联系 Oracle。

@CodeBrickie，问题是 - 你有没有观察到类似的行为？在哪些场景下？你是如何应对的？

【参考方案1】：

鉴于 Java 7 中的代码与 Java 6 略有不同（但几乎相同）。我希望看到这些非常细微的差异。我会在 2 天后拍摄快照，看看 JVM 是否仍在预热。例如，连接更多监控客户端会增加这些值（因为这些主要是监控对象）。

如果是内存泄漏，每两天 32K，这可能会在运行一年后浪费大约 5 MB，并且价值不到 5 美分的内存。我个人认为这太小了，不用担心。

【讨论】：

其实数字之间的差异很小，可以认为是噪声（可能是某个时间点的临时物体）。这些数字几乎不能证明存在内存泄漏。

@Jesper 我怀疑你是对的，这就是为什么需要更多样本（可能每周），如果你认为值得做的话。

@Peter Lawrey，有一个错误。目前，上述两个直方图之间的间隔是 10 分钟，而不是 2 天。我将很快提供间隔非常大的直方图数量。