内存溢出和内存泄漏的区别

1.1内存溢出：（Out Of Memory—OOM）

系统已经不能再分配出你所需要的空间，比如你需要100M的空间，系统只剩90M了，这就叫内存溢出

例子：一个盘子用尽各种方法只能装4个果子，你装了5个，结果掉倒地上不能吃了。这就是溢出。比方说栈，栈满时再做进栈必定产生空间溢出，叫上溢，栈空时再做退栈也产生空间溢出，称为下溢。就是分配的内存不足以放下数据项序列,称为内存溢出。说白了就是我承受不了那么多，那我就报错，

1.2内存泄漏： (Memory Leak)----》强引用所指向的对象不会被回收，可能导致内存泄漏，虚拟机宁愿抛出OOM也不会去回收他指向的对象

意思就是你用资源的时候为他开辟了一段空间，当你用完时忘记释放资源了，这时内存还被占用着，一次没关系，但是内存泄漏次数多了就会导致内存溢出

例子：你向系统申请分配内存进行使用(new)，可是使用完了以后却不归还(delete)，结果你申请到的那块内存你自己也不能再访问（也许你把它的地址给弄丢了），而系统也不能再次将它分配给需要的程序。就相当于你租了个带钥匙的柜子，你存完东西之后把柜子锁上之后，把钥匙丢了或者没有将钥匙还回去，那么结果就是这个柜子将无法供给任何人使用，也无法被垃圾回收器回收，因为找不到他的任何信息。

一般我们所说的内存泄漏指的是堆内存的泄露，堆内存是指程序从堆中分配的，大小随机的用完后必须显示释放的内存，C++/C中有free函数可以释放内存，java中有垃圾回收机制不用程序员自己手动调用释放

如果这块内存不释放，就不能再用了，这就叫这块内存泄漏了

---

2.以发生的方式来分类，内存泄漏可以分为4类：

1. 常发性内存泄漏。发生内存泄漏的代码会被多次执行到，每次被执行的时候都会导致一块内存泄漏。
2. 偶发性内存泄漏。发生内存泄漏的代码只有在某些特定环境或操作过程下才会发生。常发性和偶发性是相对的。对于特定的环境，偶发性的也许就变成了常发性的。所以测试环境和测试方法对检测内存泄漏至关重要。
3. 一次性内存泄漏。发生内存泄漏的代码只会被执行一次，或者由于算法上的缺陷，导致总会有一块仅且一块内存发生泄漏。比如，在类的构造函数中分配内存，在析构函数中却没有释放该内存，所以内存泄漏只会发生一次。
4. 隐式内存泄漏。程序在运行过程中不停的分配内存，但是直到结束的时候才释放内存。严格的说这里并没有发生内存泄漏，因为最终程序释放了所有申请的内存。但是对于一个服务器程序，需要运行几天，几周甚至几个月，不及时释放内存也可能导致最终耗尽系统的所有内存。所以，我们称这类内存泄漏为隐式内存泄漏。

从用户使用程序的角度来看，内存泄漏本身不会产生什么危害，作为一般的用户，根本感觉不到内存泄漏的存在。真正有危害的是内存泄漏的堆积，这会最终消耗尽系统所有的内存。从这个角度来说，一次性内存泄漏并没有什么危害，因为它不会堆积，而隐式内存泄漏危害性则非常大，因为较之于常发性和偶发性内存泄漏它更难被检测到

3.内存溢出的原因及解决方法：

内存溢出原因： 
1.内存中加载的数据量过于庞大，如一次从数据库取出过多数据； 
2.集合类中有对对象的引用，使用完后未清空，使得JVM不能回收； 
3.代码中存在死循环或循环产生过多重复的对象实体； 
4.使用的第三方软件中的BUG； 
5.启动参数内存值设定的过小
内存溢出的原因及解决方法：
修改JVM启动参数，直接增加内存。(-Xms，-Xmx参数一定不要忘记加。)
检查错误日志，查看“OutOfMemory”错误前是否有其 它异常或错误。
对代码进行走查和分析，找出可能发生内存溢出的位置。
 使用内存查看工具动态查看内存使用情况　　
　

对代码分析找出可能发生内存溢出的位置， 可能出现的几种情况：

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

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

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

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

引用《Effective Java(第三版)》— <7 消除过期的对象引用>这一章节：

如果你从使用手动内存管理的语言（如C或C++）切换到像Java这样的带有垃圾收集机制的语言，那么作为程 序员的工作就会变得容易多了，因为你的对象在使用完毕以后就自动回收了。当你第一次体验它的时候，它就像 魔法一样。这很容易让人觉得你不需要考虑内存管理，但这并不完全正确。 考虑以下简单的栈实现：

 1 // Can you spot the "memory leak"? 
 2 public class Stack { 
 3 			private Object[] elements; 
 4 			private int size = 0;
 5 			private static final int DEFAULT_INITIAL_CAPACITY = 16;
 6 
 7		 	public Stack() { 
 8 				elements = new Object[DEFAULT_INITIAL_CAPACITY]; 
 9		 	} 
 10 
 11 		public void push(Object e) { 
 12 			ensureCapacity(); 
 13 			elements[size++] = e;
 14 		} 
 15 
 16 		public Object pop() { 
 17 			if (size == 0) 
 18				 throw new EmptyStackException(); 
 19 			return elements[--size]; 20 } 
 21 
 22 		/** 
 23 		  * Ensure space for at least one more element, roughly 
 24 		  * doubling the capacity each time the array needs to grow. 
 25		   	  */ 
 26 		private void ensureCapacity() { 
 27			 if (elements.length == size) 
 28 				elements = Arrays.copyOf(elements, 2 * size + 1); 
 29			 } 
 30 } 

