java中的内存溢出与内存泄漏是什么

　　内存泄漏(Memory Leak)

　　概念

　　内存泄漏（Memory Leak）是指程序中己动态分配的堆内存由于某种原因程序未释放或无法释放，造成系统内存的浪费，导致程序运行速度减慢甚至系统崩溃等严重后果。

　　发生条件

　　内存泄漏必须满足以下两个条件

　　对象是可达的。即在有向图中，存在通道达到该对象，GC不会回收

　　对象是无用的。即程序以后不会再使用该对象

　　发生场景

　　静态集合类引起内存泄漏

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

　　Static Vector v = new Vector(10);

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

　　{

　　Object o = new Object(); //每次创建新的对象

　　v.add(o);

　　o = null; //将对象添加到集合后将对象的引用置空

　　}

　　//因为对象的引用置空之后,JVM已经失去的使用该对象的价值,本应该被GC清除,但是在vector集合中还存在着此对象的引用,导致没能顺利清除

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

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

　　public static void main(String[] args) {

　　Set set = new HashSet();

　　Person p1 = new Person("唐僧", "pwd1", 25);

　　Person p2 = new Person("孙悟空", "pwd2", 26);

　　Person p3 = new Person("猪八戒", "pwd3", 27);

　　set.add(p1);

　　set.add(p2);

　　set.add(p3);

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

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

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

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

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

　　for (Person person : set) {

　　System.out.println(person);

　　System.out.println(person.hashCode());

　　}

　　}

　　监听器

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

　　各种连接

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

　　单例模式

　　如果单例对象持有外部对象的引用，那么这个外部对象将不能被jvm正常回收，导致内存泄露。

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

　　class A {

　　public A() {

　　B.getInstance().setA(this);

　　}

　　....

　　}

　　//B类采用单例模式

　　class B {

　　private A a;

　　private static B instance = new B();

　　public B() {

　　}

　　public static B getInstance() {

　　return instance;

　　}

　　public void setA(A a) {

　　this.a = a;

　　}

　　//getter...

　　}

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

　　分类郑州妇科医院 http://www.zyfuke.com/

　　1. 常发性内存泄漏。 发生内存泄漏的代码会被多次执行到，每次被执行的时候都会导致一块内存泄漏。

　　2. 偶发性内存泄漏。 发生内存泄漏的代码只有在某些特定环境或操作过程下才会发生。常发性和偶发性是相对的。对于特定的环境，偶发性的也许就变成了常发性的。所以测试环境和测试方法对检测内存泄漏至关重要。

　　3. 一次性内存泄漏。 发生内存泄漏的代码只会被执行一次，或者由于算法上的缺陷，导致总会有一块仅且一块内存发生泄漏。比如，在类的构造函数中分配内存，在析构函数中却没有释放该内存，所以内存泄漏只会发生一次。

　　4. 隐式内存泄漏。 程序在运行过程中不停的分配内存，但是直到结束的时候才释放内存。严格的说这里并没有发生内存泄漏，因为最终程序释放了所有申请的内存。但是对于一个服务器程序，需要运行几天，几周甚至几个月，不及时释放内存也可能导致最终耗尽系统的所有内存。所以，我们称这类内存泄漏为隐式内存泄漏。

　　内存溢出(Out Of Memory)

　　概念

　　程序在申请内存时，没有足够的内存空间供其使用

　　内存溢出已经是软件开发历史上存在了近40年的“老大难”问题，像在“红色代码”病毒事件中表现的那样，它已经成为黑客攻击企业网络的“罪魁祸首”。 如在一个域中输入的数据超过了它的要求就会引发数据溢出问题，多余的数据就可以作为指令在计算机上运行。据有关安全小组称，操作系统中超过50%的安全漏洞都是由内存溢出引起的，其中大多数与微软的技术有关。内存溢出错误是大数据处理平台的常见错误，例如，国际知名的程序开发者问答网站 stackoverflow 上关于“Hadoop out of memory”的问题超过10000个，在Spark邮件列表上有10%的问题是关于“out of memory”。 内存溢出错误会导致处理数据的任务失败，甚至会引发平台崩溃等严重后果。对于内存溢出大部分的处理方法是重新执行任务，然而， 对于由系统配置、数据流、用户代码等原因而导致的内存溢出错误，即使用户重新执行任务依然无法避免

　　发生条件

　　内存中加载的数据过于庞大，如一次性从数据库取出过多的数据

　　集合类中，有对对象的引用，使用完后未清空，使得JVM不能不嫩回收

　　代码中存在死循环或循环产生过多重复的对象实体

　　使用的第三方软件存在bug

　　启动参数内存值设置的过小

　　分类

　　OutOfMemoryError： PermGen space

　　PermGen Space指的是内存的永久保存区，该块内存主要是被JVM用来存放class和meta信息的，当class被加载loader的时候就会被存储到该内存区中，与存放类的实例的heap区不同，java中的垃圾回收器GC不会在主程序运行期对PermGen space进行清理。

　　因此，程序启动时如果需要加载的信息太多，超出这个空间的大小，则会发生溢出。

　　解决方案： 增加空间分配——增加java虚拟机中的XX:PermSize和XX:MaxPermSize参数的大小，其中XX:PermSize是初始永久保存区域大小，XX:MaxPermSize是最大永久保存区域大小。

　　OutOfMemoryError：Java heap space

　　heap space是Java内存中的堆区，主要用来存放对象，当对象太多超出了空间大小，GC又来不及释放的时候，就会发生溢出错误。即内存泄露越来越严重时，可能会发生内存溢出。

　　解决方案：(1)、检查程序，减少大量重复创建对象的死循环，减少内存泄露。

　　(2)、增加Java虚拟机中Xms(初始堆大小)和Xmx(最大堆大小)参数的大小。

　　StackOverFlowError

　　stack是Java内存中的栈空间，主要用来存放方法中的变量，参数等临时性的数据的，发生溢出一般是因为分配空间太小，或是执行的方法递归层数太多创建了占用了太多栈帧导致溢出。

　　解决方案： 修改配置参数-Xss参数增加线程栈大小之外，优化程序是尤其重要。

　　OOM排查思路

　　第一步，修改JVM启动参数，直接增加内存。(-Xms，-Xmx参数一定不要忘记加。)

　　第二步，检查错误日志，查看“OutOfMemery”错误前，是否有其他异常或错误

　　第三步，对代码进行走查分析，找出可能发生内存溢出的位置

　　重点排查以下几点：

　　1.检查对数据库查询中，是否有一次获得全部数据的查询。一般来说，如果一次取十万条记录到内存，就可能引起内存溢出。这个问题比较隐蔽，在上线前，数据库中数据较少，不容易出问题，上线后，数据库中数据多了，一次查询就有可能引起内存溢出。因此对于数据库查询尽量采用分页的方式查询。

　　2.检查代码中是否有死循环或递归调用。

　　3.检查是否有大循环重复产生新对象实体。

　　4.检查List、MAP等集合对象是否有使用完后，未清除的问题。List、MAP等集合对象会始终存有对对象的引用，使得这些对象不能被GC回收。

　　第四步，使用内存查看工具动态查看内存使用情况