【搞定JVM】第二章 Java内存区域和溢出异常

目录

转载:https://blog.csdn.net/pcwl1206/article/details/83990008

一、走进Java

1、Java技术体系

3、Java虚拟机发展史:Sun和BEA被Oracle收购

HotSpot VM [Sun]

4、 Java的优点

5、 编译器与解释器的区别

6、内存泄漏和内存溢出

二、Java内存区域和溢出异常

1、 运行时数据区域【方法区和堆是属于线程共享区,而Java虚拟机栈、本地方法栈和程序计数器是线程独占区】

1.1 程序计数器【记录正在执行的虚拟机字节码指令的地址(如果正在执行的是本地方法则为空)】。

1.2 Java 虚拟机栈【描述的是Java方法执行的内存模型(maybe过程抽象):每个方法在执行的同时都会创建一个帧栈(Stack Frame)用于存储局部变量表、操作数栈、动态链接、方法出口等信息。每一个方法从调用直至执行完成的过程,就对应着一个栈帧在虚拟机栈中入栈到出栈的过程。它的线程也是私有的,生命周期与线程相同。】

1.3 本地方法栈【类似Java 虚拟机栈,虚拟机栈为虚拟机执行Java方法(也就是字节码)服务,而本地方法栈则为虚拟机使用到的Native方法服务】

1.4 堆:存放对象实例,几乎所有的对象实例都在这里分配内存,是垃圾收集的主要区域(“GC 堆”)(在虚拟机启动时创建)。

1.5 方法区【用于存放已被虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码等数据。】

1.6 直接内存【并不是虚拟机运行时数据区的一部分,也不是Java虚拟机规范中定义的内存区域。但是这部分内存也频繁地使用,而且也可能导致OutOfMemoryError异常。将其放到这里一起进行讲解。】

2、HotSpot虚拟机对象探秘

2.1 对象的创建(new的过程)

2.2  对象的内存布局【在HotSpot虚拟机中,对象在内存中存储的布局可以分为3块区域:对象头、实例数据和对齐填充。】

2.3  对象的访问定位【句柄和直接指针两种。而HotSpot使用的是直接指针进行对象访问的。】

3、实战:OutOfMemoryError异常

3.1  Java堆溢出

3.2  虚拟机栈和本地方法栈溢出

3.3  方法区和运行时常量池溢出

3.4  本机直接内存溢出

4 总结


转载:https://blog.csdn.net/pcwl1206/article/details/83990008

一、走进Java

1、Java技术体系

1.1 Java技术体系:

  • 按功能划分:

    • Java程序设计语言
    • Java虚拟机
    • Java API类库
    • Class文件格式 (可用不同的编译器把代码编译成字节码文件)
    • 第三方的Java类库
  • 按服务领域划分:

    • Java Card:支持Java小程序(Applets)运行在小内存设备上的平台
    • Java ME: 支持Java程序运行在移动终端上的平台
    • Java SE(standard edition): 支持面向桌面级应用的Java平台,提供完整的Java核心API
    • Java EE(enterprise edition):支持使用多层架构的企业应用的Java平台,除了提供Java SE API 外,还对其做了大量的扩充

1.2 JDK(Java Development Kit): (支持java程序开发的最小环境)

  • Java程序设计语言
  • Java虚拟机
  • Java API类库

1.3 JRE(Java Runtime Environment):(支持Java程序运行的标准环境)

  • Java SE API子集
  • Java虚拟机

3、Java虚拟机发展史:Sun和BEA被Oracle收购

HotSpot VM [Sun]

  • HotSpot VM的热点代码探测能力可以通过执行计数器找出最具有编译价值的代码,然后通知JIT编译器以方法为单位进行编译。
  • 如果一个方法被频繁调用,或方法中有效循环次数很多,将会分别触发标准编译和OSR(栈上替换)编译动作。
  • 通过编译器与解释器恰当的协同工作,可以在最优化的程序响应时间与最佳执行性能中取得平衡,而且无需等待本地代码输出才能执行程序,即时编译的压力也相对减小,有助于引入更多的代码优化技术,输出质量更高的本地代码。

