JVM 堆外内存查看方法_如何查看java应用分配的堆外内存-CSDN博客

本文链接：https://blog.csdn.net/Andrew_Chenwq/article/details/133933478

JVM 堆外内存查看方法

概述

是否曾经想过为什么Java应用程序通过众所周知的*-Xms和-Xmx调整标志消耗的内存比指定的数量大得多？由于各种原因和可能的优化，JVM可能会分配额外的本机内存。这些额外的分配最终可能使消耗的内存超出-Xmx* 限制。
在本教程中，我们将枚举JVM中本机内存分配的一些常见来源，以及它们的大小调整标志，然后学习如何使用本机内存跟踪来监视它们。

本机分配

通常，堆是Java应用程序中最大的内存消耗者，但是还有其他一些。**除了堆之外，JVM从本地内存中分配了相当大的块来维护其类元数据，应用程序代码，由JIT生成的代码，内部数据结构等。**在以下各节中，我们将探讨其中的一些分配。
可以看到整个memory主要包含了Java Heap、Class、Thread、Code、GC、Compiler、Internal、Other、Symbol、Native Memory Tracking、Arena Chunk这几部分；其中reserved表示应用可用的内存大小，committed表示应用正在使用的内存大小
Java Heap部分表示heap内存目前占用了463MB；
Class部分表示已经加载的classes个数为8801，其metadata占用了50MB；
Thread部分表示目前有225个线程，占用了27MB；
Code部分表示JIT生成的或者缓存的instructions占用了17MB；
GC部分表示目前已经占用了15MB的内存空间用于帮助GC；
Compiler部分表示compiler生成code的时候占用了26MB；
Internal部分表示命令行解析、JVMTI等占用了5MB；
Other部分表示尚未归类的占用了2MB；
Symbol部分表示诸如string table及constant pool等symbol占用了10MB；
Native Memory Tracking部分表示该功能自身占用了5MB；
Arena Chunk部分表示arena chunk占用了63MB
一个arena表示使用malloc分配的一个memory chunk，这些chunks可以被其他subsystems做为临时内存使用，比如pre-thread的内存分配，它的内存释放是成bulk的

元空间 Class

为了维护有关已加载类的某些元数据，JVM使用了称为*Metaspace*的专用非堆区域。在Java 8之前，等效项称为PermGen或Permanent Generation。Metaspace或PermGen包含有关已加载类的元数据，而不是包含在堆中的有关它们的实例的元数据。
这里重要的是，由于元空间是堆外数据区域，因此堆大小调整配置不会影响元空间的大小。为了限制元空间的大小，我们使用其他调整标志：
-XX：MetaspaceSize和-XX：MaxMetaspaceSize设置最小和最大元空间大小
在Java 8之前，使用*-XX：PermSize和-XX：MaxPermSize*来设置最小和最大PermGen大小

线程数 Thread

JVM中最消耗内存的数据区域之一是堆栈，它与每个线程同时创建。堆栈存储局部变量和部分结果，在方法调用中起着重要作用。
默认的线程堆栈大小取决于平台，但是在大多数现代的64位操作系统中，大约为1 MB。此大小可通过*-Xss *调整标志进行配置。
与其他数据区域相比，当对线程数没有限制时，分配给堆栈的总内存实际上是不受限制的。 还值得一提的是，JVM本身需要一些线程来执行其内部操作，例如GC或即时编译。

代码缓存 Code

为了在不同平台上运行JVM字节码，需要将其转换为机器指令。在执行程序时，JIT编译器负责此编译。
JVM将字节码编译为汇编指令时，会将这些指令存储在称为*代码缓存***的特殊非堆数据区域中 。可以像JVM中的其他数据区域一样管理代码缓存。-XX：InitialCodeCacheSize **和 **-XX：ReservedCodeCacheSize **调谐标志确定用于代码高速缓存中的初始和最大可能大小。

垃圾收集 GC

JVM附带了几种GC算法，每种算法都适合不同的用例。所有这些GC算法都有一个共同的特征：它们需要使用一些堆外数据结构来执行任务。这些内部数据结构消耗更多的本机内存。

Symbols

让我们从字符串开始，它是应用程序和库代码中最常用的数据类型之一。由于它们无处不在，因此它们通常占据堆的很大一部分。如果大量的这些字符串包含相同的内容，那么堆的很大一部分将被浪费。
为了节省一些堆空间，我们可以存储每个String的一个版本，并让其他版本引用存储的版本。此过程称为字符串实习。由于JVM只能内生编译时间字符串常量，因此 我们可以对要内生的字符串手动调用intern（）方法。
JVM将内联的字符串存储在特殊的本机固定大小的哈希表中，该哈希表称为String Table，也称为String Pool。我们可以通过**-XX：StringTableSize** 调整标志来配置表的大小（即桶数）。
除了字符串表外，还有另一个本机数据区域，称为运行时常量池。 JVM使用此池存储必须在运行时解析的常量，例如编译时数字文字，方法和字段引用。

本机字节缓冲区 Native Byte Buffers

JVM通常是大量本机分配的可疑对象，但有时开发人员也可以直接分配本机内存。最常见的方法是通过JNI和NIO的直接ByteBuffers进行**malloc **调用。

Additional Tuning Flags

在本节中，我们针对不同的优化方案使用了少数JVM调整标志。使用以下技巧，我们几乎可以找到与特定概念相关的所有调整标志：

