JVM--Java内存区域与内存溢出异常

1.运行时数据区域

1.程序计数器

• 概括:程序计数器是一块较小的内存空间,可以看作是当前线程所执行的字节码的行号指示器.

• 作用:在Java虚拟机的概念模型里,字节码解释器工作是就是通过改变这个计数器的值爱选取下一条需要执行的字节码指令,它是程序控制流的指示器,分支,循环,跳转,异常处理,线程恢复等基础功能都需要依赖这个计数器来完成

• 线程私有:Java虚拟机的多线程是通过线程轮流切换,分配处理器执行时间的方式来实现的,在任何一个确定的时刻,一个处理器只会执行一条线程中的指令,为了确保线程切换后能够恢复到正确的执行位置,每条线程都需要一个独立私有的程序计数器.

• 表现:如果线程执行的是Java方法,计数器记录的是正在执行的虚拟机字节码指令的地址;如果执行的是本地方法,计数器则为空.

• 异常:唯一一个在内存区域没有OutOfMemoryError异常的区域.

2.Java虚拟机栈

• 概括:用来描述Java方法执行的线程内存模型:每个方法被执行的时候,Java虚拟机都会同步创建一个栈帧用于存储局部变量表,操作数栈,动态链接,方法出口等信息.每一个方法被调用直至执行完毕的的过程,就对应着一个栈帧在虚拟机栈中从入栈到出栈的过程.

• 局部变量表:存放了编译器可知的各种Java虚拟机基本数据类型(boolean,byte,char,short,int,flot,long,double),对象引用(reference类型,它并不等同于对象本身,可能是一个指定对象相关的位置)和returnAdress类型(指向了一条字节码指令的地址).

• 线程私有

• 数据类型在局部变量表中的存储空间以局部变量槽(Solt)来表示,其中64位长度的long和double类型的数据会占用两个变量槽,其余的数据类型只占用一个.局部变量表所需的内存空间在编译器完成分配,当进入一个方法时,这个方法需要在栈帧中分配多大的局部变量空间是完全确定的,在方法运行期间不会改变局部变量表的大小.

• 异常:如果线程请求的栈深度大于虚拟机所允许的深度,将抛出StackOverflowError异常;如果Java虚拟机栈容量可以动态扩展,当栈扩展时无法申请到足够的内存会抛出OutOfMemoryError异常

3.本地方法栈

• 概述:本地方法栈与虚拟机栈所发挥的作用是非常相似的,其区别只是虚拟机栈为虚拟机执行Java方法服务,而本地方法栈则是为虚拟机使用到的本地方法服务.
• <<Java虚拟机规范>>对本地方法栈中的方法是用的语言,使用方式与数据结构并没有任何强制规定.可以自由实现,甚至有Java虚拟机(HotSpot虚拟机)直接就把本地方法栈和虚拟机栈合二为一.
• 私有
• 异常:StackOverflowError和OutOfMemoryReeoe

4.Java堆

• 概述:是虚拟机所管理的内存中最大的一块区域,所有线程共享一块区域,在虚拟机启动时创建.
• 线程公有
• 目的:存放对象实例.
• <<Java虚拟机规范>>对Java堆的描述:“所有的对象实例以及数组都应当在堆上分配”
• 从实现角度来看:随着未来Java语言的发展来看"所有的对象"变得不那么绝对,如后的值类型支持,逃逸分析技术,栈上分配,标量替换优化手段.
• Java堆是垃圾收集器管理的内存区域,又称"GC堆".其中对于区域的划分的垃圾回收空间仅仅是一部分垃圾回收器的共同特性或设计风格,非Java虚拟机具体实现的固有内存布局,更不是<<Java虚拟机规范>>里对Java堆的进一步细分.
• 从分配内存角度看,所有线程共享的Java堆中可以划分出多个线程私有的分配缓冲区(TLAB),以提升对象分配时的效率.
• <<Java虚拟机规范>>的规定,Java堆可以处于物理上不连续的内存空间中,但在逻辑上视为连续的.
• Java堆的扩展参数: -Xmx和-Xms:Java堆既可以被实现成固定大小的,也可以是扩展的.主流的都是按照可扩展来实现的.
• 异常:如果在Java堆中没有内存完成实例分配,并且堆也无法在扩展时,Java虚拟机将会抛出OutOfMemoryError异常.

5.方法区