4、 Java的优点

  • 1)摆脱了硬件平台的束缚,实现了“一次编写,到处运行”;
  • 2)提供了一个相对安全的内存管理和访问机制,避免了绝大部分的内存泄漏和指针越界问题;
  • 3)实现了热点代码检测和运行时编译及优化,使得Java应用能随着运行时间的增加而获得更高的性能;
  • 4)拥有一套完善的应用程序接口,还有无数第三方类库来帮助它实现各种各样的功能。

5、 编译器与解释器的区别

  • 编译器:把源程序的每一条语句都编译成机器语言,并保存为二进制文件,这样运行时计算机就可以直接以机器语言来运行此程序,速度很快;
  • 解释器:只在执行程序时,才一条一条的解释成机器语言给计算机执行,所以运行速度没有编译后的程序运行的快。

6、内存泄漏和内存溢出

内存溢出:是指程序在申请内存时,没有足够的空间供其使用,出现OutOfMemery(OOM)

内存泄露:是指因疏忽或错误造成程序未能释放已经不在使用的内存的情况

二、Java内存区域和溢出异常

1、 运行时数据区域【方法区和堆是属于线程共享区,而Java虚拟机栈、本地方法栈和程序计数器是线程独占区】

Java虚拟机在执行Java程序的过程中会把它所管理的内存划分为若干个不同的数据区域。这些区域都有各自的用途,以及创建和销毁时间,有的区域随着虚拟机进程的启动而存在,有些区域则依赖用户线程的启动和结束而建立和销毁。Java虚拟机运行时数据区如下图所示:
在这里插入图片描述

  • Java虚拟机栈内存结构中的程序计数器、虚拟机栈和本地方法栈这三个区域随线程创建而生,随线程销毁而死,因此这三个区域的内存分配和回收是确定的,Java垃圾收集器重点关注的是Java虚拟机的堆内存和方法区内存。

1.1 程序计数器【记录正在执行的虚拟机字节码指令的地址(如果正在执行的是本地方法则为空)】。

  • 字节码解释器工作时就是通过改变这个计数器的值来选取下一条需要执行的字节码指令。程序的分支、循环、跳转、异常处理、线程恢复等基础功能都需要依赖这个计数器来完成。

  • 由于Java虚拟机的多线程是通过线程轮流切换并分配处理器执行时间的方式来实现的,在任何一个确定的时刻,一个处理器都只会执行一条线程中的命令。因此,为了线程切换后能恢复到正确的执行位置,每条线程都需要有一个独立的程序计数器,各线程之间的计数器互不影响,独立存储,我们程这块内存区域为“线程私有”的内存。

  • 此区域是唯一 一个虚拟机规范中没有规定任何OutOfMemoryError情况的区域。

1.2 Java 虚拟机栈【描述的是Java方法执行的内存模型(maybe过程抽象):每个方法在执行的同时都会创建一个帧栈(Stack Frame)用于存储局部变量表、操作数栈、动态链接、方法出口等信息。每一个方法从调用直至执行完成的过程,就对应着一个栈帧在虚拟机栈中入栈到出栈的过程。它的线程也是私有的,生命周期与线程相同。】

在这里插入图片描述

  • 局部变量表存放了编译期可知的各种基本数据类型(boolean、byte、char、short、int、float、long、double)、对象引用和returnAddress类型(指向了一条字节码指令的地址)。

  • Java虚拟机栈的局部变量表的空间单位是槽(Slot),其中64位长度的double和long类型会占用两个Slot。局部变量表所需内存空间在编译期完成分配,当进入一个方法时,该方法需要在帧中分配多大的局部变量是完全确定的,在方法运行期间不会改变局部变量表的大小。

  • 可以通过 -Xss 这个虚拟机参数来指定每个线程的 Java 虚拟机栈内存大小:

java -Xss512M HackTheJava
  •  
  • 该区域可能抛出以下异常:

    • 当线程请求的栈深度超过最大值,会抛出 StackOverflowError 异常;
    • 栈进行动态扩展时如果无法申请到足够内存,会抛出 OutOfMemoryError 异常。

