本文分析一下可能引起java内存泄露的场景：

通过 finalize() 方法

终结器finalizers的使用是潜在内存泄漏问题的另一个来源。每当类的 finalize() 方法被重写时，该类的对象不会立即被垃圾回收。相反，GC将它们排队等待最后确定，这将在稍后的时间点发生。

另外，如果我们的应用程序不能更快地完成或最终处理一个错误，那么如果我们的应用程序不能更快地完成一个错误，那么我们的应用程序就不能完成。

为了证明这一点，让我们考虑一下，我们已经为一个类重写了 finalize() 方法，并且该方法需要一点时间来执行。当此类的大量对象被垃圾回收时，在VisualVM中，它看起来像：

但是，如果我们只删除重写的 finalize() 方法，则同一个程序会给出以下响应：

如何预防？

我们应该避免使用终结器

内部字符串

当Java 7从 PermGen转移到 HeapSpace 时，Java字符串池经历了一次重大变化。但是对于在版本6及以下运行的应用程序，我们在处理大字符串时应该更加注意。

如果我们读取一个巨大的字符串对象，并在该对象上调用 intern() ，那么它将进入字符串池，该池位于PermGen(永久内存)中，只要我们的应用程序运行，它就会一直留在那里。这会阻塞内存并在我们的应用程序中造成内存泄漏。

JVM 1.6中这个例子的PermGen在VisualVM中如下所示：

与此相反，在一个方法中，如果我们只是从文件中读取一个字符串，而不是对其进行内接，那么PermGen看起来像：

如何预防？

解决这个问题最简单的方法是升级到最新的Java版本，因为从JavaVersion7开始，字符串池被移到HeapSpace如果要处理大型字符串，请增大PermGen空间的大小，以避免任何潜在的 OutOfMemoryError ：-XX:MaxPermSize=512m使用ThreadLocals

ThreadLocal是一种构造，它使我们能够将状态隔离到特定线程，从而允许我们实现线程安全。

当使用这个结构时，每个线程都将持有一个对其ThreadLocal变量副本的隐式引用，并将维护自己的副本，而不是在多个线程之间共享资源，只要线程是活动的。

尽管 ThreadLocal变量有很多优点，但是它的使用还是有争议的，因为如果使用不当，它们会导致内存泄漏。Joshua Bloch曾经评论过线程本地用法：

线程池的草率使用与线程局部变量的草率使用可能会导致意外的对象保留，正如在许多地方所指出的那样。但把责任推到线程本地上是没有道理的。

threadlocal导致内存泄漏

一旦保持线程不再活动， threadlocal 就应该被垃圾回收。但是当 threadlocal 与现代应用服务器一起使用时，问题就出现了。

现代应用服务器使用一个线程池来处理请求，而不是创建新的请求(例如apache tomcat中的 Executor )。此外，它们还使用单独的类加载器。

由于应用程序服务器中的线程池遵循线程重用的概念，因此它们永远不会被垃圾回收，而是被重用以服务于另一个请求。

现在，如果任何类创建了一个 ThreadLocal 变量，但没有显式地删除它，那么即使在web应用程序停止之后，该对象的副本也将保留在工作线程中，从而防止对象被垃圾回收。

如何预防？

