Java垃圾收集器会干扰HPA的缩减吗？

我在kubernetes集群上部署了大量使用内存的SpringAPI

我将自动缩放（HPA）配置为将内存消耗视为缩放标准，并运行负载测试，在缩放时一切正常，但在缩放时内存不会下降，因此创建的POD不会被删除。如果我再次运行测试，将创建新的pod，，但从未删除

使用VisualVM进行本地分析，我相信问题与GC相关。在本地，GC在测试期间正常工作，但在请求结束时停止运行，留下垃圾，并且只在长时间后再次运行。所以我相信这些垃圾会阻止HPA的规模缩小

有没有人能告诉我是什么原因导致了这种效果，或者我可以试试

PS.在探查器中，我没有任何内存泄漏的迹象，当我手动运行GC时，剩余的垃圾会被清除

以下是一些额外的细节：

• Java版本：11
• Spring版本：2.3
• Kubernetes版本：1.17
• Docker图片：openjdk:11 jre slim
• HPA请求内存：1Gi
• HPA限制内存：2Gi
• HPA内存利用率指标：80%
• HPA最小吊舱数：2
• HPA最大吊舱数：8
• JVM操作：-Xms256m-Xmx1G

---

很可能没有内存泄漏

JVM从操作系统请求内存，直到

-Xmx…

命令行选项设置的限制。每次主要GC运行后，JVM都会查看正在使用的堆内存与（当前）堆大小的比率：

• 如果比率太接近1（即堆太满），JVM将从操作系统请求内存以使堆变大。它“急切地”这样做

• 如果比率太接近0（即堆太大），JVM可能会收缩堆并向操作系统返回一些内存。它“不情愿地”这样做。具体地说，JVM决定释放内存之前，可能需要多次完整的GC运行

我认为您看到的是JVM堆大小调整策略的影响。如果JVM处于空闲状态，那么就不会有足够的完整GC来触发JVM收缩堆，也不会将内存返回给操作系统

您可以尝试通过多次调用

System.gc（）

来鼓励JVM返回内存。但是运行一个完整的GC是CPU密集型的。如果您确实设法让JVM收缩堆，那么再次扩展堆（对于下一个大请求）将需要更多完整的GCs

所以我的建议是：不要尝试。使用其他一些条件来触发自动缩放。。。如果有道理的话

---

另一件需要注意的事情是，JVM+应用程序可能会使用大量的非堆内存；e、 g.可执行和共享的本机库、本机（C++）堆、Java线程堆栈、Java元空间等。这些用法都不受

-Xmx

选项的约束。

read