• 概述:是各个线程共享的内存区域,它用于存储已被虚拟机加载的类型信息,常量,静态变量,即时编译器编译后的代码缓存等数据.<<Java虚拟机规范>>中把方法去描述为堆的一个逻辑部分,也被称为"非堆(Non-Heap)".
• 线程公有
• "永久代":该称呼只是基于主流Java虚拟机使用过的对应方法区的称号.比如HotSpot虚拟机,其当时设置的目的是希望垃圾回收器能够向管理Java堆一样去管理方法区,省去专门为方法区编写内存管理代码.原则上如何实现方法区属于虚拟机具体实现细节,不受<<Java虚拟机规范>>的管束.
• 基于HotSpot虚拟机的方法区修改:JDK 6 HotSpot开发团队要放弃永久代逐步改为采用本地内存.JDK 7 把原本放在永久代的字符串常量池,静态变量等移出.JDK 8 完全废弃了永久代,使用元空间.将剩余的(主要是类型信息)全部移到元空间中.
• 回收目的:<<Java虚拟机规范>>对于方法区的约束非常宽松,除了和Java堆一样不需要连续的内存和可以选择固定大小或者可扩展外,甚至还可以选择不实现垃圾收集. 其主要回收的目的是:针对常量池的回收和对类型的卸载.
• 异常:如果方法区无法满足新的内存分配需求时,将抛出OutOfMemoryError异常.

6.运行时常量池

• 概述:是方法区的一部分,Class文件中除了有类的版本,字段,方法,接口等描述信息外,还有一项信息是常量池表,用于存放编译器生成的各种字面量与符号引用,这部分内容将在类加载后存放到方法区的运行时常量池中.
• <<Java虚拟机规范>>并没有做任何细节的要求,不同提供商实现的虚拟机可以按照自己的需要来实现这个内存区域.不过一般来说,除了保存Class文件中的描述的符号引用外,还会把有符号引用翻译出来的直接引用也存储在运行时常量池中.
• 运行时常量池相对于Class文件常量池的另外一个重要的特征是具备动态性.并非只有预置入Class文件中常量池的内容才能进入方法去运行时常量池,运行期间也可以将新的常量放入池中.比如:String类的intern()方法.
• 异常:OutOfMemoryError异常.

7.直接内存

• 概述:直接内存并不是虚拟机运行时数据区的一部分,也不是<<Java虚拟机规范>>中定义的内存区域,但是这部分内存也被频繁地使用,而且也可能导致OutOfMemoryError异常出现.
• 在JDK 1.4中新加入了NIO类,引入了一种基于管道与缓冲区的I/O方式,它可以使用Native函数库直接分配对外内存,然后通过一个存储在Java对立面的DirectByteBuffer对象作为这块内存的引用进行操作.这样能在一些场景中显著提高性能,因为避免了在Java堆和Native堆中来回复制数据.
• 本机直接内存分布不会受到Java堆大小的限制.
• 异常:OutOfMemoryError异常

2.HotSpot虚拟机对象探秘

1.对象的创建

Java程序在语言层面上创建一个对象通常仅仅是new关键字进行创建,但在虚拟中的对象创建过程是?

第一步

• 当Java虚拟机遇到一条字节码new指令时,首先去检查这个指令的参数是否能在常量池中定位到一个类的符号引用,并且检查这个符号引用代表的类是否已被加载,解析和初始化.如果没有,那必须先执行相应的类加载过程.

第二步

• 虚拟机为新生对象分配内存.
  该对象所需的内存大小在类加载后便可确定.
  Java堆绝对规整:将会使用"指针碰撞"分配方式;
  Java堆不规整:将会使用"空闲列表"分配方式;
  选择哪种分配方式是由Java堆的规整来决定的,Java堆是否规整是由所采用的回收算法所决定的.(压缩算法–指针碰撞;清除算法–空闲列表);
• 存在的问题:对象创建在虚拟机栈中是非常频繁的行为,在并发情况下并不是线程安全的.(例如:当正在给A对象分配内存,指针还没来得及修改,对象B又同时使用了原来的指针来分配内存)
• 解决方案:
  方案一:对分配内存空间的动作进行同步处理–实际上虚拟机采用的是CAS配上失败重试的方式保证更新操作的原子性;
  方案二:把内存分配的动作按照线程划分在不同的空间之中进行,即每个线程在Java堆中预先分配一小块内存,称为本地线程分配缓冲(TLAB),哪个线程要分配内存,就在哪个线程的本地缓冲区中分配只有本地缓冲区用完了,分配新的缓冲区时才需要同步锁定.虚拟机是否使用TLAB,可以通过-XX:+/-UseTLAB参数来设定.

