我们最近一直在使用以下配置测试 G1 垃圾收集器:
-详细:gc -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+UseG1GC -XX:MaxGCPauseMillis=1250 -XX:+PrintTenuringDistribution -Xloggc:${logdir}/gc-$(date +%Y_% m_%d-%H_%M).log -XX:+UseStringDeduplication -XX:+PrintStringDeduplicationStatistics -XX:+PrintPromotionFailure -XX:+PrintAdaptiveSizePolicy -XX:+PrintHeapAtGC -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=10 -XX: GCLogFileSize=100M -XX:+UnlockExperimentalVMOptions -XX:G1NewSizePercent=15 -XX:ParallelGCThreads=8 -XX:+ParallelRefProcEnabled -XX:G1HeapRegionSize=8M JAVA_OPTS_HEAP:-Xms16g -Xmx16g
我们最近遇到了一个问题，两个 java 进程在一个 48 GB RAM 的盒子上以上述配置运行，并且这两个进程继续每个消耗大约 20 - 22 GB 的 RAM(很少有小进程消耗剩余内存)，从而填满整个 RAM，然后触发磁盘交换，最终导致 OOM 和进程被杀死。
这似乎令人担忧，因为 NMT 既没有以有意义的方式报告此内存使用情况，我们也没有从 GC 日志中获得有关此使用情况的任何线索。在 NMT 统计中，应用程序内存低于 16G，元空间使用量低于 1G。
我们曾尝试将 maxMetaSpaceSize 设置为 2G，但这也无济于事。当进程运行数天时，RAM 使用量似乎无限增长。
从其他问题来看，G1 垃圾收集器确实倾向于消耗更多内存，但磁盘交换是一个令人担忧的问题。有人可以就如何解决这个问题提供一些建议吗？
最佳答案
至于期待评论我把它作为答案。
解释 why a java process might consume more memory than -Xmx 的好读物.根据我们提供的信息，我相信这也是您的原因。
对于 G1，有一个 OBE Getting Started with the G1 Garbage Collector详细介绍了 G1GC 的功能。在那里查看 Recommended Use Cases for G1。也许您不会从使用 G1 中受益。
引用自 OBE(Oracle By E示例)
If you are using CMS or ParallelOldGC and your application is not experiencing long garbage collection pauses, it is fine to stay with your current collector.
关于java - G1 垃圾收集器的高内存使用问题，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/45725812/