1.3 本地方法栈【类似Java 虚拟机栈,虚拟机栈为虚拟机执行Java方法(也就是字节码)服务,而本地方法栈则为虚拟机使用到的Native方法服务】

  • 与Java虚拟机栈一样,本地方法栈也会抛出StackOverflowError和OutOfMemoryError异常。

    本地方法一般是用其它语言(C、C++ 或汇编语言等)编写的,并且被编译为基于本机硬件和操作系统的程序,对待这些方法需要特别处理。

在这里插入图片描述

1.4 堆:存放对象实例,几乎所有的对象实例都在这里分配内存,是垃圾收集的主要区域(“GC 堆”)(在虚拟机启动时创建)。

Java堆是垃圾收集器管理的主要区域,因此很多时候也被称做“GC”堆(Garbage Collected Heap)。

  • 从内存回收的角度看,由于现在收集器基本都采用分代收集算法,所以Java堆中还可以细分为:新生代和老年代。
  • 从内存分配角度来看,线程共享的Java堆中可能划分出多个线程私有的分配缓冲区(Thread Local Allocation Buffer, TLAB)。
  • 不过无论如何划分,都与存放的内容无关,无论哪个区域,存储的都仍然是对象实例,进一步划分的目的是为了更好地回收内存,或者更快地分配内存。

Java虚拟机规定,Java堆可以处于物理上不连续的内存空间中,只要逻辑上是连续的即可。在实现时,可以是固定大小的,也可以是可扩展的。如果在堆中没有完成实例分配。并且堆也无法扩展时,将会抛出OutOfMemoryError异常。

可以通过 -Xms 和 -Xmx 两个虚拟机参数来指定一个程序的堆内存大小,第一个参数设置初始值,第二个参数设置最大值。

java -Xms1M -Xmx2M HackTheJava
  •  

1.5 方法区【用于存放已被虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码等数据。】

  • Java虚拟机规范对方法区的限制非常宽松,除了和Java堆一样不需要连续的内存和可以选择固定大小或者可扩展外,还可以选择不实现垃圾收集。这个区域的内存回收目标主要是针对常量池的回收和对类型的卸载。

    • 运行时常量池(Runtime Constant Pool):是方法区的一部分。
      • 用于存放编译期生成的各种字面量和符号引用,这部分内容将在类加载后进入方法区的运行时常量池中存放。
      • 除了在编译期生成的常量,还允许动态生成,例如 String 类的 intern()
      • String的intern
  • 根据Java虚拟机规范规定,当方法区无法满足内存分配需求时,将抛出OutOfMemoryError异常。

  • HotSpot 虚拟机把它当成永久代来进行垃圾回收。但是很难确定永久代的大小,因为它受到很多因素影响,并且每次 Full GC 之后永久代的大小都会改变,所以经常会抛出 OutOfMemoryError 异常。为了更容易管理方法区,从 JDK 1.8 开始,移除永久代,并把方法区移至元空间,它位于本地内存中,而不是虚拟机内存中。

1.6 直接内存【并不是虚拟机运行时数据区的一部分,也不是Java虚拟机规范中定义的内存区域。但是这部分内存也频繁地使用,而且也可能导致OutOfMemoryError异常。将其放到这里一起进行讲解。】

  • 在JDK1.4中新加入了NIO(New Input/Output)类,引入了一种基于通道(Channel)与缓冲区(Buffer)的I/O方式,它可以使用Native函数库直接分配堆外内存,然后通过一个存储在Java堆中的DirectByteBuffer对象作为这块内存的引用进行操作

  • 这样能在一些场景中显著提高性能,因为避免了在 Java 堆和 Native 堆中来回复制数据。

  • 本地直接内存的分配不会受到Java堆大小的限制,但是,既然是内存,肯定还是会受到本机总内存大小以及处理器寻址空间的限制。如果各个内存区域总和大于物理内存限制,从而导致动态扩展时出现OutOfMemoryError异常。

2、HotSpot虚拟机对象探秘

如果我们想了解虚拟机是如何创建、如何布局以及如何访问的,对于这些细节的问题,就必须把讨论范围限定到具体的虚拟机和集中在某一内存区域上才有意义。基于实用优先原则,下面用HotSpot虚拟机和Java堆内存作为例。