第三步

也许这就是全局变量不用初始化的原因吧QAQ

• 对分配到的内存空间(但不包括对象头)都初始化为零值,如果使用了TLAB的话,这一项工作也可以提前至TLAB分配时顺便进行. 这些操作保证了对象的实例字段在Java代码中可以不赋初始值就直接使用,使程序能访问到这些字段的数据类型所对应的零值.

第四步

• Java虚拟机对对象进行必要的设置.(例如:这个对象是哪个类的实例,如何才能找到类的元数据信息,对象的哈希码,对象的GC分代年龄等信息).这些信息都会存放在对象的对象头之中.根据虚拟机当前运行状态的不同,如是否启用偏向锁等,对象头会有不同的设置方式.

以上工作完成后,从虚拟机视角来看,一个对象已经产生了,但是从Java程序视角看,对象的创建才刚刚开始–构造函数,即Class文件中的<init>()方法还没有执行所有的字段都为默认的零值,对象需要的其他资源和状态信息也还没有按照预定的意图构造好.一般来说,new指令之后会接着执行<init>()方法,按照程序员的意愿对对象进行初始化,这样一个真正可用的对象才算完全被构造出来.

2.对象的内存布局

• 在HotSpot虚拟机里,对象在堆内存中的存储布局可以划分为三个部分:对象头(Header),实例数据(Instance Data)和对其填充(Padding).
• 对象头包括两部分:
  第一类:用于存储对象自身的运行时数据.(例如哈希码,GC分代年龄,锁状态标志,线程持有锁,偏向线程ID,偏向时间戳等),因为对象需要存储的运行时数据很多,但对象头里的信息是与对象自身定义的数据无关的额外存储成本,考虑到虚拟机的空间效率,Mark Word被设计成一个有着动态定义的数据结构,以便在极小的空间内存储尽量多的数据,根据对象的状态复用自己的存储空间.
  第二类:类型指针.即对象指向它的类型元数据的指针,Java虚拟机通过这个指针来确定该对象是哪个类的实例.并不是所有的虚拟机实现都必须要在对象数据上保留类型指针.换句话说,查找对象的元数据信息并不一定要经过对象本身.此外,如果是一个Java数组,那在对象头中还必须要有一块用于记录数组长度的数据,因为虚拟机可以通过普通Java对象的元数据信息确定Java对象的大小,但如果数组的长度是不确定的,将无法通过元数据中的信息推断出数组的大小.
• 实例数据:是对象真正存储的有效信息,即我们在程序代码里面所定义的各种类型的字段内容,无论是从父类继承下来的,还是子类中定义的字段都必须记录起来.这部分的存储顺序会受到虚拟机分配策略参数(-XX:FieldsAllocationStyle参数)和字段在Java源码中定义顺序的影响.HotSpot虚拟机默认的分配顺序为longs/doubles,ints,shorts/chars,bytes/booleans,oops,相同宽度的字段总是被分配到一起存放,满足这个前提下,在父类中定义的变量会出现在子类之前.如果HotSpot虚拟机的+XX:CompactFields参数值为true,那子类中较窄的变量也允许插入父类变量的空隙之中,以节省出一点点空间.
• 对其填充不是必然存在的,没有特别含义,起到占位符作用.因为HotSpot虚拟机的自动内存管理系统要求起始地址必须是8字节的整数倍.如果示例数据部分没有对齐的话,就需要通过对其填充来补全.

3.对象的访问定位

• 概述:Java程序会通过栈上的reference数据来操作栈上的具体对象.由于reference类型在<<Java虚拟机规范>>里面只规定了它是一个指向对象的引用,并没有定义这个引用应该通过什么方式去定位,访问到堆中对象的具体位置,所以对象访问方式也是由虚拟机实现而定的,主流的访问方式主要有使用句柄和直接指针两种:

  1. 如果 使用句柄访问的话,Java堆中将可能会划分出一块内存来作为句柄池,reference中存储的就是对象的句柄地址,而句柄中包含了对象实例数据与类型数据各组具体的地址信息.
  2. 如果使用直接指针访问的话,Java堆中对象的内存布局就必须考虑如何放置访问类型数据的相关信息,reference中存储的直接就是对象地址,如果只是访问对象本身的话,就不需要多一次间接访问的开销.
     

• 虚拟机HotSpot主要采用的是通过直接指针访问对象.