内存提升后java.lang.ref.Finalizer OutOfMemory

Question

提取heapdump我意识到它有很多对象在等待finalization，其中大部分是来自jdbc连接等库的实例。

知道队列中的那些实例基本上是实现finalize()的类，为什么它们根本没有最终确定？

几天前，我提出了这种情况的记忆。最初它有1GB，新一代设置为256 MB（-Xmx1g -XX:NewSize=256m -XX:MaxNewSize=256m）。当我们添加一些重度缓存功能时，我们将分配给该实例的内存增加到3 GB（-Xmx3G -XX:NewSize=512m -XX:MaxNewSize=512m）。从那一刻起，我们开始看到一些记忆。仔细研究一下，我发现了很多java.lang.ref.Finalizer和等待完成的对象。

这怎么可能彼此相关？可能它甚至相关吗？

Answer 1

  

为什么他们根本没有最终确定？

某些组件需要更长的时间才能最终确定涉及IO的任何内容。 JDBC连接是相对较重的网络资源，因此它们需要更长的时间。

我建议您使用连接池（大多数JDBC库都内置了它们）这样您就不会一直创建/销毁它们。

注意：澄清1Gb = 1 gig-bit或128 MB（兆字节）256 mb是256毫位或大约1/4的位。 -XX:NewSize=512m是512 MB而不是256 MB。并且-XX:MaxNewSize=512不会工作，因为它只有512字节，很有可能你使用-XX:MaxNewSize=512m

3Gb是3千兆比特，但假设您的意思是3 GB，那么-Xmx1G不是1 GB或8 Gb。

Answer 2

垃圾收集器在清理的最后一步调用

Object.finalize()。 GC会定期运行（取决于您使用的GC，如果7和8可能是CMS，或G1，如果您这样配置）。有很多对象在等待最终确定＆＃39;可能意味着你有一个大堆和足够的内存，GC不需要运行（CMS最有可能，因为G1运行微清理更频繁）。

将GC跟踪添加到JVM启动参数并监控其运行频率：-XX：+ PrintGCDetails -XX：+ PrintGCTimeStamps请参阅：http://www.oracle.com/technetwork/java/javase/gc-tuning-6-140523.html

如果您使用堆大于1Gb的大量小对象，您可能需要考虑使用G1垃圾收集器，因为它更适合这样的任务，并且没有“停止”世界＆＃39; CMS的行为。