解决垃圾收集器的内存泄漏问题

时间:2011-01-09 03:43:18

标签: java

Java后端系统面临如此大的负载,垃圾收集器无法处理并且存在内存泄漏。怎么解决这个问题?

4 个答案:

答案 0 :(得分:2)

我非常怀疑。内存泄漏,除非通过本机代码,实际上是内存膨胀的情况。内存膨胀只是具有强大引用的对象,永远不会被删除。

答案 1 :(得分:2)

在Java中,最终导致内存泄漏的唯一方法是保留不再需要的引用。由于您的应用程序仍然可以访问引用,垃圾收集器将无法清理它,并且从垃圾收集器的角度来看,确实没有办法知道它是泄漏。

唯一要做的就是修复泄漏。至于如何查找和检测它们......遗憾的是,我没有很多建议。也许您可以在单元测试中添加代码以验证函数是否释放了他们不再需要的内存?或者你可以运行单元测试,大大减少VM内存,以确定哪些单元负责最多的分配?有些模式通常会导致泄漏。例如,保持较大字符串的子字符串(例如,如果您将文件读入字符串),因为子字符串保持对它来自的字符串的引用。我想可以编写一个程序来检测导致泄漏的这种和其他常见模式。但是,我不知道任何当前可用的程序可能会进行此类泄漏检测。

答案 2 :(得分:1)

除非您使用的是异常的JVM实现,否则只有当您持有比所需更长的对象时才会真正发生内存“泄漏”。如果Java检测到对象仍然可以访问,它将永远不会收集它,因为它可能会影响程序语义。

如果您对降低内存使用率感兴趣,请尝试断开对不再需要的对象的引用,或者使用WeakReferenceWeakHashMap来保存对象的存储方式它们可以自动回收。

如果您想尝试追踪内存浪费空间的确切内容,您可能需要通过查看对象访问来检查this paper检测潜在的内存泄漏。这个工具看起来效果很好,虽然我对它并不熟悉。

希望这有帮助!

答案 3 :(得分:0)

jmap是你的朋友。当前(sun / oracle)JVM中存在一些泄漏但我非常怀疑OP正在谈论。 终结器类似于幻像引用(java.lang.ref.FinalReference的impl;它们本身不会使GC混乱,使得finalize方法提供的对象是不同的)