java进程中提交内存和RSS的差异
我正在运行一个运行jetty的简单java进程，上面显示了2.9g的RAM。使用的JDK版本是1.8.0_112。
使用本机内存跟踪（jcmd），它显示提交的总内存仅为1.5G内存
而且，正如jvisualvm所报告的，直接缓冲池的大小非常小。
我完全知道NMT显示的内存是提交内存，不需要在RAM中。在这种情况下，NMT内存对RES的贡献应该是
在我的例子中，这里的差异约为1.4G（RES显示内存增加了1.4G），这不能仅仅归因于共享库、罐。有人能建议我如何知道这个额外的内存是什么，以及可以使用哪些工具来检查它们吗？
我已经在线/Stackoverflow检查了所有现有的相关问题，但找不到任何合适的答案。
共有1个答案
pmap-X
NMT不计算由本机非JVM代码分配的内存，即使该内存是由标准Java类库分配的，例如通过ZipInputStream的本机方法。参见相关问题。
另一个可能的原因是malloc本身。本机内存分配器很少将未使用的内存返回操作系统。例如，如果一个应用程序使用malloc在小块中分配1 GB，然后释放所有这些块，从应用程序的角度来看，将有1 GB的可用内存，但操作系统可能会在RSS中计算这1 GB。这个内存基本上属于应用程序的malloc池，可以在以后的malloc调用中重用。
尝试使用其他分配器，如jemalloc或tcmalloc。顺便说一句，它们都有一个分配探查器，可以帮助查找本机内存泄漏。
-
在图像中，使用内存为3.8G，提交内存为8.6G，最大内存也为8.6G，任何人都可以解释使用内存和提交内存之间的差异，或者任何解释它的链接。
-
为了降低RSS，我正在Java8上运行不同jvm选项的实验： > 用于Rss跟踪的脚本： 用于设置java进程的JVM args： 与JCMD进行差异：
-
场景： 我有一个在docker容器中运行的JVM。我使用两个工具做了一些内存分析:1)Top2)Java本地内存跟踪。 问题： 给docker容器的总内存=2 GB Java最大堆=1 GB 提交总量(JVM)=始终小于800 MB 使用的堆(JVM)=始终小于200 MB 未使用堆(JVM)=始终小于100 MB。 RSS=约1.1GB. 那么，1.1 GB(RSS)和800 MB（Java总提
-
问题是，那些块是什么？哪个子系统分配这些？ 更新：我们不使用JIT和/或JNI本机代码调用。
-
“Kubernetes”(v1.10.2)说我的pod（包含一个容器）使用了大约5GB的内存。在容器内部，RSS更像是681MIB。anypony能否解释如何使用以下数据从681MIB到5GB（或者描述如何使用我省略的另一个命令来弥补差异，或者来自容器，或者来自在kubernetes中运行该容器的docker主机）？ kubectl top pods显示为5GB: Cadvisor报告了一个相似的
-
我试图在docker容器内JavaSpring Boot应用程序中寻找内存泄漏。 应用程序的堆大小如下所示： 本机内存差异如下所示： 本机内存跟踪： 总计：保留=8295301KB 1728KB，已提交=2794537KB 470172KB 获取堆转储后： 堆泄漏可疑报告非常小-45MB： 问题是：为什么Java堆提交=2245120KB-几乎2GB？它不符合Xmx512m，也不符合jmap的堆转