这个程序没有什么明显的错误（但是对于泛型版本，请参阅条目29）。你可以对它进行详尽的测试，它都会 成功地通过每一项测试，但有一个潜在的问题。笼统地说，程序有一个“内存泄漏”，由于垃圾回收器的活动的增 加，或内存占用的增加，静默地表现为性能下降。在极端的情况下，这样的内存泄漏可能会导致磁盘分⻚（disk paging），甚至导致内存溢出（OutOfMemoryError）的失败，但是这样的故障相对较少。 那么哪里发生了内存泄漏？如果一个栈增⻓后收缩，那么从栈弹出的对象不会被垃圾收集，即使使用栈的程 序不再引用这些对象。这是因为栈维护对这些对象的过期引用（obsoletereferences）。过期引用简单来说就是永 远不会解除的引用。在这种情况下，元素数组“活动部分（activeportion）”之外的任何引用都是过期的。活动部 分是由索引下标小于size的元素组成。 垃圾收集语言中的内存泄漏（更适当地称为无意的对象保留unintentional object retentions）是隐蔽的。 如果无意中保留了对象引用，那么不仅这个对象排除在垃圾回收之外，而且该对象引用的任何对象也是如此。即使 只有少数对象引用被无意地保留下来，也可以阻止垃圾回收机制对许多对象的回收，这对性能产生很大的影响。 这类问题的解决方法很简单：一旦对象引用过期，将它们设置为null。在我们的Stack类的情景下，只要 从栈中弹出，元素的引用就设置为过期。pop方法的修正版本如下所示：

1 public Object pop() { 
2 if (size == 0) 
3 throw new EmptyStackException(); 
4 Object result = elements[--size]; 
5 elements[size] = null; // Eliminate obsolete reference 
6 return result; 
7 } 

取消过期引用的另一个好处是，如果它们随后被错误地引用，程序立即抛出NullPointerException 异常，而不是悄悄地做继续做错误的事情。尽可能快地发现程序中的错误是有好处的。 当程序员第一次被这个问题困扰时，他们可能会在程序结束后立即清空所有对象引用。这既不是必要的，也 不是可取的；它不必要地搞乱了程序。清空对象引用应该是例外而不是规范。消除过期引用的最好方法是让包含引用的变量超出范围。如果在最近的作用域范围内定义每个变量（详⻅第57条），这种自然就会出现这种情况。

那么什么时候应该清空一个引用呢？Stack类的哪个方面使它容易受到内存泄漏的影响？简单地说，它管 理自己的内存。存储池（storagepool）由elements数组的元素组成（对象引用单元，而不是对象本身）。数组 中活动部分的元素(如前面定义的)被分配，其余的元素都是空闲的。垃圾收集器没有办法知道这些；对于垃圾收 集器来说，elements数组中的所有对象引用都同样有效。只有程序员知道数组的非活动部分不重要。程序员可 以向垃圾收集器传达这样一个事实，一旦数组中的元素变成非活动的一部分，就可以手动清空这些元素的引用。

一般来说，当一个类自己管理内存时，程序员应该警惕内存泄漏问题。每当一个元素被释放时，元素中包含 的任何对象引用都应该被清除。

另一个常⻅的内存泄漏来源是缓存。一旦将对象引用放入缓存中，很容易忘记它的存在，并且在它变得无关 紧要之后，仍然保留在缓存中。对于这个问题有几种解决方案。如果你正好想实现了一个缓存：只要在缓存之外存 在对某个项（entry）的键（key）引用，那么这项就是明确有关联的，就可以用WeakHashMap来表示缓存；这 些项在过期之后自动删除。记住，只有当缓存中某个项的生命周期是由外部引用到键（key）而不是值（value） 决定时，WeakHashMap才有用。

更常⻅的情况是，缓存项有用的生命周期不太明确，随着时间的推移一些项变得越来越没有价值。在这种情况 下，缓存应该偶尔清理掉已经废弃的项。这可以通过一个后台线程(也许是ScheduledThreadPoolExecutor )或将新的项添加到缓存时顺便清理。LinkedHashMap类使用它的removeEldestEntry方法实现了后一 种方案。对于更复杂的缓存，可能直接需要使用java.lang.ref。

第三个常⻅的内存泄漏来源是监听器和其他回调。如果你实现了一个API，其客户端注册回调，但是没有 显式地撤销注册回调，除非采取一些操作，否则它们将会累积。确保回调是垃圾收集的一种方法是只存储弱引用 （weakreferences），例如，仅将它们保存在WeakHashMap的键（key）中。

因为内存泄漏通常不会表现为明显的故障，所以它们可能会在系统中保持多年。通常仅在仔细的代码检查或 借助堆分析器（heapprofiler）的调试工具才会被发现。因此，学习如何预⻅这些问题，并防止这些问题发生，是 非常值得的。