内存，它在计算机中含义为：
内存是计算机中重要的部件之一，它是与CPU进行沟通的桥梁。计算机中所有程序的运行都是在内存中进行的，因此内存的性能对计算机的影响非常大。内存(Memory)也被称为内存储器和主存储器，其作用是用于暂时存放CPU中的运算数据，以及与硬盘等外部存储器交换的数据。只要计算机在运行中，CPU就会把需要运算的数据调到内存中进行运算，当运算完成后CPU再将结果传送出来，内存的运行也决定了计算机的稳定运行。 内存是由内存芯片、电路板、金手指等部分组成的。 [来自百度百科]
那么在Java虚拟机中，它的内存是怎么样的？
虽然Java虚拟机在自动内存管理机制下，Java程序员无需为每个new操作写配对的delete/free代码，也不容易出现内存泄漏和内存溢出的问题。但是呢？凡事都有个例外，在现实中还是经常能碰到内存泄漏和内存溢出什么的。
所以这篇就是为了对Java虚拟机的内存进行了解，为解决问题做准备。
Java虚拟机的内存划分图，
通过上面我们了解到虚拟机的内存的基本信息。
那么，来到主菜：内存泄漏。
在前面我们讲到内存泄漏和内存溢出。但是我们了解它们是怎么定义和区分吗？
我们通俗来的话，
- 内存溢出：你申请了10个字节的空间，但是你在这个空间写入11或以上字节的数据，出现溢出。
- 内存泄漏：你用new申请了一块内存，后来很长时间都不再使用了（按理应该释放），但是因为一直被某个或某些实例所持有导致 GC 不能回收，也就是该被释放的对象没有释放。
那么接着来看下，
曾经在StackOverflow问答网站上有一个热门讨论：如何用Java编写一段会发生内存泄露的代码。
转载链接：如何用Java编写一段代码引发内存泄露
Q：刚才我参加了面试，面试官问我如何写出会发生内存泄露的Java代码。这个问题我一点思路都没有，好囧。
A1：通过以下步骤可以很容易产生内存泄露（程序代码不能访问到某些对象，但是它们仍然保存在内存中）:
- 应用程序创建一个长时间运行的线程（或者使用线程池，会更快地发生内存泄露）。
- 线程通过某个类加载器（可以自定义）加载一个类。
- 该类分配了大块内存（比如new byte[1000000]），在某个静态变量存储一个强引用，然后在ThreadLocal中存储它自身的引用。分配额外的内存new byte[1000000]是可选的(类实例泄露已经足够了)，但是这样会使内存泄露更快。
- 线程清理自定义的类或者加载该类的类加载器。
- 重复以上步骤。
由于没有了对类和类加载器的引用，ThreadLocal中的存储就不能被访问到。ThreadLocal持有该对象的引用，它也就持有了这个类及其类加载器的引用，类加载器持有它所加载的类的所有引用，这样GC无法回收ThreadLocal中存储的内存。在很多JVM的实现中Java类和类加载器直接分配到permgen区域不执行GC，这样导致了更严重的内存泄露。
这种泄露模式的变种之一就是如果你经常重新部署以任何形式使用了ThreadLocal的应用程序、应用容器（比如Tomcat）会很容易发生内存泄露（由于应用容器使用了如前所述的线程，每次重新部署应用时将使用新的类加载器）。
A2：
- 静态变量引用对象
class MemorableClass {
static final ArrayList list = new ArrayList(100);
}
- 调用长字符串的String.intern()
String str=readString(); // read lengthy string any source db,textbox/jsp etc..
// This will place the string in memory pool from which you cant remove
str.intern();
- 未关闭已打开流(文件，网络等)
try {
BufferedReader br = new BufferedReader(new FileReader(inputFile));
...
...
} catch (Exception e) {
e.printStacktrace();
}
- 未关闭连接
try {
Connection conn = ConnectionFactory.getConnection();
...
...
} catch (Exception e) {
e.printStacktrace();
}
- JVM的GC不可达区域
比如通过native方法分配的内存。
- web应用在application范围的对象，应用未重启或者没有显式移除
getServletContext().setAttribute("SOME_MAP", map);
- web应用在session范围的对象，未失效或者没有显式移除
session.setAttribute("SOME_MAP", map);
- 不正确或者不合适的JVM选项
比如IBM JDK的noclassgc阻止了无用类的垃圾回收
A3：如果HashSet未正确实现(或者未实现)hashCode()或者equals(),会导致集合中持续增加“副本”。如果集合不能地忽略掉它应该忽略的元素，它的大小就只能持续增长，而且不能删除这些元素。
如果你想要生成错误的键值对，可以像下面这样做：
class BadKey {
// no hashCode or equals();
public final String key;
public BadKey(String key) { this.key = key; }
}
Map map = System.getProperties();
map.put(new BadKey("key"), "value"); // Memory leak even if your threads die.
A4：除了被遗忘的监听器，静态引用，hashmap中key错误/被修改或者线程阻塞不能结束生命周期等典型内存泄露场景，下面介绍一些不太明显的Java发生内存泄露的情况，主要是线程相关的。
- Runtime.addShutdownHook后没有移除，即使使用了removeShutdownHook，由于ThreadGroup类对于未启动线程的bug，它可能不被回收，导致ThreadGroup发生内存泄露。
- 创建但未启动线程，与上面的情形相同。
- 创建继承了ContextClassLoader和AccessControlContext的线程，ThreadGroup和InheritedThreadLocal的使用，所有这些引用都是潜在的泄露，以及所有被类加载器加载的类和所有静态引用等等。这对ThreadFactory接口作为重要组成元素整个j.u.c.Executor框架(java.util.concurrent)的影响非常明显，很多开发人员没有注意到它潜在的危险。而且很多库都会按照请求启动线程。
- ThreadLocal缓存，很多情况下不是好的做法。有很多基于ThreadLocal的简单缓存的实现，但是如果线程在它的期望生命周期外继续运行ContextClassLoader将发生泄露。除非真正必要不要使用ThreadLocal缓存。
- 当ThreadGroup自身没有线程但是仍然有子线程组时调用ThreadGroup.destroy()。发生内存泄露将导致该线程组不能从它的父线程组移除，不能枚举子线程组。
- 使用WeakHashMap，value直接(间接)引用key，这是个很难发现的情形。这也适用于继承Weak/SoftReference的类可能持有对被保护对象的强引用。
- 使用http(s)协议的java.net.URL下载资源。KeepAliveCache在系统ThreadGroup创建新线程，导致当前线程的上下文类加载器内存泄露。没有存活线程时线程在第一次请求时创建，所以很有可能发生泄露。(在Java7中已经修正了，创建线程的代码合理地移除了上下文类加载器。)
- 使用InflaterInputStream在构造函数(比如PNGImageDecoder)中传递new java.util.zip.Inflater()，不调用inflater的end()。仅仅是new的话非常安全，但如果自己创建该类作为构造函数参数时调用流的close()不能关闭inflater，可能发生内存泄露。这并不是真正的内存泄露因为它会被finalizer释放。但这消耗了很多native内存，导致linux的oom_killer杀掉进程。所以这给我们的教训是：尽可能早地释放native资源。
- java.util.zip.Deflater也一样，它的情况更加严重。好的地方可能是很少用到Deflater。如果自己创建了Deflater或者Inflater记住必须调用end()。
------------------------------------------------原文结束---------------------------------------------------
通过上面的内存泄漏的转载文章，我们了解到内存泄漏的发生情况有很多种。但是你要是结合一开始的内存结构图理解，那就非常容易了。
在Java虚拟机那张图中，你知道那部分是唯一一个在Java虚拟机规范中没有规定任何OutOfMemoryError情况的区域吗？
参考资料：
2661
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
