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 见这里：