JCMD的代码/内部部分包含什么？

Question

为基于JVM的服务确定docker容器的尺寸非常困难（众所周知）。我很确定我们的容器尺寸略有不足，并且想清除一些与我在监视时看到的特定jcmd（本机内存跟踪器）输出有关的问题。

问题：

jcmd报告的“内部”中是否包含直接字节缓冲区？
jcmd报告的“代码”中除代码缓存外还有什么？
是否有一种很好的方法来限制jcmd报告的“代码”部分。我阅读了https://docs.oracle.com/javase/8/embedded/develop-apps-platforms/codecache.htm，但这仅涵盖了代码缓存限制，建议将JVM默认设置保持不变。

JCMD输出在这里。

直接字节缓冲区 JMX属性在这里。

一些背景细节：

设置：

基于Spring Boot的应用程序
JVM选项：

-服务器-Xms1792m -Xmx1792m -XX：MetaspaceSize = 128M-XX：MaxMetaspaceSize = 192M -XX：+ UseG1GC -XX：+ UseStringDeduplication-XX：MaxDirectMemorySize = 256m -XX：NativeMemoryTracking = detail
在AWS / EC2中运行的Docker容器2500MiB

Answer 1

jcmd报告的“内部”中是否包含直接字节缓冲区？

（更新） ByteBuffer.allocateDirect内部调用Unsafe.allocateMemory，该调用由NMT在“内部”部分中计数（以mtInternal常数表示）。

相反，MappedByteBuffers（由获取FileChannel.map）未反映在NMT报告中，尽管从OS角度来看它们肯定会影响进程使用的内存量。

jcmd报告的“代码”中除代码缓存外还有什么？

维护已编译代码和生成的运行时存根的辅助VM结构：哈希表，代码字符串，适配器指纹等。与CodeCache本身相比，它们都很小。这些结构构成报告中的“ malloc”部分，而CodeCache进入“ mmap”部分。

是否有一种很好的方法来限制jcmd报告的“代码”部分。

关闭分层编译（-XX:-TieredCompilation）可能会减少“代码”使用的内存量，只是因为生成的代码会少很多。但是请确保您了解什么是分层编译以及它可能会对性能产生什么影响。