我有一个Grails / Spring应用程序，它运行在像Tomcat这样的Web服务器上的servlet容器中。有时我的应用程序崩溃，因为JVM达到其最大允许内存（Xmx）。
随后的错误是“java.lang.OutOfMemoryError”，因为Java堆空间已满。
为防止出现此错误，我想从我的应用程序中检查正在使用的内存量以及当前JVM剩余的内存量。
如何从我的应用程序中访问这些参数？
答案 0 :(得分：1)
您可以尝试Grails Melody Plugin显示相对于您的上下文的网址/monitoring中的信息。
答案 1 :(得分：1)
尝试了解何时抛出OOM而不是尝试通过应用程序对其进行操作。而且，即使您能够从应用程序中捕获这些值 - 您将如何防止错误？通过明确调用GC。知道了，
Java机器规范说明了这一点 OutOfMemoryError：Java虚拟机实现已用完虚拟或物理内存，并且自动存储管理器无法回收足够的内存来满足对象创建请求。
因此，GC保证在抛出OOM之前运行。您的应用程序在刚刚运行完全垃圾收集后抛出OOME，并发现它仍然没有足够的可用堆来继续。
这可能是内存泄漏，或者通常您的应用程序可能需要很高的内存。大多数情况下，如果在启动应用程序的短时间内抛出OOM - 通常应用程序需要更多内存，如果服务器运行正常一段时间然后抛出OOM则很可能是内存泄漏。
要发现内存泄漏，请使用上述人员提到的工具。我使用new-relic监视我的应用程序并检查GC运行的频率。
PS Scavenge又名minor-GC又称并行对象收集器仅适用于年轻一代，PS MarkAndSweep又称主要GC又名并行标记和扫描收集器适用于老一代。当两者都运行时 - 它被认为是一个完整的GC。轻微的gc运行非常频繁 - Full GC的频率相对较低。请注意消耗不同的堆空间来分析您的应用程序。您还可以尝试以下选项 -
如果经常使用OOM，那么使用正确的选项启动java，获取堆转储并使用jhat或eclipse中的内存分析器进行分析（http://www.eclipse.org/mat/）
-XX：+ HeapDumpOnOutOfMemoryError -XX：HeapDumpPath =转储文件的路径
答案 2 :(得分：0)
为防止出现此错误，我想从我的应用内查看多少 内存正在使用中，当前JVM剩余多少内存。
我认为以这种方式进行并不是最好的主意。更好的是调查实际上破坏了你的应用程序，消除错误或在那里做出一些限制。可能有许多不同的场景，您的应用程序可能变得不可预测。总结一下 - 为监控目的捕获内存级别是可以的（但是有很多专用工具），但在我看来，根据应用逻辑中的这些值，不推荐和不良做法
答案 3 :(得分：0)
为此，您将使用分析器来分析您的应用程序和JVM，而不是使用代码来监视应用程序中的此类度量标准。
分析是动态程序分析的一种形式，可以测量程序的空间（内存）或时间复杂度，特定指令的使用，或函数调用的频率和持续时间
以下是一些优秀的java个人资料：
http://www.ej-technologies.com/products/jprofiler/overview.html（付费）