内存泄漏，内存溢出总结以及相关解决方案

谁践踏了优雅 2022-12-25 01:00 225阅读 0赞

\*\*内存泄漏定义（memory leak）：\*\*一个不再被程序使用的对象或变量还在内存中占有存储空间。

一次内存泄漏似乎不会有大的影响，但内存泄漏堆积后的后果就是内存溢出。  
**内存溢出 out of memory** :指程序申请内存时，没有足够的内存供申请者使用，或者说，给了你一块存储int类型数据的存储空间，但是你却存储long类型的数据，那么结果就是内存不够用，此时就会报错OOM,即所谓的内存溢出。  
**二者的关系：**

1.  内存泄漏的堆积最终会导致内存溢出
2.  \*\*内存溢出：\*\*就是你要的内存空间超过了系统实际分配给你的空间，此时系统相当于没法满足你的需求，就会报内存溢出的错误。
3.  \*\*内存泄漏 ：\*\*是指你向系统申请分配内存进行使用(new)，可是使用完了以后却不归还(delete)，结果你申请到的那块内存你自己也不能再访问（也许你把它的地址给弄丢了），而系统也不能再次将它分配给需要的程序。就相当于你租了个带钥匙的柜子，你存完东西之后把柜子锁上之后，把钥匙丢了或者没有将钥匙还回去，那么结果就是这个柜子将无法供给任何人使用，也无法被垃圾回收器回收，因为找不到他的任何信息。

**让JVM误以为此对象还在引用中，无法回收，造成内存泄漏：**

**1、静态集合类**，如HashMap、LinkedList等等。如果这些容器为静态的，那么它们的生命周期与程序一致，则容器中的对象在程序结束之前将不能被释放，从而造成内存泄漏。简单而言，长生命周期的对象持有短生命周期对象的引用，尽管短生命周期的对象不再使用，但是因为长生命周期对象持有它的引用而导致不能被回收。

**2、各种连接**，如数据库连接、网络连接和IO连接等。在对数据库进行操作的过程中，首先需要建立与数据库的连接，当不再使用时，需要调用close方法来释放与数据库的连接。只有连接被关闭后，垃圾回收器才会回收对应的对象。否则，如果在访问数据库的过程中，对Connection、Statement或ResultSet不显性地关闭，将会造成大量的对象无法被回收，从而引起内存泄漏。

\*\*3、变量不合理的作用域。\*\*一般而言，一个变量的定义的作用范围大于其使用范围，很有可能会造成内存泄漏。另一方面，如果没有及时地把对象设置为null，很有可能导致内存泄漏的发生。

public class UsingRandom {
    
    　　private String msg;
    
    　　public void receiveMsg(){
    
    　　readFromNet();// 从网络中接受数据保存到msg中
    
    　　saveDB();// 把msg保存到数据库中
    
    　　}
    
    }

如上面这个伪代码，通过readFromNet方法把接受的消息保存在变量msg中，然后调用saveDB方法把msg的内容保存到数据库中，此时msg已经就没用了，由于msg的生命周期与对象的生命周期相同，此时msg还不能回收，因此造成了内存泄漏。

实际上这个msg变量可以放在receiveMsg方法内部，当方法使用完，那么msg的生命周期也就结束，此时就可以回收了。还有一种方法，在使用完msg后，把msg设置为null，这样垃圾回收器也会回收msg的内存空间。

\*\*4、内部类持有外部类，\*\*如果一个外部类的实例对象的方法返回了一个内部类的实例对象，这个内部类对象被长期引用了，即使那个外部类实例对象不再被使用，但由于内部类持有外部类的实例对象，这个外部类对象将不会被垃圾回收，这也会造成内存泄露。

\*\*5、改变哈希值，\*\*当一个对象被存储进HashSet集合中以后，就不能修改这个对象中的那些参与计算哈希值的字段了，否则，对象修改后的哈希值与最初存储进HashSet集合中时的哈希值就不同了，在这种情况下，即使在contains方法使用该对象的当前引用作为的参数去HashSet集合中检索对象，也将返回找不到对象的结果，这也会导致无法从HashSet集合中单独删除当前对象，造成内存泄露。

也可以总结为：

1.内存中加载的数据量过于庞大，如一次从数据库取出过多数据；  
2.集合类中有对对象的引用，使用完后未清空，使得JVM不能回收；  
3.代码中存在死循环或循环产生过多重复的对象实体；  
4.使用的第三方软件中的BUG；  
5.启动参数内存值设定的过小；

