tipos - ¿De dónde provienen estos recuerdos nativos de Java?

tipos primitivos java

Question

La versión de JDK es el punto de acceso 8u_45

Investigué la memoria nativa de mi proceso de Java. La memoria nativa incluso consume más espacio que el montón. Sin embargo, hay muchos bloques de memoria nativos que me confunden. El resultado de pmap -x por ejemplo:

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 ]

Hay muchos bloques que ocupan alrededor de 64M.

Utilizo jcmd pid VM.native_memory detail para rastrear estos bloques de memoria. Sin embargo, no puedo encontrar estos bloques con ninguno de los rangos de memoria enumerados en el resultado de jcmd.

Además, noté un artículo que menciona el efecto arena en malloc of glic Java 8 y Virtual Memory en Linux . Sin embargo, estos bloques parecen diferentes del grupo de subprocesos porque 1. El modo es rw--- no ----- 2. El grupo de subprocesos de la arena solo afecta a la memoria virtual. No puede explicar esto demasiado RSS.

Yo uso gdb para rastrear la memoria asignada

dump binary memory mem.bin from to

mem.bin.1

mem.bin.2

mem.bin.3

mem.bin.4

Hay alrededor de 30 bloques como los que se muestran en la imagen.

Después de algunos días, utilizo las herramientas de Perforación de Google para rastrear las asignaciones de Heap. Y encontré esto:

Muestra que: los inflables inflables consumen casi 2G de memoria. Supongo que puede tratarse de algún problema de compilación.

He leído este problema: https://bugs.openjdk.java.net/browse/JDK-8164293 . ¿Esto está relacionado con mi preocupación?

Entonces, ¿cómo puedo rastrear el origen de estos bloques de memoria?

Answer 1

Utilice jemalloc o tcmalloc : ambos tienen un generador de perfiles integrado que ayudará a identificar la fuente de asignaciones.

El proceso de Java puede usar demasiada memoria nativa por muchas razones. Los motivos populares son

• Direct ByteBuffers
• Memoria asignada por Unsafe.allocateMemory
• Recursos no cerrados (p ZipInputStream Ej. ZipInputStream )
• otras bibliotecas nativas

Tenga en cuenta que NativeMemoryTracking no mostrará la memoria consumida por las bibliotecas nativas.