Java进程使用的虚拟内存远远超出了Java堆。你知道，JVM包含许多子系统：垃圾收集器，类加载，JIT编译器等，所有这些子系统都需要一定数量的RAM才能起作用。
JVM不是RAM的唯一使用者。本机库（包括标准Java类库）也可以分配本机内存。这对于本机内存跟踪甚至是不可见的。Java应用程序本身也可以通过直接ByteBuffer使用堆外内存。
那么，什么需要占用Java进程中的内存呢？
JVM部分（主要由本机内存跟踪显示）
1. Java Heap
最明显的部分。这是Java对象所在的位置。堆占用最多-Xmx的内存。
- Garbage Collector
GC结构和算法需要额外的内存来进行堆管理。这些结构包括标记位图，标记堆栈（用于遍历对象图），记忆集（用于记录区域间引用）和其他结构。其中一些是直接可调的，例如-XX:MarkStackSizeMax，其他取决于堆布局，例如，G1区域（-XX:G1HeapRegionSize）越大，记住的集合就越小。
GC内存开销因GC算法而异。-XX:+UseSerialGC并且-XX:+UseShenandoahGC开销最小。G1或CMS可能很容易使用大约总堆大小的10％。
- Code Cache
包含动态生成的代码：JIT编译的方法，解释器和运行时存根。其大小受限制-XX:ReservedCodeCacheSize（默认为240M）。关闭-XX:-TieredCompilation以减少编译的代码量，从而减少代码缓存的使用。
- Compiler
JIT编译器本身也需要内存来完成其工作。这可以再次通过关闭分层编译或通过减少编译器线程的数目可以降低：-XX:CICompilerCount。
- Class loading
类元数据（方法字节码，符号，常量池，注释等）存储在称为元空间的堆外区域中。加载的类越多-使用的元空间越多。总使用量可以受到限制-XX:MaxmetaspaceSize（默认情况下无限制）和 -XX:CompressedClassSpaceSize（默认情况下为1G）。
- Symbol tables
JVM的两个主要哈希表：Symbol表包含名称，签名，标识符等，而String表包含对嵌入字符串的引用。如果本机内存跟踪通过String表指示大量内存使用，则可能意味着应用程序过度调用String.intern。
- Threads
线程堆栈还负责占用RAM。堆栈大小由控制-Xss。默认值为每个线程1M，但幸运的是情况还不错。OS会延迟分配内存页，即在首次使用时分配内存页，因此实际的内存使用量会低得多（每个线程堆栈通常为80-200 KB）。我编写了一个脚本来估计有多少RSS属于Java线程堆栈。
还有其他JVM部分分配本机内存，但是它们通常在总内存消耗中不起作用。
直接缓冲区
应用程序可以通过调用显式请求堆外内存
ByteBuffer.allocateDirect。默认的堆外限制等于-Xmx，但可以用覆盖
-XX:MaxDirectMemorySize。直接字节缓冲区包含在OtherNMT输出部分中（或Internal在JDK 11之前）。
通过JMX可以查看已使用的直接内存量，例如在JConsole或Java Mission Control中：
除了直接的ByteBuffer外，还可以将MappedByteBuffers文件映射到进程的虚拟内存。NMT不会跟踪它们，但是，MappedByteBuffers也可以占用物理内存。而且没有简单的方法来限制他们可以服用多少。你可以通过查看进程内存映射来查看实际用法：pmap -x
AddressKbytes RSS Dirty Mode Mapping...00007f2b3e557000 39592 32956 0 r--s- some-file-17405-Index.db00007f2b40c01000 39600 33092 0 r--s- some-file-17404-Index.db ^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^
本机库
加载的JNI代码System.loadLibrary可以分配所需的尽可能多的堆外内存，而无需JVM进行控制。这也涉及标准的Java类库。特别是，未关闭的Java资源可能会成为本机内存泄漏的来源。典型示例为
ZipInputStream或
DirectoryStream。
JVMTI代理（尤其是
jdwp调试代理）也可能导致过多的内存消耗。
此答案描述了如何使用async-profiler来分析本机内存分配。
分配者问题
进程通常直接从OS（通过mmap系统调用）或通过使用malloc标准libc分配器来请求本机内存。依次malloc使用mmap，从OS请求大块内存，然后根据其自己的分配算法管理这些大块。问题是-该算法可能导致碎片和过多的虚拟内存使用。
jemalloc，替代分配器，通常看起来比常规
libc更智能
malloc，因此切换为
jemalloc可能会导致免费占用的空间较小。
结论
由于有太多因素需要考虑，因此无法保证估算Java进程的全部内存使用率的方法。
Total memory = Heap + Code Cache + metaspace + Symbol tables + Other JVM structures + Thread stacks + Direct buffers + Mapped files + Native Libraries + Malloc overhead + ...
可以通过JVM标志来缩小或限制某些内存区域（例如代码缓存），但是其他许多区域完全不受JVM控制。
设置Docker限制的一种可能方法是在进程的“正常”状态下观察实际的内存使用情况。有用于调查Java内存消耗问题的工具和技术：本机内存跟踪，pmap，jemalloc和async-profiler。
更新资料
这是我对Java进程的内存占用的演示的记录。
在本视频中，我讨论了Java进程中可能消耗内存的内容，如何监视和限制某些内存区域的大小以及如何分析Java应用程序中的本机内存泄漏。