2.1 对象的创建(new的过程)

在Java语言中,我们常用new关键字去创建对象,这个创建过程大概包括以下部分:

 (1)虚拟机遇到一条new指令时,首先将去检查这个指令的参数是否能在常量池中定位到一个类的符号引用,并检查这个符号引用代表的类是否已经被加载、解析和初始化过。如果没有,那必须先执行相应的类加载过程;

(2)在类加载检查通过后,接下来虚拟机将为新生对象分配内存。对象所需的内存的大小在类加载完成后便可完全确定;

(3)内存分配完成后,虚拟机需要将分配到的内存空间都初始化为零值(不包括对象头);

(4)接下来,虚拟机要对对象进行必要的设置,例如这个对象是哪个类的实例、如何才能找到类的元数据信息、对象的哈希码、对象的GC分代年龄等信息。这些信息存放在对象的对象头中。

在上面的工作都完成之后,从虚拟机的视角来看,一个新的对象就已经产生了,但是从Java程序来看,对象的创建才刚刚开始,<init>方法还没有执行,所有的字段都还为零。

2.2  对象的内存布局【在HotSpot虚拟机中,对象在内存中存储的布局可以分为3块区域:对象头、实例数据和对齐填充。】


在HotSpot虚拟机中,对象在内存中存储的布局可以分为3块区域:对象头(Header)、实例数据(Instance  Data)和对齐填充(Padding)。

(1)对象头:包括两部分信息,第一部分用于存储自身的运行时数据,如哈希码、GC分代年龄、锁状态标志等等;第二部分是类型指针,即对象指向它的类元数据的指针,虚拟机通过这个指针来确定这个对象是哪个类的实例。

(2)实例数据:是对象真正存储的有效信息,也是在程序代码中所定义的各种类型的字段内容。无论是父类继承下来的,还在在子类中定义的,都需要记录下来。

(3)对其填充:并不是必然存在的,也没有特殊的含义,它仅仅起着占位符的作用。HotSpot要求对象的大小必须是8字节的整数倍。而对象头部分正好是8字节的倍数(1倍或者2倍),因此,当对象实例数据部分没有对齐的时候,就需要通过对其补充来补全。

2.3  对象的访问定位【句柄和直接指针两种。而HotSpot使用的是直接指针进行对象访问的。】


          建立对象就是为了使用对象,我们的Java程序需要通过栈上的reference数据来操作栈上的具体对象。由于reference类型在Java虚拟机规范中只规定了一个指向对象的引用,并没有定义这个引用应该通过何种方式去定位、访问堆中的具体位置,所以对象的访问方式也取决于虚拟机实现而定。

目前主流的访问方式有:句柄和直接指针两种。而HotSpot使用的是直接指针进行对象访问的。

句柄:最大好处就是reference中存储的是稳定的句柄地址,再对象被移动时(垃圾收集移动对象是非常普遍的行为)只会改变句柄中的实例数据指针,而reference本身不需要被修改【在Java堆中划出一块内存来作为句柄池,句柄中包含了对象实例数据和类型数据各自的具体地址信息】

直接指针:最大好处就是速度更快,它节省了一次指针定位的开销【reference中存储的直接就是对象地址,对象里面包含了指向到对象类型数据的指针】

 

3、实战:OutOfMemoryError异常

3.1  Java堆溢出


          Java堆用于存储对象实例,只要不断地创建对象,并且保证GC Roots到对象之间有可达路径来避免垃圾回收机制清除这些对象,那么在对象数量到达最大堆的容量限制后就会产生内存溢出异常。

如下代码中:限制Java堆的大小为20MB,不可扩展(将堆的最小值-Xms参数与最大值-Xmx参数设置为一样即可避免堆自动扩展),通过参数-XX:+HeapDumpOnOutOfMemoryError可以让虚拟机在出现内存异常时Dump出当前的内存堆转储快照以便事后进行分析。

/**
 * 测试:堆溢出
 * VM Args:  -Xms20m -Xmx20m -XX:+HeapDumpOnOutOfMemoryError
 */
