我们在一些生产实例中注意到了一种奇怪的模式。它们的-Xms设置为6G，没有-Xmx。 -Xmn设置为2G。 CMS gc正在使用中。应用程序正在Oracle Java 8热点上运行。
应用程序在由mesos管理的docker容器中运行，每个容器具有10G内存。轻浮禁用。通过AppDynamics javaagent监视应用实例。
最近我们注意到所有的jvm实例都停留在6G预留位置。即使没有显式的-Xmx分配也不会超过-Xms。一些实例充满了它们的原信息，并在几天内从appD监视中消失。一个或两个appD代理的民意调查成功进入了appD服务器，但仅此而已。停运之前，主要的GC费率飞速上涨。服务没有响应。
非常奇怪的是，这些通过的1-2 appD轮询确实报告了jvm的内存配置。这表明jvm仅剩下3G的分配空间，即使-Xms是它的两倍[并且在中断之前确实是6G]。自然消耗的内存已达到该极限。我没有看到重启jvm的迹象。
给我的印象是-Xms是堆大小的硬性最小限制。我说错了吗在什么情况下堆分配会远低于-Xms？
但是，我确实注意到分配的堆有一些下降低于-Xms，只是速度没有那么快。通常只需要数十MB。但是停机期间的故障似乎很严重。