GC图显示内存泄漏，但无法在转储中跟踪
我们的应用程序中有一个JavaMicorservice，它连接到Postgres以及Phoenix。我们正在使用Spring Boot 2. x。
问题是，我们正在为应用程序执行大约8小时的耐久性测试，我们可以观察到使用的堆在不断增加，尽管我们对VM参数使用了建议，看起来像是内存泄漏。我们分析了堆转储，但根本原因对我们来说并不明确，一些专家能否根据结果提供帮助？
我们实际使用的VM参数是：
-XX:congcthreads=8-XX:DisableExplicitGC-XX:InitialHeapSize=536870912-XX:initialingheapoccupencypercent=45-XX:maxgcpausemilis=1000-XX:MaxHeapFreeRatio=70-XX:MaxHeapSize=536870912-XX:MinHeapFreeRatio=40-XX:ParallelGCThreads=16-XX:PrintAdaptiveSizePolicy-XX:PrintGC-XX:PrintGCDateStamps-XX:PrintGCDetails-XX:PrintGC-XX:PrintGCTimeStamps-XX:UseCompressedClassPointers-XX:UseCompressedOops-XX:UseG1GC-XX:UseStringDuplication
我们希望使用的堆在GC日志中应该是平坦的，但是内存消耗没有释放，而且还在不断增加。
共有1个答案
我不确定上面使用的是哪种工具，但我会在堆中寻找支配者层次结构。Eclipse MAT是一个分析堆转储的好工具，它可以为您指出内存的实际存储方向，您可以决定是否将其归类为泄漏。不管您附加了什么标签，如果应用程序在一段时间后因为内存不足而崩溃，那么这就是一个问题。
这个博客也讨论了诊断这类问题。
-
我在继续我的游戏超过8次后，我得到了OutOfMemory错误，因为堆逐渐填充。在使用MAT分析我的游戏堆时，我知道以下2个原因： 关键词Android.Graphics.Bitmap Byte[] 关键词java.lang.Object[]Android.content.res.resources 请提出解决方案
-
我试图在我们非常小且简单的Spring Boot应用程序中跟踪并确定内存泄漏的根本原因。 它使用以下内容：-Spring Boot 2.2.4-azure servicebus jms Spring Boot starter 2.2.1-MSSQL 功能：该应用程序只发送Azure ServiceBus队列，存储数据并将数据发送到其他目的地。这是一个小应用程序，所以它很容易启动64兆的内存，尽管我
-
问题内容： 我必须在Java应用程序中找到内存泄漏。我对此有一些经验，但希望就此方法论/战略提出建议。欢迎任何参考和建议。 关于我们的情况： 堆转储大于1 GB 我们有5次堆放场。 我们没有任何测试案例可以激发这一点。仅在使用至少一个星期后，它才会在（大规模）系统测试环境中发生。 该系统建立在内部开发的传统框架上，该框架具有许多设计缺陷，以至于无法将它们全部计算在内。 没有人深入了解该框架。它已被
-
问题内容： 我们有一个App Engine应用程序，可将许多较大文件写入Google Cloud Store。这些文件是动态创建的CSV文件，因此我们将Python用作缓冲区和写入该缓冲区的接口。 通常，我们的过程如下所示： 据我们了解，它们本身不需要关闭。而是，仅上述内容和需要被关闭。 我们在由App Engine的任务队列调用的中运行上述过程。最终，在几次调用我们的任务后，我们得到以下错误：
-
我已经用工具从运行了几天的Java应用程序中生成了一个堆转储文件，这将导致一个很大的二进制堆转储文件。 我如何在IntellIJ IDEA中对这个堆转储执行内存分析？ 我知道有一些用于Eclipse和Netbeans的工具，但如果可能的话，我更愿意使用IDEA。 分析的基本结果将告诉我每个对象在内存中的实例数（每个类），以便我能够开始调试内存泄漏。
-
我们有一个应用程序引擎应用程序，它将许多相对较大的文件写入谷歌云商店。这些文件是动态创建的CSV，因此我们使用Python的作为写入该缓冲区的接口。 通常，我们的流程如下所示： 据我们所知，不需要自己关闭。相反，只需要关闭上面的和。 我们在appengine的任务队列调用的