public class HeapOOM {
    
    static class OOMObject{
        
    }
    
    public static void main(String[] args){
        List<OOMObject> list = new ArrayList<OOMObject>();
        
        while(true){
            list.add(new OOMObject());
        }
    }
}

在Run as --> Run  configurations --> Java Application --> Arguments --> VM arguments中设置虚拟机启动参数,运行结果如下:

可以通过dump出来的文件分析是出现了内存泄漏(Memory Leak)还是内存溢出(Memory  Overflow)。具体分析过程后面章节会具体讲到。

可以通过dump出来的文件分析是出现了内存泄漏(Memory Leak)还是内存溢出(Memory  Overflow)。具体分析过程后面章节会具体讲到。

3.2  虚拟机栈和本地方法栈溢出


            由于在HotSpot虚拟机中并不区分虚拟机栈和本地方法栈,因此,对于HotSpot来说,虽然-Xoss参数(设置本地方法和栈大小)存在,但实际上是无效的,栈容量只由-Xss参数设定。

关于虚拟机栈和本地方法栈,在Java虚拟机规范中描述了两种异常:

(1)如果线程请求的栈深度大于虚拟机所允许的最大深度,将抛出StackOverflowError异常;

(2)如果虚拟机在扩展栈时无法申请到足够的内存空间,则抛出OutOfMemoryError异常。

3.2.1  如果线程请求的栈深度大于虚拟机所允许的最大深度,将抛出StackOverflowError异常

单线程的环境下,无论由于栈帧过大还是虚拟机栈容量太小,当内存无法分配的时候,虚拟机则抛出的都是StackOverflowError异常。


/**
 * 虚拟机栈和本地方法栈OOM测试
 * VM Args: -Xss128k  设置栈容量为128k
 */
public class JavaVMStackSOF {
 
	private int stackLength = 1;
	
	public void stackLeak(){
		stackLength++;
		stackLeak();   // 递归
	}
	
	public static void main(String[] args) {
		JavaVMStackSOF oom = new JavaVMStackSOF();
		try{
			oom.stackLeak();
		}catch(Throwable e){
			System.out.println("stack length:" + oom.stackLength);
			throw e;
		}
	}
}

运行结果

3.3.2  如果虚拟机在扩展栈时无法申请到足够的内存空间,则抛出OutOfMemoryError异常

操作系统分配给每个进程的内存是有限制的,比如32为Windows为2GB。所以创建线程能用的剩下内存 = 2GB(操作系统限制) - 最大堆容量(Xmx)- 最大方法区容量(MaxPermSize)- 程序计数器消耗的内存(很小,可忽略)。在Java虚拟机栈内存一定的情况下,每个线程分配到的栈容量越大,可以建立的线程数目就越少,建立线程时就越容易把剩下的内存耗尽。导致无法申请到足够的栈空间,抛出OutOfMemoryError异常

/**
 * 创建线程导致内存溢出异常
 * VM Args: -Xss2M   设置栈容量为2M
 */
public class JavaVMStackOOM {
 
	private void dontStop(){
		while(true){
		}
	}
	
	public void stackLeakByThread(){
		// 一直循环创建线程,直到内存溢出
		while(true){
			Thread thread = new Thread(new Runnable(){
				
				@Override
				public void run(){
					dontStop();
				}
			});
			thread.start();
		}
	}
	
	public static void main(String[] args) {
		JavaVMStackOOM oom = new JavaVMStackOOM();
		oom.stackLeakByThread();
	}

}

由于运行该程序可能会出现操作系统假死,所以这里就不再运行了,贴上书上的运行结果:

3.3  方法区和运行时常量池溢出


           运行时常量池属于方法区的一部分,可以使用-XX:PermSize和-XX:MaxPermSize限制方法区的大小【注意:仅限JDK1.6及之前的版本,因为JDK1.7中开始逐步“去永久代”】。

String.intern()是一个Native方法,它的作用是:如果字符串常量池中已经包含了一个等于此String对象的字符串,则返回代表池中这个字符串的String对象;否则,将此String对象包含的字符串添加到常量池中,并且返回String对象的引用。