$ java -XX:+PrintFlagsFinal -version | grep <concept>

该PrintFlagsFinal打印所有- *XX *在JVM选项。例如，要查找所有与Metaspace相关的标志：

$ java -XX:+PrintFlagsFinal -version | grep Metaspace      // truncated      uintx MaxMetaspaceSize                          = 18446744073709547520                    {product}      uintx MetaspaceSize                             = 21807104                                {pd product}      // truncated

本机内存跟踪（NMT）

既然我们知道了JVM中本机内存分配的常见来源，那么该是时候找出如何监视它们了。**首先，我们应该使用另一个JVM调整标志启用本地内存跟踪：*-XX：NativeMemoryTracking = off | sumary | detail。 ***默认情况下，NMT处于关闭状态，但我们可以使它查看其观测结果的摘要或详细视图。
假设我们要跟踪典型的Spring Boot应用程序的本机分配：

$ java -XX:NativeMemoryTracking=summary -Xms300m -Xmx300m -XX:+UseG1GC -jar app.jar

在这里，我们使用G1作为GC算法，在分配300 MB堆空间的同时启用NMT。

即时快照

启用NMT后，我们可以随时使用*jcmd *命令获取本机内存信息：
```
$ jcmd <pid> VM.native_memory
```
为了找到JVM应用程序的PID，我们可以使用 jps命令：

$ jps -l                    7858 app.jar // This is our app7899 sun.tools.jps.Jps

现在，如果我们将 jcmd *与适当的*pid一起使用， *VM.native_memory *将使JVM打印出有关本机分配的信息：
```
$ jcmd 7858 VM.native_memory
```
让我们逐节分析NMT输出。

总分配

NMT报告保留和提交的内存总量，如下所示：

Native Memory Tracking:Total: reserved=1731124KB, committed=448152KB

保留的内存代表我们的应用程序可能使用的内存总量。相反，已提交的内存等于我们的应用程序当前正在使用的内存量。
尽管分配了300 MB的堆，但我们的应用程序的总保留内存几乎为1.7 GB，远不止于此。同样，已提交的内存大约为440 MB，这又远远超过了300 MB。
在合计部分之后，NMT报告每个分配源的内存分配。因此，让我们深入探讨每个来源。

堆

NMT按预期报告了我们的堆分配：

Java Heap (reserved=307200KB, committed=307200KB)          (mmap: reserved=307200KB, committed=307200KB)

300 MB的保留和提交内存，与我们的堆大小设置匹配。

元空间

NMT关于已加载类的类元数据的说明如下：

Class (reserved=1091407KB, committed=45815KB)      (classes #6566)      (malloc=10063KB #8519)       (mmap: reserved=1081344KB, committed=35752KB)

保留了将近1 GB的空间，并有45 MB的空间用于加载6566类。

线程

这是关于线程分配的NMT报告：

Thread (reserved=37018KB, committed=37018KB)       (thread #37)       (stack: reserved=36864KB, committed=36864KB)       (malloc=112KB #190)        (arena=42KB #72)

总共为37个线程的堆栈分配了36 MB的内存–每个堆栈几乎1 MB。JVM在创建时将内存分配给线程，因此保留和提交的分配是相等的。

代码缓存

让我们看看NMT对JIT生成和缓存的汇编指令的评价：

Code (reserved=251549KB, committed=14169KB)     (malloc=1949KB #3424)      (mmap: reserved=249600KB, committed=12220KB)

当前，将近有13 MB的代码被缓存，并且该数量可能会增加到大约245 MB。

GC

这是有关G1 GC内存使用情况的NMT报告：

GC (reserved=61771KB, committed=61771KB)   (malloc=17603KB #4501)    (mmap: reserved=44168KB, committed=44168KB)

我们可以看到，几乎有60 MB的空间被保留并致力于帮助G1。
让我们看看一个简单得多的GC（例如串行GC）的内存使用情况：

$ java -XX:NativeMemoryTracking=summary -Xms300m -Xmx300m -XX:+UseSerialGC -jar app.jar

串行GC几乎不使用1 MB：

GC (reserved=1034KB, committed=1034KB)   (malloc=26KB #158)    (mmap: reserved=1008KB, committed=1008KB)

显然，我们不应该仅仅因为内存使用率就选择了GC算法，因为串行GC的“停滞不前”性质可能会导致性能下降。

符号Symbol

这是有关符号分配的NMT报告，例如字符串表和常量池：

Symbol (reserved=10148KB, committed=10148KB)       (malloc=7295KB #66194)        (arena=2853KB #1)

将近10 MB分配给符号。

随着时间的NMT

NMT使我们能够跟踪内存分配如何随时间变化。**首先，我们应将应用程序的当前状态标记为基线：
```
$ jcmd <pid> VM.native_memory baseline
```
然后，过一会儿，我们可以将当前内存使用量与该基准进行比较：

$ jcmd <pid> VM.native_memory summary.diff

NMT使用+和–符号将告诉我们在此期间内存使用量如何变化：

Total: reserved=1771487KB +3373KB, committed=491491KB +6873KB-             Java Heap (reserved=307200KB, committed=307200KB)                        (mmap: reserved=307200KB, committed=307200KB) -             Class (reserved=1084300KB +2103KB, committed=39356KB +2871KB)// Truncated