文章目录

1
概念
2
分析内存溢出可能出现的地方
2
分析内存泄漏的原因

1 概念

内存泄漏： 分配出去的内存没有被回收回来，失去对内存区域的控制，造成资源的浪费，比如:new出来了对象并没有引用，垃圾回收器不会回收他，造成内存泄漏
内存溢出： 程序所需要的内存超出了系统所能分配的内存。

2 分析内存溢出可能出现的地方

从 Java代码的运行过程来看，有三个区域会发生 OOM，它们分别是：Metaspace、Java 虚拟机栈、堆内存。

Java栈

虚拟机栈，每执行一个方法都会有一个栈帧入栈，栈帧中包含参数、局部变量、返回值地址等信息。如果代码层次太深，不断有方法入栈却没有出栈，Java虚拟机栈就会OOM。

虚拟机中的栈内存也是有限的，我们调用方法的时候会创建一个栈帧，紧接着方法入栈。如果一个线程一直调用方法入栈，栈内存终归是要满的，此时线程的栈中就会发生 OOM。
发生这种情况一般就是代码除了问题，比如写了个递归调用，和 Metaspace 的内存溢出一样，也很少发生。
如果在单线程的情况下，无论是栈帧太大还是虚拟机栈容量太小，当内存无法再分配的时候，虚拟机抛出的是StackOverflowError异常。
如果在多线程下，不断地建立线程可能会产生OutOfMemoryError异常。

Metaspace

保存类的基本信息，如果加载太多类就会 OOM

永久代的垃圾收集主要回收两部分内容：废弃常量和无用的类。

回收废弃常量与回收 Java 堆中的对象非常类似。以常量池中字面量的回收为例，假如一个字符串"abc"已经进入了常量池中，但是当前系统没有任何一个 String 对象是叫做"abc"的，也没有其他地方引用了这个字面量，如果这时发生内存回收，而且必要的话，这个"abc"常量就会被系统清理出常量池。常量池中的其他类（接口）、方法、字段的符号引用也与此类似。

注意：在大量使用反射、动态代理、CGLib 等 ByteCode 框架、动态生成 JSP 以及 OSGi这类频繁自定义 ClassLoader 的场景都需要虚拟机具备类卸载的功能，以保证永久代不会溢出。

堆

堆中创建的对象过多就会触发GC，GC 的速度赶不上新建对象的速度也会发生 OOM。

高并发场景下，请求量太大，创建了大量新的对象，且这些都是有用的、存活的。堆中无法放入更多对象就会导致堆内存溢出
内存泄漏问题，长生命周期的对象引用了大量短生命周期的对象，没有及时取消对它们的引用，导致 GC 无法回收这些理应被回收的对象，就导致了堆内存溢出
Java堆中只会产生OutOfMemoryError异常。

注意：类需要同时满足下面 3 个条件才能算是“无用的类”

该类所有的实例都已经被回收，也就是 Java 堆中不存在该类的任何实例。
加载该类的 ClassLoader 已经被回收。
该类对应的 java.lang.Class 对象没有在任何地方被引用，无法在任何地方通过反射访问该类的方法。

虚拟机可以对满足上述3 个条件的无用类进行回收，这里说的仅仅是“可以”，而并不是和对象一样，不使用了就必然会回收。

注意：方法区溢出方法区中只会产生OutOfMemoryError异常。

2 分析内存泄漏的原因

原因：

长生命周期对象持有短生命周期对象的引用可能会引起内存泄漏

1、静态集合类：容器使用时引起的内存泄漏

HashMap、Vector等很容易出现内存泄漏，

集合被定义成静态的时候，由于它们的生命周期跟应用程序一样长

他们引用的所有对象Object不能被释放，如果将Object对象置为null，也还是会被Vector引用，可以将Vector对象置为null，切出对静态集合类的引用。

Vector vector = new Vector();
for (int i = 1; i<100; i++) {
	 Object object = new Object();
	 vector.add(object);
	 object = null;
}
//这样会造成内存泄漏
//...对vector的操作
//...与vector无关的其他操作这样会造成短暂的内存泄漏，method方法结束后被回收，
//...对vector的操作
vector = null;
//...与vector无关的其他操作

2、各种连接时：未正确使用close()方法导致的内存泄漏

各种IO或者数据库连接时，最后都需要close()释放对象，这样也是长对象引用短对象，造成的内存泄漏。

SessionFactory factory = new SessionFactory();
try {Session session = factory.connect();
} finally{
	 session.close();
}

这里必须用close关闭连接，因为SessionFactory是长对象，session是短对象。

3、外部模块的引用

调用外部模块的时候，也应该注意防止内存泄漏。如模块A调用了外部模块B的一个方法，如：public void register(Object o)。这个方法有可能就使得A模块持有传入对象的引用，这时候需要查看B模块是否提供了去除引用的方法，如unregister()

4、单例模式

使用单例模式的时候也有可能导致内存泄漏。因为单例对象初始化后将在JVM的整个生命周期内存在，如果它持有一个外部对象（生命周期比较短）的引用，那么这个外部对象就不能被回收，而导致内存泄漏。如果这个外部对象还持有其它对象的引用，那么内存泄漏会更严重

public class AppManager {
	 private static AppManager instance;
	 private Context context;
	 private AppManager(Context context) {
	 	this.context = context;
	 }
	 public static AppManager getInstance(Context context) {
		 if (instance != null) {
			 instance = new AppManager(context);
		 }
		 return instance;
	 }
}

这是一个普通的单例模式，当创建这个单例的时候，由于需要传入一个Context，所以这个Context的生命周期的长短至关重要：

如果此时传入的是 Application 的 Context，因为 Application 的生命周期就是整个应用的生命周期，所以这将没有任何问题。

如果此时传入的是 Activity 的 Context，当这个 Context 所对应的 Activity 退出时，由于该 Context 的引用被单例对象所持有，其生命周期等于整个应用程序的生命周期，所以当前 Activity 退出时它的内存并不会被回收，这就造成泄漏了。

正确的方式应该改为下面这种方式：

public class AppManager {
	 private static AppManager instance;
	 private Context context; 
	 private AppManager(Context context) { 
			 // 使用Application 的context 
			 this.context = context.getApplicationContext();
	 } 
	 public static AppManager getInstance(Context context) { 
		 if (instance != null) { 
		 		instance = new AppManager(context); 
		 } 
		 return instance; 
	 } 
}

或者这样写，连 Context 都不用传进来了：在你的 Application 中添加一个静态方法，getContext() 返回 Application 的 context，

... 
context = getApplicationContext(); 
...
 //获取全局的context - - >return返回全局context对象
 public static Context getContext(){
	 return context;
 }
 
 public classAppManager{
	  private static AppManager instance;
	  private Context context;
	  private AppManager() {
			  // 使用Application 的context
			  this.context = MyApplication.getContext();
	  }
	  public static AppManager getInstance() {
			  if (instance != null) {
				  instance = new AppManager();
			  }
			  return instance;
	  }
 }

如何解决以及监控JVM内存、CPU的情况，请关注下篇文章。。。

Java技术债务

JVM内存泄漏和内存溢出的原因 - Java技术债务