/**
 * 运行时常量池导致的内存溢出异常
 * -XX:PermSize=10M -XX:MaxPermSize=10M
 */
public class RuntimeConstantPoolOOM {
 
	public static void main(String[] args) {
		// 使用List保持着常量池引用,避免Full GC回收常量池的行为
		List<String> list = new ArrayList<String>();
		
		// 10MB的PermSize在Integer范围内足够产生OOM了。
		int  i = 0;
		while(true){
			list.add(String.valueOf(i++).intern());
		}
	} 
}

需要在JDK1.6及以下版本运行中才会出现运行时常量溢出,在OutOfMemoryError后面紧跟的提示信息是”PermGen  space“,说明运行时常量池属于方法区。

再看下面这段代码,在JDK1.6和JDK1.7中运行会得出不同的结果:

/**
 * JDK1.6和JDK1.7中的字符串常量池问题
 * JDK1.6运行结果:两个false
 * JDK1.7运行结果:一个ture,一个false
 */
public class RuntimeConstantPoolOOM_Demo {
	
	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);  //java这个字符串常量是固定存在于字符串常量池中的关键字()
	}
}

           JDK1.6运行结果:两个false,JDK1.7运行结果:一个ture,一个false。产生差异的原因是:在JDK1.6中,intern()方法会把首次遇到的字符串实例复制到永久代中,返回的也是永久代中这个字符串实例的引用,而由StringBuilder创建的字符串实例在Java堆上,所以必然不是同一个引用,将返回false。而JDK1.7的intern()实现不会复制实例,只是在常量池中记录首次出现的实例引用,因此intern()返回的引用和由StringBuilder创建的那个字符串实例是同一个。

对于str2比较返回false是因为“java”这个字符串在执行StringBuilder之前已经出现过,字符串常量池已经有它的引用了[所以指向的是常量池中的],不符合“首次出现”的原则,而“计算机软件”这个字符串则是首次出现的【指向的是堆上的】,因此返回true。

方法区用于存放Class的相关信息,如类名、访问修饰符、常量池、字段描述、方法描述等。对于这些区域的测试,基本的思路是运行时产生大量的类去填满方法区,直到溢出。下面的例子中借助CGLIB动态代理直接操作字节码运行时生成了大量的动态类。增强的类越多,就需要越大的方法区来保证动态生成的Class可以载入内存。


/**
 * 借助CGLIB使方法区出现内存溢出异常
 * VM Args: -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(){
				public Object intercept(Object obj, Method method, Object[] args, MethodProxy proxy) throws Throwable{
					return proxy.invokeSuper(obj, args);
				}
			});
			enhancer.create();
		}
	}
	
	static class OOMObject{
		
	}
}

 

3.4  本机直接内存溢出


        Java虚拟机可以通过参数-XX:MaxDirectMemorySize指定,如果不指定,则默认与Java堆最大值(-Xmx一样)。JDK中可以通过反射获取Unsafe类(Unsafe类的getUnsafe()方法只有启动类加载器Bootstrap才能返回实例)直接操作本机直接内存。

/**
 * 使用unsafe分配本机内存
 * VM Area:-Xmx20M -XX:MaxDirectMemorySize=10M
 */
public class DirectMemoryOOM {
 
	private static final int _1MB = 1024 * 1024;
	
	public static void main(String[] args) {
		Field unsafeFiled = Unsafe.class.getDeclaredField()[0];
		unsafeFiled.setAccessible(true);
		Unsafe unsafe = unsafeFiled.get(null);
		while(true){
			unsafe.allocateMemory(_1MB);
		}
	}
}

4 总结


本章主要讲解了Java虚拟机内存是如何划分的,哪部分区域、什么样的代码和操作可能导致内存溢出异常。虽然Java有垃圾收集机制,但内存溢出异常离我们并不遥远,本章只是讲解了各个区域出现内存溢出异常的原因,下一章详细讲解Java垃圾收集机制为了避免内存溢出异常而做了哪些努力。

猜你喜欢

转载自blog.csdn.net/ZHAOJING1234567/article/details/89215482