这些java本机内存从哪里分配? [英] Where do these java native memory allocated from?

查看:137
本文介绍了这些java本机内存从哪里分配?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

JDK版本是热点8u_45

JDK version is hotspot 8u_45

我研究了我的java进程的本机内存。本机内存甚至比堆消耗更多空间。然而,有许多本机内存块让我感到困惑。例如pmap -x的结果:

I researched native memory of my java process. The native memory even consumes more space than heap. However there are many native memory blocks which confuses me. The result of pmap -x for example:

00007f8128000000   65508   25204   25204 rw---    [ anon ]
00007f812bff9000      28       0       0 -----    [ anon ]
00007f812c000000   65508   24768   24768 rw---    [ anon ]
00007f812fff9000      28       0       0 -----    [ anon ]
00007f8130000000   65508   25532   25532 rw---    [ anon ]
00007f8133ff9000      28       0       0 -----    [ anon ]
00007f8134000000   65524   22764   22764 rw---    [ anon ]
00007f8137ffd000      12       0       0 -----    [ anon ]
00007f8138000000   65508   26456   26456 rw---    [ anon ]
00007f813bff9000      28       0       0 -----    [ anon ]
00007f813c000000   65508   23572   23572 rw---    [ anon ]
00007f813fff9000      28       0       0 -----    [ anon ]
00007f8140000000   65520   23208   23208 rw---    [ anon ]
00007f8143ffc000      16       0       0 -----    [ anon ]
00007f8144000000   65512   23164   23164 rw---    [ anon ]
00007f8147ffa000      24       0       0 -----    [ anon ]
00007f8148000000   65516   23416   23416 rw---    [ anon ]
00007f814bffb000      20       0       0 -----    [ anon ]
00007f814c000000   65508   23404   23404 rw---    [ anon ]
00007f814fff9000      28       0       0 -----    [ anon ]
00007f8150000000   65512   24620   24620 rw---    [ anon ]
00007f8153ffa000      24       0       0 -----    [ anon ]
00007f8154000000   65536   23976   23976 rw---    [ anon ]
00007f8158000000   65508   23652   23652 rw---    [ anon ]
00007f815bff9000      28       0       0 -----    [ anon ]
00007f815c000000   65508   23164   23164 rw---    [ anon ]
00007f815fff9000      28       0       0 -----    [ anon ]
00007f8160000000   65508   23344   23344 rw---    [ anon ]
00007f8163ff9000      28       0       0 -----    [ anon ]
00007f8164000000   65508   24052   24052 rw---    [ anon ]
00007f8167ff9000      28       0       0 -----    [ anon ]
00007f8168000000  131052   48608   48608 rw---    [ anon ]
00007f816fffb000      20       0       0 -----    [ anon ]
00007f8170000000   65516   23056   23056 rw---    [ anon ]
00007f8173ffb000      20       0       0 -----    [ anon ]
00007f8174000000   65516   26860   26860 rw---    [ anon ]
00007f8177ffb000      20       0       0 -----    [ anon ]
00007f8178000000   65508   23360   23360 rw---    [ anon ]
00007f817bff9000      28       0       0 -----    [ anon ]
00007f817c000000   65536   24856   24856 rw---    [ anon ]
00007f8180000000   65512   23272   23272 rw---    [ anon ]
00007f8183ffa000      24       0       0 -----    [ anon ]
00007f8184000000   65508   23688   23688 rw---    [ anon ]
00007f8187ff9000      28       0       0 -----    [ anon ]
00007f8188000000   65512   24024   24024 rw---    [ anon ]
00007f818bffa000      24       0       0 -----    [ anon ]
00007f818c000000   65508   25020   25020 rw---    [ anon ]
00007f818fff9000      28       0       0 -----    [ anon ]
00007f8190000000   65512   22868   22868 rw---    [ anon ]
00007f8193ffa000      24       0       0 -----    [ anon ]
00007f8194000000   65508   24156   24156 rw---    [ anon ]
00007f8197ff9000      28       0       0 -----    [ anon ]
00007f8198000000   65508   23684   23684 rw---    [ anon ]

有很多街区占用大约64M。

There are many blocks which occupy about 64M.

我使用jcmd pid VM.native_memory细节来跟踪这些内存块。但是,我找不到jcmd结果中列出的任何内存范围的这些块。

I use jcmd pid VM.native_memory detail to track these memory blocks. However, I cannot found these blocks with any of the memory ranges listed in the result of jcmd.

此外,我注意到一篇文章提到了malloc中的竞技场效果< a href =http://info.prelert.com/blog/java-8-and-virtual-memory-on-linux =nofollow noreferrer> Java 8和Linux上的虚拟内存。但是这些块似乎与线程池不同,因为1.模式是 rw --- 不是 ----- 2.竞技场线程池仅影响虚拟内存。它无法解释这些太多的RSS。

Furthermore, I noticed an article which mentions arena effect in malloc of glic Java 8 and Virtual Memory on Linux. However These blocks seem different from thread pool because 1. The mode is rw--- not ----- 2. The arena thread pool only affects virtual memory. It cannot explain these too much RSS.

我使用gdb来跟踪分配的内存

I use gdb to track the allocated memory

dump binary memory mem.bin from to

mem.bin.1

mem.bin.1

mem.bin.2

mem.bin.2

mem.bin.3

mem.bin.3


mem.bin.4

mem.bin.4

有关于30块l看看图片中显示的内容。

There are about 30 blocks like those shown in the picture.

几天后,我使用Google perf工具跟踪堆分配。并发现:

After some days, I use Google perf tools to track heap allocations. And found this:

它表明:zip膨胀消耗近2G内存。我想这可能与某些编译问题有关。

It shows that: zip inflates consume nearly 2G memory. I guess it may concern with some compilation issue.

我读过这个问题: https://bugs.openjdk.java.net/browse/JDK-8164293 。这与我的关注有关吗?

I have read this issue:https://bugs.openjdk.java.net/browse/JDK-8164293. Is this related to my concern?

那么如何跟踪这些内存块的来源呢?

So how can I track the source of these memory block?

推荐答案

使用 jemalloc tcmalloc - 他们两者都有内置的分配探查器,有助于识别分配的来源。

Use jemalloc or tcmalloc - they both have built-in allocation profiler that will help to identify the source of allocations.

由于许多原因,Java进程可能会使用过多的本机内存。热门原因是

Java process may use too much native memory for many reasons. Popular reasons are


  • 直接ByteBuffers

  • 分配的内存Unsafe.allocateMemory

  • 未封闭的资源(例如 ZipInputStream

  • 其他原生资源库

  • Direct ByteBuffers
  • Memory allocated by Unsafe.allocateMemory
  • Unclosed resources (e.g. ZipInputStream)
  • other native libraries

请注意,NativeMemoryTracking不会显示本机库消耗的内存。

Note that NativeMemoryTracking will not show memory consumed by native libraries.

这篇关于这些java本机内存从哪里分配?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