我们监控生产 JVM，并拥有监控触发器，当 JVM 堆空间不足时(理想情况下)会发送警告。然而，提出一种有效的检测算法相当困难，因为垃圾回收的本质是，在 GC 启动之前，应用程序通常没有可用内存。
我能想到有很多方法可以解决这个问题。例如。监视可用空间，当它变得太低时发送警告，但延迟它并且仅在它持续超过一分钟时触发。那么，什么在实践中对您有用？
特别有趣:
- 如何检测需要立即采取 react 的严重内存/堆问题？
- 如何检测需要采取预防措施的堆问题？
- 哪些方法是普遍有效的？例如。无需使触发器适应某些 JVM 调整参数，反之亦然，或者强制在某些时间间隔内执行 GC。
- 是否有广泛使用的最佳实践？
最佳答案
我发现 JVM 内存健康状况的一个非常有效的衡量标准是 JVM 在垃圾收集上花费的时间百分比。一个健康、调整良好的 JVM 将使用很少(< 1% 左右)的 CPU 时间来收集垃圾。不健康的 JVM 将“浪费”大量时间来保持堆清洁，并且在遇到内存泄漏或最大堆设置太低(因为更多的 CPU 被占用)的 JVM 中，收集所使用的 CPU 百分比将呈指数级攀升。用于保持堆清洁，较少用于做“实际工作”...假设入站请求速率没有减慢，很容易掉下悬崖，您会受到 CPU 限制，并且无法足够快地完成足够的工作早在你真正得到 java.lang.OutOfMemoryError 之前)。
值得注意的是，这也是您要防范的情况。您实际上并不关心 JVM 是否使用了其所有堆，只要它能够有效地回收内存而不妨碍它需要执行的“实际工作”即可。 (事实上，如果您从未达到最大堆大小，您可能需要考虑缩小堆。)
此统计数据由许多现代 JVM 提供(当然至少是 Oracle 和 IBM)。
另一个有效的衡量标准是完整 GC 之间的时间。您执行完整 GC 的次数越多，花费在 GC 上的时间就越多。
关于java - 如何检测低堆情况以进行监控和警报？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/31793461/