# 内存溢出的解决方案： #

**第一步，就是修改JVM启动参数，直接增加内存**。这一点看上去似乎很简单，但很容易被忽略。JVM默认可以使用的内存为64M，Tomcat默认可以使用的内存为128MB，对于稍复杂一点的系统就会不够用。在某项目中，就因为启动参数使用的默认值，经常报“OutOfMemory”错误。因此，-Xms，-Xmx参数一定不要忘记加。

\*\*第二步，检查错误日志，\*\*查看“OutOfMemory”错误前是否有其它异常或错误。\*\*在一个项目中，使用两个数据库连接，其中专用于发送短信的数据库连接使用DBCP连接池管理，用户为不将短信发出，有意将数据库连接用户名改错，使得日志中有许多数据库连接异常的日志，一段时间后，就出现“OutOfMemory”错误。经分析，这是由于DBCP连接池BUG引起的，数据库连接不上后，没有将连接释放，最终使得DBCP报“OutOfMemory”错误。经过修改正确数据库连接参数后，就没有再出现内存溢出的错误。

查看日志对于分析内存溢出是非常重要的，通过仔细查看日志，分析内存溢出前做过哪些操作，可以大致定位有问题的模块。

\*\*第三步，安排有经验的编程人员对代码进行走查和分析，找出可能发生内存溢出的位置。\*\*重点排查以下几点：

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

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

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

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

\*\*第四步，使用内存查看工具动态查看内存使用情况。\*\*某个项目上线后，每次系统启动两天后，就会出现内存溢出的错误。这种情况一般是代码中出现了缓慢的内存泄漏，用上面三个步骤解决不了，这就需要使用内存查看工具了。

内存查看工具有许多，比较有名的有：Optimizeit Profiler、JProbe Profiler、JinSight和Java1.5的**Jconsole**等。它们的基本工作原理大同小异，都是监测Java程序运行时所有对象的申请、释放等动作，将内存管理的所有信息进行统计、分析、可视化。开发人员可以根据这些信息判断程序是否有内存泄漏问题。一般来说，一个正常的系统在其启动完成后其内存的占用量是基本稳定的，而不应该是无限制的增长的。持续地观察系统运行时使用的内存的大小，可以看到在内存使用监控窗口中是基本规则的锯齿形的图线，如果内存的大小持续地增长，则说明系统存在内存泄漏问题。通过间隔一段时间取一次内存快照，然后对内存快照中对象的使用与引用等信息进行比对与分析，可以找出是哪个类的对象在泄漏。

# 如何查看内存溢出： #

1.在linux下首先找到tomcat的PID

步骤1：ps aux|grep tomcat\_1

步骤2：用jhat生成dump文件，文件后缀为hprof（dump文件后缀的用mat打不开）

jmap -dump:format=b,file=/opt/tomcat6666.hprof 15837

下载到windows下：

sz tomcat6666.hprof

步骤3：下载MAT

http://www.eclipse.org/mat/downloads.php

![img][]

不需要单独安装eclipse,解压后点击如图exe文件

![image-20201129004638032][]

![image-20201129004739064][]

打开刚才的文件tomcat6666.hprof

效果图如下：

![image-20201129004812488][]

备注：

linux下执行 jstack 15837 >zxm.txt

打开zxm.txt，

如下：

![image-20201129004842268][]  
**如果大家对java架构相关感兴趣，可以关注下面公众号，会持续更新java基础面试题, netty, spring boot,spring cloud等系列文章，一系列干货随时送达, 超神之路从此展开, BTAJ不再是梦想!**

![架构殿堂][20200415234301759.jpg]

[img]: /images/20221120/cb7ca7d2e64247469d17bffdc111b65a.png
[image-20201129004638032]: /images/20221120/4cf4fe8f7d664fb293d1a19d94560c6d.png
[image-20201129004739064]: /images/20221120/3d6a816c8acb4fdea222d2975469a66c.png
[image-20201129004812488]: /images/20221120/162e8b8b959e479485ee3918d1d8c213.png
[image-20201129004842268]: /images/20221120/6cee19aae30d424ab25f6ed7ce646ad0.png
[20200415234301759.jpg]: https://img-blog.csdnimg.cn/20200415234301759.jpg