remove()ThreadLocals.set(null)try { threadLocal.set(System.nanoTime()); //... further processing}finally { threadLocal.remove();}解决内存泄漏的其他方法

虽然在处理内存泄漏时没有一刀切的解决方案，但是我们可以通过一些方法将这些泄漏最小化。

启用分析

Java探查器是监视和诊断应用程序内存泄漏的工具。它们分析应用程序内部发生的事情—例如，如何分配内存。

使用探查器，我们可以比较不同的方法，并找到可以最佳利用资源的领域。

在本教程我们一直在使用javavisualvm。请查看我们的Java探查器指南，了解不同类型的探查器，如任务控制、JProfiler、YourKit、Java VisualVM和Netbeans探查器。

详细的垃圾收集

通过启用详细的垃圾收集，我们可以跟踪GC的详细跟踪。要实现这一点，我们需要在JVM配置中添加以下内容：

-verbose:gc通过添加此参数，我们可以看到GC内部发生的详细情况：

使用引用对象以避免内存泄漏

我们还可以使用Java中内置的引用对象 java.lang.ref处理内存泄漏的包。使用 java.lang.ref包，而不是直接引用对象，我们使用对对象的特殊引用，以便于对它们进行垃圾回收。

引用队列旨在让我们知道垃圾回收器执行的操作。

Eclipse内存泄漏警告

对于jdk1.5及更高版本的项目，每当遇到明显的内存泄漏情况时，Eclipse都会显示警告和错误。因此，在Eclipse中开发时，我们可以定期访问“Problems”选项卡，并对内存泄漏警告(如果有)保持警惕：

Benchmarking基准测试

我们可以通过执行基准测试来测量和分析Java代码的性能。这样，我们就可以比较不同方法的性能来完成相同的任务。这可以帮助我们选择更好的方法，也可以帮助我们保存记忆。

有关基准测试的更多信息，请访问我们的Java微基准标记教程。

代码评审

最后，我们总是采用经典的、老派的方法来完成简单的代码遍历。

在某些情况下，即使是这种看起来微不足道的方法也有助于消除一些常见的内存泄漏问题。

结论

通俗地说，我们可以认为内存泄漏是一种通过阻塞重要内存资源而降低应用程序性能的疾病。而且，与所有其他疾病一样，如果得不到治愈，随着时间的推移，它会导致致命的应用程序崩溃。

内存泄漏很难解决，找到它们需要对Java语言进行复杂的掌握。在处理内存泄漏时，没有一刀切的解决方案，因为泄漏可以通过各种各样的事件发生。

但是，如果我们求助于最佳实践并定期执行严格的代码遍历和分析，那么我们就可以将应用程序中内存泄漏的风险降到最低。

原文链接：http://javakk.com/911.html

如果觉得本文对你有帮助，可以转发关注支持一下

转载于http://blog.csdn.net/wtt945482445/article/details/52483944

Java 内存分配策略

Java 程序运行时的内存分配策略有三种,分别是静态分配,栈式分配,和堆式分配，对应的，三种存储策略使用的内存空间主要分别是静态存储区(也称方法区)、栈区和堆区。

静态存储区(方法区)：主要存放静态数据、全局 static 数据和常量。这块内存在程序编译时就已经分配好，并且在程序整个运行期间都存在。

栈区 ：当方法被执行时，方法体内的局部变量(其中包括基础数据类型、对象的引用)都在栈上创建，并在方法执行结束时这些局部变量所持有的内存将会自动被释放。因为栈内存分配运算内置于处理器的指令集中，效率很高，但是分配的内存容量有限。

堆区 ： 又称动态内存分配，通常就是指在程序运行时直接 new 出来的内存，也就是对象的实例。这部分内存在不使用时将会由 Java 垃圾回收器来负责回收。

栈与堆的区别：

在方法体内定义的(局部变量)一些基本类型的变量和对象的引用变量都是在方法的栈内存中分配的。当在一段方法块中定义一个变量时，Java 就会在栈中为该变量分配内存空间，当超过该变量的作用域后，该变量也就无效了，分配给它的内存空间也将被释放掉，该内存空间可以被重新使用。

堆内存用来存放所有由 new 创建的对象(包括该对象其中的所有成员变量)和数组。在堆中分配的内存，将由 Java 垃圾回收器来自动管理。在堆中产生了一个数组或者对象后，还可以在栈中定义一个特殊的变量，这个变量的取值等于数组或者对象在堆内存中的首地址，这个特殊的变量就是我们上面说的引用变量。我们可以通过这个引用变量来访问堆中的对象或者数组。

举个例子:

1 public classSample {2 int s1 = 0;3 Sample mSample1 = newSample();4

5 public voidmethod() {6 int s2 = 1;7 Sample mSample2 = newSample();8 }9 }10

11 Sample mSample3 = new Sample();

Sample 类的局部变量 s2 和引用变量 mSample2 都是存在于栈中，但 mSample2 指向的对象是存在于堆上的。

mSample3 指向的对象实体存放在堆上，包括这个对象的所有成员变量 s1 和 mSample1，而它自己存在于栈中。

结论：

局部变量的基本数据类型和引用存储于栈中，引用的对象实体存储于堆中。—— 因为它们属于方法中的变量，生命周期随方法而结束。

成员变量全部存储与堆中(包括基本数据类型，引用和引用的对象实体)—— 因为它们属于类，类对象终究是要被new出来使用的。

了解了 Java 的内存分配之后，我们再来看看 Java 是怎么管理内存的。

Java是如何管理内存

Java的内存管理就是对象的分配和释放问题。在 Java 中，程序员需要通过关键字 new 为每个对象申请内存空间 (基本类型除外)，所有的对象都在堆 (Heap)中分配空间。另外，对象的释放是由 GC 决定和执行的。在 Java 中，内存的分配是由程序完成的，而内存的释放是由 GC 完成的，这种收支两条线的方法确实简化了程序员的工作。但同时，它也加重了JVM的工作。这也是 Java 程序运行速度较慢的原因之一。因为，GC 为了能够正确释放对象，GC 必须监控每一个对象的运行状态，包括对象的申请、引用、被引用、赋值等，GC 都需要进行监控。

监视对象状态是为了更加准确地、及时地释放对象，而释放对象的根本原则就是该对象不再被引用。

为了更好理解 GC 的工作原理，我们可以将对象考虑为有向图的顶点，将引用关系考虑为图的有向边，有向边从引用者指向被引对象。另外，每个线程对象可以作为一个图的起始顶点，例如大多程序从 main 进程开始执行，那么该图就是以 main 进程顶点开始的一棵根树。在这个有向图中，根顶点可达的对象都是有效对象，GC将不回收这些对象。如果某个对象 (连通子图)与这个根顶点不可达(注意，该图为有向图)，那么我们认为这个(这些)对象不再被引用，可以被 GC 回收。

以下，我们举一个例子说明如何用有向图表示内存管理。对于程序的每一个时刻，我们都有一个有向图表示JVM的内存分配情况。以下右图，就是左边程序运行到第6行的示意图。

Java使用有向图的方式进行内存管理，可以消除引用循环的问题，例如有三个对象，相互引用，只要它们和根进程不可达的，那么GC也是可以回收它们的。这种方式的优点是管理内存的精度很高，但是效率较低。另外一种常用的内存管理技术是使用计数器，例如COM模型采用计数器方式管理构件，它与有向图相比，精度行低(很难处理循环引用的问题)，但执行效率很高。

什么是Java中的内存泄露

在Java中，内存泄漏就是存在一些被分配的对象，这些对象有下面两个特点，首先，这些对象是可达的，即在有向图中，存在通路可以与其相连；其次，这些对象是无用的，即程序以后不会再使用这些对象。如果对象满足这两个条件，这些对象就可以判定为Java中的内存泄漏，这些对象不会被GC所回收，然而它却占用内存。

在C++中，内存泄漏的范围更大一些。有些对象被分配了内存空间，然后却不可达，由于C++中没有GC，这些内存将永远收不回来。在Java中，这些不可达的对象都由GC负责回收，因此程序员不需要考虑这部分的内存泄露。

通过分析，我们得知，对于C++，程序员需要自己管理边和顶点，而对于Java程序员只需要管理边就可以了(不需要管理顶点的释放)。通过这种方式，Java提高了编程的效率。

因此，通过以上分析，我们知道在Java中也有内存泄漏，但范围比C++要小一些。因为Java从语言上保证，任何对象都是可达的，所有的不可达对象都由GC管理。

对于程序员来说，GC基本是透明的，不可见的。虽然，我们只有几个函数可以访问GC，例如运行GC的函数System.gc()，但是根据Java语言规范定义， 该函数不保证JVM的垃圾收集器一定会执行。因为，不同的JVM实现者可能使用不同的算法管理GC。通常，GC的线程的优先级别较低。JVM调用GC的策略也有很多种，有的是内存使用到达一定程度时，GC才开始工作，也有定时执行的，有的是平缓执行GC，有的是中断式执行GC。但通常来说，我们不需要关心这些。除非在一些特定的场合，GC的执行影响应用程序的性能，例如对于基于Web的实时系统，如网络游戏等，用户不希望GC突然中断应用程序执行而进行垃圾回收，那么我们需要调整GC的参数，让GC能够通过平缓的方式释放内存，例如将垃圾回收分解为一系列的小步骤执行，Sun提供的HotSpot JVM就支持这一特性。

同样给出一个 Java 内存泄漏的典型例子，

1 Vector v = new Vector(10);2 for (int i = 1; i < 100; i++) {3 Object o = newObject();4 v.add(o);5 o = null;6 }

在这个例子中，我们循环申请Object对象，并将所申请的对象放入一个 Vector 中，如果我们仅仅释放引用本身，那么 Vector 仍然引用该对象，所以这个对象对 GC 来说是不可回收的。因此，如果对象加入到Vector 后，还必须从 Vector 中删除，最简单的方法就是将 Vector 对象设置为 null。

详细Java中的内存泄漏

1.Java内存回收机制

不论哪种语言的内存分配方式，都需要返回所分配内存的真实地址，也就是返回一个指针到内存块的首地址。Java中对象是采用new或者反射的方法创建的，这些对象的创建都是在堆(Heap)中分配的，所有对象的回收都是由Java虚拟机通过垃圾回收机制完成的。GC为了能够正确释放对象，会监控每个对象的运行状况，对他们的申请、引用、被引用、赋值等状况进行监控，Java会使用有向图的方法进行管理内存，实时监控对象是否可以达到，如果不可到达，则就将其回收，这样也可以消除引用循环的问题。在Java语言中，判断一个内存空间是否符合垃圾收集标准有两个：一个是给对象赋予了空值null，以下再没有调用过，另一个是给对象赋予了新值，这样重新分配了内存空间。

2.Java内存泄漏引起的原因

内存泄漏是指无用对象(不再使用的对象)持续占有内存或无用对象的内存得不到及时释放，从而造成内存空间的浪费称为内存泄漏。内存泄露有时不严重且不易察觉，这样开发者就不知道存在内存泄露，但有时也会很严重，会提示你Out of memory。j

Java内存泄漏的根本原因是什么呢？长生命周期的对象持有短生命周期对象的引用就很可能发生内存泄漏，尽管短生命周期对象已经不再需要，但是因为长生命周期持有它的引用而导致不能被回收，这就是Java中内存泄漏的发生场景。具体主要有如下几大类：

1、静态集合类引起内存泄漏：

像HashMap、Vector等的使用最容易出现内存泄露，这些静态变量的生命周期和应用程序一致，他们所引用的所有的对象Object也不能被释放，因为他们也将一直被Vector等引用着。

例如

Static Vector v = new Vector(10);

for (int i = 1; i<100; i++)

{

Object o = new Object();

v.add(o);

o = null;

}

在这个例子中，循环申请Object 对象，并将所申请的对象放入一个Vector 中，如果仅仅释放引用本身(o=null)，那么Vector 仍然引用该对象，所以这个对象对GC 来说是不可回收的。因此，如果对象加入到Vector 后，还必须从Vector 中删除，最简单的方法就是将Vector对象设置为null。

2、当集合里面的对象属性被修改后，再调用remove()方法时不起作用。

例如：

1 public static voidmain(String[] args)2 {3 Set set = new HashSet();4 Person p1 = new Person("唐僧","pwd1",25);5 Person p2 = new Person("孙悟空","pwd2",26);6 Person p3 = new Person("猪八戒","pwd3",27);7 set.add(p1);8 set.add(p2);9 set.add(p3);10 System.out.println("总共有:"+set.size()+" 个元素!"); //结果：总共有:3 个元素!

11 p3.setAge(2); //修改p3的年龄,此时p3元素对应的hashcode值发生改变

12

13 set.remove(p3); //此时remove不掉，造成内存泄漏

14

15 set.add(p3); //重新添加，居然添加成功

16 System.out.println("总共有:"+set.size()+" 个元素!"); //结果：总共有:4 个元素!

17 for(Person person : set)18 {19 System.out.println(person);20 }21 }

3、监听器

在java 编程中，我们都需要和监听器打交道，通常一个应用当中会用到很多监听器，我们会调用一个控件的诸如addXXXListener()等方法来增加监听器，但往往在释放对象的时候却没有记住去删除这些监听器，从而增加了内存泄漏的机会。

4、各种连接

比如数据库连接(dataSourse.getConnection())，网络连接(socket)和io连接，除非其显式的调用了其close()方法将其连接关闭，否则是不会自动被GC 回收的。对于Resultset 和Statement 对象可以不进行显式回收，但Connection 一定要显式回收，因为Connection 在任何时候都无法自动回收，而Connection一旦回收，Resultset 和Statement 对象就会立即为NULL。但是如果使用连接池，情况就不一样了，除了要显式地关闭连接，还必须显式地关闭Resultset Statement 对象(关闭其中一个，另外一个也会关闭)，否则就会造成大量的Statement 对象无法释放，从而引起内存泄漏。这种情况下一般都会在try里面去的连接，在finally里面释放连接。

5、内部类和外部模块的引用

内部类的引用是比较容易遗忘的一种，而且一旦没释放可能导致一系列的后继类对象没有释放。此外程序员还要小心外部模块不经意的引用，例如程序员A 负责A 模块，调用了B 模块的一个方法如：

public void registerMsg(Object b);

这种调用就要非常小心了，传入了一个对象，很可能模块B就保持了对该对象的引用，这时候就需要注意模块B 是否提供相应的操作去除引用。

6、单例模式

不正确使用单例模式是引起内存泄漏的一个常见问题，单例对象在初始化后将在JVM的整个生命周期中存在(以静态变量的方式)，如果单例对象持有外部的引用，那么这个对象将不能被JVM正常回收，导致内存泄漏，考虑下面的例子：

1 classA{2 publicA(){3 B.getInstance().setA(this);4 }5 ....6 }7 //B类采用单例模式

8 classB{9 privateA a;10 private static B instance=newB();11 publicB(){}12 public staticB getInstance(){13 returninstance;14 }15 public voidsetA(A a){16 this.a=a;17 }18 //getter...

19 }

显然B采用singleton模式，它持有一个A对象的引用，而这个A类的对象将不能被回收。想象下如果A是个比较复杂的对象或者集合类型会发生什么情况