什么会导致java进程大大超过Xmx或Xss限制？
我有7个不同的java守护进程，我在3个不同的服务器上运行（全部7个）。java命令行具有-Xmx2048m和-Xss1024k。在这3台服务器上，所有21个进程的顶部和顶部的VIRT大小都略低于2.5 GB。根据守护进程的不同，RES大小从300到1.9 GB不等。
这一切都是应该的。
输入新服务器。更快的CPU、更多的RAM（16 GB而不是8 GB）、稍新的java（旧服务器上为1.6.0_10-b33，新服务器上为1.6.0_31-b04）。两个系统（和JVM）都是64位的。
已将2个守护进程移动到新服务器。在新的服务器上，给定相同的任务，守护进程都消耗了大量的CPU（大约相当于一个内核的价值），而且完成的工作更少。（从旧系统上的5110个处理器移动到新系统上的5620个）。
几乎是CPU使用的全部额外核心（GC线程？？）并为一个守护进程报告5 GB VIRT和2 GB RES，为另一个守护进程报告10.5 GB VIRT和2 GB RES。
知道什么会导致java忽略（或者如果是这种情况下似乎忽略）内存限制吗？
共有1个答案
事实证明这是一个glibc问题。
我的简短回答是：
导出MALLOC\u ARENA\u MAX=1
这减少了多达5倍的进程占用空间（顶部为VIRT）。回到CentOS 5中的水平。
最新版本的glibc有一个新功能“每线程内存池”：
http://www.centos.org/docs/5/html/5.4/Technical_Notes/glibc.html
1.71.1日志部分的最后一项讨论了它（并指出了一个非公共错误......）
-
问题内容： 我在3个不同的服务器上运行了7个不同的Java守护程序（全部7个）。Java命令行具有-Xmx2048m和- Xss1024k。在这3台服务器上，顶部和顶部的VIRT大小全部显示21个进程不足2.5 GB。RES大小从300到1.9 GB不等，具体取决于它是哪个守护程序。 这就是应有的一切。 输入新服务器。更快的CPU，更多的RAM（16 GB而不是8 GB），Java稍微更新（旧服务
-
我们在日志中看到了OutOfMemoryExceptions，它们似乎与java堆提交大小从~1G增长到~2.4G一致。尽管有错误消息，但堆空间似乎没有用完。除了抛出异常（和生成的堆转储）之外，调整大小似乎最终会成功，应用程序继续运行，没有任何问题（堆提交大小约2.4G）。 下面是日志输出的一个示例： 请注意，在OOME之前，提交的堆总数在1GB和2.4GB之间振荡。我们可以看到，它之前非常稳定在
-
假设我有32 GB的RAM，我通过指定-xmx2048m为我的java进程分配了2GB。但实际上我的进程通常只消耗1GB的堆。那么分配的剩余1GB内存会发生什么呢？剩余的RAM总量是30 GB还是31 GB？
-
PS：有时我会从java代码执行shell脚本。会不会导致这类问题？
-
问题内容： 好吧，我试图理解并阅读可能导致它的原因，但我却无法理解： 我的代码中有这个地方： 事实是，当它尝试调用某些方法时，它将引发而不是其他预期的异常（特别是）抛出 。我实际上知道调用了什么方法，所以我直接转到该方法代码，并为应该抛出的行添加了一个块 ，它实际上按预期抛出。然而，当它上升时，以某种方式更改了上面的代码并没有 按预期进行。 是什么原因导致这种行为的？我该如何检查？ 问题答案： 通
-
主要内容：1.Spring AOP 工作流程,2.源码解读1.Spring AOP 工作流程 第一块就是，我们在创建 Bean 的前置处理中，会遍历程序所有的切面信息，然后将切面信息保存在缓存中 第二块就是，我们在创建 Bean 的后置处理器中，里面会做两件事情： 获取切面方法：首先会从缓存中拿到所有的切面信息，和 Louzai 的所有方法进行匹配，然后找到 Louzai 所有需要进行 AOP 的方法。 创建 AOP 代理对象：结合 Louzai 需要进