我的程序中有很多线程，其中一个不断询问内存而不释放它 . 正如gc log show所示，我发现了连续的Full GC（人机工程学），但程序没有获得更多内存，所有线程都停止了，除了JVM垃圾收集线程 . 我阅读了官方文档，GC Ergonomics尝试增加或缩小堆以满足特殊目标，例如minium暂停时间和/或吞吐量 . 但是，在 Full GC (Ergonomics) 之后，作为gc log显示，堆空间的大小没有变化，无论是古老还是年轻 .
我徘徊为什么在Full GC（人体工程学）之后堆的大小没有改变
我的电脑有16G内存，没有交换 . 此计算机中没有运行其他应用程序
JVM Args： -XX:+PrintGCDateStamps -Xloggc:gc.log -Dcom.sun.management.jmxremote=true -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.managementote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false -Xmx10G -XX:+HeapDumpOnOutOfMemoryError -XX:+PrintGCDetails gc log：gc log
1 回答
这里有几件事要看 .
首先，您描述应用程序的方式似乎是典型的内存泄漏（即使这是故意的） . 如果你有一个线程不断分配它维护引用的对象，最终你将耗尽堆空间 . 查看GC日志和堆图，这正是发生的事情 . 完整的GC正在不断运行，试图回收空间以保持您的应用程序正常运行 . 收集器不回收任何空间，这实际上让我感到惊讶的是VM不会因OutOfMemoryError而停止 . 如果堆连续满98％或更多并且GC无法回收超过2％的空间，则会产生OutOfMemoryError . GC日志显示这是真的 .
接下来的问题是为什么堆空间不会扩展到8Gb以上 . 您将-Xmx选项设置为10Gb，因此从逻辑上讲，如果需要，您可以期望堆增长到该大小 . 在16Gb的机器上，没有理由不这样做 . 我会添加选项-Xms来将初始大小设置为10Gb，这将迫使JVM在启动时保留所有空间 .
正如评论中指出的那样，您应该对应用程序进行概要分析，以便更好地了解您正在维护引用的对象，以及是否有某种方法可以减少这种情况 . 使用无界数据集，您将始终达到应用程序无法继续的点 .