您的位置:首页 > 编程语言 > Java开发

深入理解JVM笔记一-java内存区域与内存溢出异常

2017-01-16 23:02 701 查看
title: 深入理解JVM笔记一-java内存区域与内存溢出异常

date: 2016-10-18 15:03:57

categories: JVM

tags: JVM

自动内存管理机制

java内存区域与内存溢出异常

1.java虚拟机运行时数据区



程序计数器(Program Counter Register)

它是一块较小的内存空间,它的作用可以看做是当先线程所执行的字节码的信号指示器。

每一条JVM线程都有自己的PC寄存器,各条线程之间互不影响,独立存储,这类内存区域被称为“线程私有”内存

在任意时刻,一条JVM线程只会执行一个方法的代码。该方法称为该线程的当前方法(Current Method)

如果该方法是java方法,那PC寄存器保存JVM正在执行的字节码指令的地址

如果该方法是native,那PC寄存器的值是undefined。

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

Java虚拟机栈(Java Virtual Machine Stack)

与PC寄存器一样,Java虚拟机栈也是线程私有的。每一个JVM线程都有自己的java虚拟机栈,这个栈与线程同时创建,它的生命周期与线程相同。

虚拟机栈描述的是Java方法执行的内存模型:每个方法被执行的时候都会同时创建一个栈帧(Stack Frame)用于存储局部变量表、操作数栈、动态链接、方法出口等信息。每一个方法被调用直至执行完成的过程就对应着一个栈帧在虚拟机栈中从入栈到出栈的过程。

JVM stack 可以被实现成固定大小,也可以根据计算动态扩展。

如果采用固定大小的JVM stack设计,那么每一条线程的JVM Stack容量应该在线程创建时独立地选定。JVM实现应该提供调节JVM Stack初始容量的手段;如果采用动态扩展和收缩的JVM Stack方式,应该提供调节最大、最小容量的手段。

如果线程请求的栈深度大于虚拟机所允许的深度将抛出StackOverflowError;

如果JVM Stack可以动态扩展,但是在尝试扩展时无法申请到足够的内存时抛出OutOfMemoryError。

本地方法栈(Native Method Stack)

本地方法栈与虚拟机栈作用相似,后者为虚拟机执行Java方法服务,而前者为虚拟机用到的Native方法服务。

虚拟机规范对于本地方法栈中方法使用的语言,使用方式和数据结构没有强制规定,甚至有的虚拟机(比如HotSpot)直接把二者合二为一。

这玩意儿抛出的异常跟上面的虚拟机栈一样。

Java堆(Java Heap)

虚拟机管理的内存中最大的一块,同时也是被所有线程所共享的,它在虚拟机启动时创建,这货存在的意义就是存放对象实例,几乎所有的对象实例以及数组都要在这里分配内存。这里面的对象被自动管理,也就是俗称的GC(Garbage Collector)所管理。用就是了,有GC扛着呢,不用操心销毁回收的事儿。

Java堆的容量可以是固定大小,也可以随着需求动态扩展(-Xms和-Xmx),并在不需要过多空间时自动收缩。

Java堆所使用的内存不需要保证是物理连续的,只要逻辑上是连续的即可。

JVM实现应当提供给程序员调节Java 堆初始容量的手段,对于可动态扩展和收缩的堆来说,则应当提供调节其最大和最小容量的手段。

如果堆中没有内存完成实例分配并且堆也无法扩展,就会抛OutOfMemoryError。

方法区(Method Area)

跟堆一样是被各个线程共享的内存区域,用于存储以被虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码等数据。虽然这个区域被虚拟机规范把方法区描述为堆的一个逻辑部分,但是它的别名叫非堆,用来与堆做一下区别。

方法区在虚拟机启动的时候创建。

方法区的容量可以是固定大小的,也可以随着程序执行的需求动态扩展,并在不需要过多空间时自动收缩。

方法区在实际内存空间中可以是不连续的。

Java虚拟机实现应当提供给程序员或者最终用户调节方法区初始容量的手段,对于可以动态扩展和收缩方法区来说,则应当提供调节其最大、最小容量的手段。

