jdk1.7.0中内存泄漏

发布于 2024-12-21 21:20:02 字数 2667 浏览 0 评论 0原文

我们尝试过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。

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

We've tried jdk 1.7.0_02. Ten days of running give 420 MB memory leak of the following objects:

- java.lang.management.MemoryUsage,

- [C (array of char),

- java.util.HashMap$Entry,

- [Ljava.util.HashMap$Entry (array of HashMap$Entry),

and some others.

This doesn't happen on jdk1.6.x.

First output of the "jmap -histo:live" command:

 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

The last output of the "jmap -histo:live" command done in 10 days after the first:

 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

I also have 8 other histograms, made after each day of the tests. They show linear number of objects increasing. This is definitely not a noise. It is a stable leak 42 MB per day.

Did you observe similar behavior? In what scenarios? How did you cope with it?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

漆黑的白昼 2024-12-28 21:20:02

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

如果是内存泄漏,每两天 32K,运行一年后可能会浪费约 5 MB,而内存价值不到 5 美分。就我个人而言,我认为这太小了,无需担心。

Given the code in Java 7 is slightly different (but almost the same) as Java 6. I would expect to see these very subtle differences. I would take the snapshot after another 2 days to see if the JVM is still warming up. Connecting more monitoring clients would increase these values for example (as these are mostly monitoring objects).

If it is a memory leak, at 32K every two days, this could be wasting ~5 MB after a year of running and worth less than 5 cents of memory. Personally I would consider this too small to worry about.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文