TSS翻译：常见的Java内存问题第一部分

TSS翻译：常见的Java内存问题第一部分

原文链接：http://www.theserverside.com/news/thread.tss?thread_id=62217

http://blog.dynatrace.com/2011/04/20/the-top-java-memory-problems-part-1/

内存和垃圾收集器一直是Java应用程序最值得关注的问题之一。当我们对java有JVM的内存收集机制而津津乐道的时候，恐怕大多数人又对GC垃圾收集的机制莫讳如深。dynaTrace的Michael Kopp 也有同感，不过他把引起java内存泄漏的主要原因列出来了。

<!--[if !supportLists]-->1、<!--[endif]-->线程局部变量 Thread Local Variables

主要是在使用线程池的情况下容易出现，使用heap dump 容易找出问题所在；

2、<!--[endif]-->可变的静态字段和集合Mutable static fields and collections

避免这种情况的很简单少用。A good architectural rule is not to use mutable static objects at all, most of the time there is a better alternative.

3、<!--[endif]-->循环和复杂的双向引用Circular and complex bi-directional references

对方举了一个经典的例子：

org.w3c.dom.Document doc = readXmlDocument();
org.w3c.dom.Node child = doc.getDocumentElement().getFirstChild();
doc.removeNode(child);
doc = null;

<!--[if !supportLists]-->4、<!--[endif]-->JNI内存泄漏 JNI memory leaks

用的不多，不多说了。

<!--[if !supportLists]-->5、<!--[endif]-->类的 Equals/hashcode 不正确的实现

这样的类使用HashMap容易的时候容易出问题。

避免这种情况的方法是做测试，比如这个工具：http://code.google.com/p/equalsverifier/

<!--[if !supportLists]-->6、<!--[endif]-->类加载器引起的内存泄漏

Class Loader 的层面比较底层，一般是应用程序服务器和OSGi 容器中容易出现。

也许回复更精彩，把1,2,6综合起来了：

static ThreadLocal myWrapper =
new ThreadLocal() {
NotThreadSafeObject initialValue() {
return new NotThreadSafeObject();
}
}

…
myWrapper.get().someMethod()
…

More details at http://www.szegedi.org/articles/memleak.html

如何使用：dynaTrace 见这里：

http://blog.dynatrace.com/2011/04/13/application-performance-monitoring-in-production-a-step-by-step-guide/