当方法区无法满足内存分配需求时就会抛OutOfMemoryError。

运行时常量池(Runtime Constant Pool)

它是方法区的一部分。Class文件中除了有类的版本、字段、方法、接口等描述等信息外,还有一项信息是常量池(Constant Pool Table),用于存放编译期生成的各种字面量和符号引用,这部分内容将在类加载后存放到方法区的运行时常量池中。

Java虚拟机对Class文件的每一部分(自然也包括常量池)的格式都有严格的规定,每一个字节用于存储哪种数据都必须符合规范上的要求,这样才会被虚拟机认可、装载和执行。但对于运行时常量池,Java虚拟机规范没有做任何细节的要求,不同的提供商实现的虚拟机可以按照自己的需要来实现这个内存区域。不过,一般来说,除了保存Class文件中描述的符号引用外,还会把翻译出来的直接引用也存储在运行时常量池中。

运行时常量池相对于Class文件常量池的另外一个重要特征是具备动态性,Java语言并不要求常量一定只能在编译期产生,也就是并非预置入Class文件中常量池的内容才能进入方法区运行时常量池,运行期间也可能将新的常量放入池中,这种特性被开发人员利用得比较多的便是String类的intern()方法。

既然运行时常量池是方法区的一部分,自然会受到方法区内存的限制,当常量池无法再申请到内存时会抛出OutOfMemoryError异常。

2.hotspot虚拟机对象探秘

1.对象的创建

new->检查这个指令参数是否能在常量池中定位到一个类的引用符号->判断这个类是否被加载、解析、初始化过->加载检查通过后,分配内存(指针碰撞,空闲列表)

->对分配内存空间的动作进行同步处理(CAS配上失败重试、TLAB)->虚拟机需要将分配到的内存空间都初始化为零值->对对象进行必要的设置

2.对象的内存布局

还Hotspot虚拟机中,对象的内存中存储的布局分为3块区域:对象头(header)、实例数据(Instance Data)、对其填充(Padding)

Hotspot虚拟机的对象头包括两部分信息,第一部分用于存储自身运行时的数据,例如:哈希码、GC分代年龄、锁状态标识、线程持有锁、偏向线程id、偏向时间戳,这部分数据数据长度在32位和64位的虚拟机(未开启指针压缩)中分别为32bit和64bit,官方称为’Mark word’。对象需要存储的运行时的数据非常多,已经超出了32位、64位bitmap结构所能记录的限度,但是对象头信息是与对象自身定义的数据无关额外的存储成本,考虑到虚拟机的空间效率,Mark work被设计成一个非固定的数据结构以便在极小空间内存储尽可能多的信息,他会根据对象状态复用自己的存储空间。

对象头的另一部分是类型指针,即对象指向他的类元数据的指针,虚拟机通过这个指针来确定这个对象是哪个类的实例。如果对象是一个Java数组,那在对象中还必须有一块用于记录数组长度的数据,因为虚拟机可通过普通 Java对象的元数据信息确定Java对象的大小,但是从数组的元数据中却无法确定数组的大小。

接下来的实例数据是对象真正存储的有效信息,也是在程序代码中所定义的各种类型的字段内容。无论是从父类继承下来的还是在子类中定义的,都需要记录下来。这部分的存储顺序会受到虚拟机分配策略参数和字段在Java源码中定义顺序的影响。Hotspot虚拟机的分配策略是相同宽度的字段总是被分配到一起。在满足这个前提条件下,在父类中定义的变量会出现在子类之前。

3.对象的访问定位

句柄

如果使用句柄访问的话,Java堆中将会划分出一块内存来作为句柄池,reference中存储的就是对象的句柄地址,而句柄中包含了对象实例数据与类型数据的具体各自的地址信息。如图1所示。



直接指针

如果使用直接指针访问的话,Java堆对象的布局中就必须考虑如何放置访问类型数据的相关信息,reference中存储的直接就是对象地址,如图2所示。



3.outofmemoryerror异常

1.java 堆溢出

2.虚拟机栈本地方法溢出

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

4.本机直接内存溢出
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签:  jvm