场景
1.Java堆溢出
Java堆用于存储对象实例,只要不断创建对象,并且保证GC Roots到对象之间有可达路径(对象被引用)来避免垃圾回收机制清除对象,那么在对象数量达到最大堆容量后就会产生内存溢出异常。
Java 堆溢出原因
- 无法在 Java 堆中分配对象
- 应用程序保存了无法被GC回收的对象。
- 应用程序过度使用 finalizer。
Java 堆溢出排查解决思路
- 查找关键报错信息,如
java.lang.OutOfMemoryError: Java heap space
- 使用内存映像分析工具(如Eclipsc Memory Analyzer或者Jprofiler)对Dump出来的堆储存快照进行分析,分析清楚是内存泄漏还是内存溢出。
- 如果是内存泄漏,可进一步通过工具查看泄漏对象到GC Roots的引用链,修复应用程序中的内存泄漏。
- 如果不存在泄漏,先检查代码是否有死循环,递归等,再考虑用 -Xmx 增加堆大小。
举个栗子:
public class HeapOOM
{
static class OOMObject{
}
public static void main(String[] args)
{
List<OOMObject> list = new ArrayList<OOMObject>();
while(true)
{
list.add(new OOMObject());
}
}
}
结果:
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
堆溢出排查解决思路
- 检查虚拟机堆内存参数(-Xms,-Xmx);0
- 代码上检查是否存在某些对象的生命周期过长,持有状态时间过长,减少程序运行期间内存消耗;
2.虚拟机栈和本地方法栈溢出
HotSpot虚拟机不区分虚拟机栈和本地方法栈。
Java虚拟机规范中描述了两种异常:
- 如果线程请求的栈深度大于虚拟机所允许的最大深度,抛出StackOverflowError异常。
- 如果虚拟机在扩展栈时无法申请到足够的内存空间,抛出OutOfMemoryError异常。
当栈空间无法继续分配时,到底是内存太小,还是已使用的栈空间太大?其本质上是对同一件事物的两种描述。
在单线程情况下,无论是栈帧太大还是虚拟机容量太小,当内存无法分配时,虚拟机都是抛出StackOverflowError异常。
如果使用多线程,通过不断建立线程的方式可以产生内存溢出异常,但是这与栈空间是否足够大没有关系,每个线程的栈分配到的内存越大,可建立的线程数就少,建立线程时更容易把剩下的内存耗尽。 当过多线程导致内存溢出,在不减少线程数或更换64位虚拟机的情况下,只能通过减少最大堆和减少栈容量来换取更多线程。
栈溢出原因
- 在单个线程下,栈帧太大,或者虚拟机栈容量太小,当内存无法分配的时候,虚拟机抛出StackOverflowError 异常。
- 不断地建立线程的方式会导致内存溢出。
栈溢出排查解决思路
- 查找关键报错信息,确定是StackOverflowError还是OutOfMemoryError
- 如果是StackOverflowError,检查代码是否递归调用方法等
- 如果是OutOfMemoryError,检查是否有死循环创建线程等,通过-Xss降低的每个线程栈大小的容量
/**
* -Xss2M
*/
public class JavaVMStackOOM {
private void dontStop(){
while(true){
}
}
public void stackLeakByThread(){
while(true){
Thread thread = new Thread(new Runnable(){
public void run() {
dontStop();
}
});
thread.start();}
}
public static void main(String[] args) {
JavaVMStackOOM oom = new JavaVMStackOOM();
oom.stackLeakByThread();
}
}
3.方法区和运行时常量池溢出
方法区,(又叫永久代,JDK8后,元空间替换了永久代),用于存放Class的相关信息,如类名、访问修饰符、常量池、字段描述、方法描述等。运行时产生大量的类,会填满方法区,造成溢出。
方法区溢出原因
- 使用CGLib生成了大量的代理类,导致方法区被撑爆
- 在Java7之前,频繁的错误使用String.intern方法
- 大量jsp和动态产生jsp
- 应用长时间运行,没有重启
方法区溢出排查解决思路
- 检查是否永久代空间设置得过小
- 检查代码是否频繁错误得使用String.intern方法
- 检查是否跟jsp有关。
- 检查是否使用CGLib生成了大量的代理类
- 重启大法,重启JVM
运行时常量池溢出
String.intern() 是一个native方法,他的作用是:如果字符串常量池中已经包含一个等于此String对象的字符串,则返回代表池中这个字符串的String对象;否则,将此String对象包含的字符串添加到常量池中,并且返回此Sring对象的引用。在JDK1.6之前的版本中,由于常量池分配在永久代内,我们可以通过-XX:PermSize和-XX:MaxPermSize限制方法区大小,从而间接限制其中常量池的容量:如下面代码所示
/**
* VM Args -XX:PermSize=10M -XX:MaxPermSize=10M
*/
public class RuntimeConstantPoolOOM {
public static void main(String[] args) {
List<String> list = new ArrayList<String>();
int i = 0;
while(true){
System.out.println(i);
list.add(String.valueOf(i++).intern());
}
}
}
运行结果
Exception in thread "main" java.lang.OutOfMemoryError: PermGen space
从运行结果可以看到,运行时常量池溢出,在OutOfMenoryError后面跟随的提示信息是PermGen space,说明运行时常量池属于方法区的一部分。
在使用JDK7 就不会有上述的结果,while循环会一直进行下去。关于这,通过下面的代码,会遇到一个很奇怪的现象。
public class RuntimeConstantPoolOOM {
public static void main(String[] args) {
String str1 = new StringBuilder("计算机").append("软件").toString();
System.out.println(str1.intern() == str1);
String str2 = new StringBuilder("ja").append("va").toString();
System.out.println(str2.intern() == str2);
}
}
这段代码在JDK1.6 之前运行,会得到两个false,但是如果在JDK1.7中运行,会得到一个true和一个false。产生差异的原因是,在JDK1.6中,intern()方法会把首次遇到 的字符串实例复制到永久带中,返回的也是永久带中这个字符串实例的引用,而由StringBuilder创建的字符串实例在Java堆上,所以必然不是同一个引用,返回false。而JDK1.7(以及部分其他虚拟机)的intern()实现不会再复制实例,只是在常量池中记录首次出现的实例引用。因此intern()返回的引用和由StringBuilder创建的那个字符串实例是同一个。对str2比较返回false是因为java这个字符串在执行StringBuilder.toSting() 之前已经出现过,字符串常量池中已经有它的引用了,不符合首次出现的原则。
方法区溢出
方法区用于存放Class的相关信息,如类名,访问修饰符,常量池,字段描述,方法描述等。对于方法区的移除,可以构造大量的类去填充,直到溢出。使用CGLib来做一个尝试。
/**
* -XX:PermSize=10M -XX:MaxPermSize=10M
*/
public class JavaMethodAreaOOM {
public static void main(String[] args) {
while (true){
Enhancer enhancer = new Enhancer();
enhancer.setSuperclass(OOMObject.class);
enhancer.setUseCache(false);
enhancer.setCallback(new MethodInterceptor() {
@Override
public Object intercept(Object o, Method method, Object[] objects, MethodProxy methodProxy) throws Throwable {
return methodProxy.invokeSuper(o, args);
}
});
enhancer.create();
}
}
static class OOMObject{
}
}
在JDK1.7中,会出现如下的异常
Caused by: java.lang.OutOfMemoryError: PermGen space
而在JDK1.8中,因为取消了永久带,所以-XX:PermSize=10M -XX:MaxPermSize=10M参数都无效了,而对于存放类的元数据的内存大小的设置变为Metaspace参数,可以通过参数-XX:MetaspaceSize 和-XX:MaxMetaspaceSize设定大小
运行上述的代码。会出现如下异常:
Caused by: java.lang.OutOfMemoryError: Metaspace
4.本机直接内存溢出
直接内存并不是虚拟机运行时数据区的一部分,也不是Java 虚拟机规范中定义的内存区域。但是,这部分内存也被频繁地使用,而且也可能导致OOM。
在JDK1.4 中新加入了NIO(New Input/Output)类,它可以使用 native 函数库直接分配堆外内存,然后通过一个存储在Java堆中的 DirectByteBuffer 对象作为这块内存的引用进行操作。这样能在一些场景中显著提高性能,因为避免了在 Java 堆和 Native 堆中来回复制数据。
直接内存溢出原因
- 本机直接内存的分配虽然不会受到Java 堆大小的限制,但是受到本机总内存大小限制。
- 直接内存由 -XX:MaxDirectMemorySize 指定,如果不指定,则默认与Java堆最大值(-Xmx指定)一样。
- NIO程序中,使用ByteBuffer.allocteDirect(capability)分配的是直接内存,可能导致直接内存溢出。
直接内存溢出
- 检查代码是否恰当
- 检查JVM参数-Xmx,-XX:MaxDirectMemorySize 是否合理。
DirectMemory容量可以通过 -XX:MaxdirectMemorySize 指定,如果不指定,则默认与Java堆最大值(-Xmx指定)一样。下面代码越过了DirectByteBuffer类,直接通过反射获取unfase实例进行内存分配(unsafe类的getUnsafe()方法限制了只有rt.jar中的类才能使使用Unsafe的功能)。因为,虽然使用DirectByteBuffer分配内存也会抛出内存溢出异常,但他抛出异常时并没有真正向操作系统申请分配内存,而是通过计算得知内存无法分配,于是手动抛出异常,真正申请分配内存的方法时unsafe.allocateMemory()
/**
* -Xmx20M -XX:MaxDirectMemorySize=10M
*/
public class DirectMenoryOOM {
private static final int _1MB = 1024 * 1024;
public static void main(String[] args) throws IllegalAccessException {
Field unsafeField = Unsafe.class.getDeclaredFields()[0];
unsafeField.setAccessible(true);
Unsafe unsafe = (Unsafe) unsafeField.get(null);
while (true){
unsafe.allocateMemory(_1MB);
}
}
}
返回结果
Exception in thread "main" java.lang.OutOfMemoryError:
由DirectMemory导致的内存溢出,一个明显的特征是在heap Dump文件中不会看见明显的异常,如果读者发现OOM之后的Dump文件很小,而程序中又直接或间接使用了NIO,那就可以考虑一下这方面的原因。
参考文章
Java程序员必备:常见OOM异常分析
深入了解JVM虚拟机