我有 7 个不同的 Java 守护程序，我在 3 个不同的服务器上运行(全部 7 个)。 java命令行有-Xmx2048m和-Xss1024k。在这 3 台服务器上，所有 21 个进程的顶部和顶部的 VIRT 大小均显示为略低于 2.5 GB。 RES 大小从 300 GB 到 1.9 GB 不等，具体取决于它是哪个守护进程。
一切都应该如此。
输入新服务器。更快的 CPU，更多的 RAM(16 GB 而不是 8 GB)，稍微更新的 java(旧服务器上的 1.6.0_10-b33，新服务器上的 1.6.0_31-b04)。两个系统(和 JVM)都是 64 位的。
将 2 个守护进程移至新服务器。在新服务器上，给定相同的任务，守护进程既消耗大量 CPU(大约相当于一个内核的值(value))，又完成得更少。 (从旧系统上的 5110 处理器移至新系统上的 5620)。
几乎是一个完整的额外核心 CPU 使用率(GC 线程？？)，一个守护进程报告 5 GB VIRT 和 2 GB RES，另一个守护进程报告 10.5 GB VIRT 和 2 GB RES。
有什么想法会导致 java 忽略(或者如果是这种情况，似乎会忽略)内存限制？
最佳答案
原来这是一个 glibc 问题。
我的简短回答是:
导出 MALLOC_ARENA_MAX=1
这将流程占用空间(顶部的 VIRT)减少了多达 5 倍。回到 CentOS 5 中看到的级别。
最新版本的 glibc 有一个新特性“每线程内存池”:
http://www.centos.org/docs/5/html/5.4/Technical_Notes/glibc.html
1.71.1 日志部分的最后一项讨论了它(并指的是一个非公开的错误......)
关于java - 什么会导致 java 进程大大超过 Xmx 或 Xss 限制？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/10575342/