Java虚拟机-内存布局

Java虚拟机-内存布局

Java数据区

程序计数器

程序计数器(Program Counter Register)可以视作当前线程所执行字节码的行号指示器。

在虚拟机的概念模型中,字节码解释器通过改变程序计数器的值来选取下一条需要执行的字节码指令,分支、循环、跳转、异常处理、线程恢复等基本功能都需要依赖计数器。

在任一时刻,一个cpu内核只会执行一个线程中的指令;java的多线程是通过线程轮流切换并分配处理器执行时间的方式来实现的。为了线程切换后能恢复到正确位置,显然每个线程都需要私有的程序计数器。

如果线程正在执行的是Java方法,计数器记录的是正在执行的虚拟机字节码指令地址;如果正在执行的是Native方法,计数器的值为空(Undefined)。

程序计数器区域不会有OutOfMemoryError。

Java 虚拟机栈

Java虚拟机栈(Java Virtual Machine Stacks)是Java方法执行的内存模型,也是线程私有的。

每个方法执行时都以创建一个栈帧,用于存储局部变量表,操作数栈,动态链接等信息。每个方法从调用到执行完成的过程,就对应一个栈帧在虚拟机中入栈到出栈的过程。

我们常说的“栈”就是指虚拟机栈中的局部变量表这一部分。局部变量表存放了编译期可知的各种基本数据类型(boolean,byte,char,short,int,long,float,double) ,对象引用,reference(指向对象起始地址的引用或指向一个代表对象的句柄或其他与此对象相关的位置)和returnAddress类型(指向一条字节码指令地址)。

float和double类型的数据会占用2个局部变量空间,其他的数据类型只占用一个。局部变量表所需的内存空间在编译期会完成分配,运行期不会改变其大小。注意,这里说的“大小”是指变量槽的数量,虚拟机真正使用多大的内存空间(譬如按照1个变量槽占用32个比特、64个比特,或者更多)来实现一个变量槽,这是完全由具体的虚拟机实现自行决定的事情。

对于Java虚拟机栈这个区域,有两种异常情况:

  1. 栈溢出异常StackOverflowError
  2. 内存不足异常OutOfMemoryError

本地方法栈

本地方法栈(Native Mehtod Stack)与虚拟机栈的作用是十分相似的,同样是线程私有的。区别在于虚拟机栈为虚拟机执行Java方法服务,而本地方法栈则为虚拟机的Native方法服务。

《Java虚拟机规范》对本地方法栈中方法使用的语言、使用方式与数据结构并没有任何强制规定,因此具体的虚拟机可以根据需要自由实现它,甚至有的Java虚拟机(譬如HotSpot虚拟机)直接就把本地方法栈和虚拟机栈合二为一。

与虚拟机栈一样,有两种异常情况:

  1. 栈溢出异常StackOverflowError
  2. 内存不足异常OutOfMemoryError

Java 堆

Java堆是被所有线程共享的一块内存区域,在虚拟机启动时创建。几乎所有的对象实例都在这里分配内存:所有的对象实例以及数组都要在堆上分配。但随着编译器的发展和逃逸分析技术的成熟,并不是”所有的”对象都会在堆上分配。在jvm开启了逃逸分析的相关选项后,不会逃逸的对象将在栈上分配。Java堆是垃圾收集器管理的主要区域,也常被称为”GC堆”。

根据《Java虚拟机规范》的规定,Java堆可以处于物理上不连续的内存空间中,但在逻辑上它应该被视为连续的,这点就像我们用磁盘空间去存储文件一样,并不要求每个文件都连续存放。但对于大对象(典型的如数组对象),多数虚拟机实现出于实现简单、存储高效的考虑,很可能会要求连续的内存空间。

Java堆内存不足时,会抛出内存不足异常OutOfMemoryError

方法区

方法区(Method Area)和Java堆一样,是各个线程共享的内存区域。用于存储已被虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码等数据。

在JDK6的时候HotSpot开发团队就有放弃永久代,逐步改为采用本地内存(NativeMemory)来实现方法区的计划了,到了JDK7的HotSpot,已经把原本放在永久代的字符串常量池、静态变量等移出,而到了JDK8,终于完全废弃了永久代的概念,改用与JRockit、J9一样在本地内存中实现的元空间(Metaspace)来代替,把JDK7中永久代还剩余的内容(主要是类型信息)全部移到元空间中。

《Java虚拟机规范》对方法区的约束是非常宽松的,除了和Java堆一样不需要连续的内存和可以选择固定大小或者可扩展外,甚至还可以选择不实现垃圾收集。相对而言,垃圾收集行为在这个区域的确是比较少出现的,但并非数据进入了方法区就如永久代的名字一样“永久”存在了。这区域的内存回收目标主要是针对常量池的回收和对类型的卸载,一般来说这个区域的回收效果比较难令人满意,尤其是类型的卸载,条件相当苛刻,但是这部分区域的回收有时又确实是必要的。

方法区内存不足时,会抛出内存不足异常OutOfMemoryError

运行时常量池

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

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

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

运行时常量池是方法区的一部分,常量池内存不足时,会抛出内存不足异常OutOfMemoryError

直接内存

直接内存(Direct Memory)并不是虚拟机运行时数据区的一部分,也不是Java虚拟机规范中定义的内存区域。但这部分内存也可能到导致OutOfMemoryError异常的出现。

在JDK1.4中新加入了NIO(NewInput/Output)类,引入了一种基于通道(Channel)与缓冲区(Buffer)的I/O方式,它可以使用Native函数库直接分配堆外内存,然后通过一个存储在Java堆里面的DirectByteBuffer对象作为这块内存的引用进行操作。这样能在一些场景中显著提高性能,因为避免了在Java堆和Native堆中来回复制数据。

显然,本机直接内存的分配不会受到Java堆大小的限制,但是,既然是内存,则肯定还是会受到本机总内存(包括物理内存、SWAP分区或者分页文件)大小以及处理器寻址空间的限制,一般服务器管理员配置虚拟机参数时,会根据实际内存去设置Xmx等参数信息,但经常忽略掉直接内存,使得各个内存区域总和大于物理内存限制(包括物理的和操作系统级的限制),从而导致动态扩展时出现OutOfMemoryError异常。

虚拟机对象(HotSpot)

对象的创建

当虚拟机遇到一条new指令时,

  1. 首先,检查这个指令的参数是否能在常量池中定位到一个类的符号引用,以及它对应的类是否加载,解析和初始化过。如果没有,执行类的加载。
  2. 类成功加载后,虚拟机为对象分配内存。对象所需内存的大小在类加载时已经确定,要做的仅是从Java堆中分配一块内存空间。
    • 假设Java堆中内存是绝对规整的,那么可以在用过的内存和空闲的内存中间放着一个指针作为分界点的指示器。那么分配内存就是将指针向空闲空间挪动一段与对象大小相等的距离。这种分配方式叫做”指针碰撞”。
    • 如果Java的内存不是规整的,已用内存和空闲内存交错,那么需要维护一个列表,记录那些内存是可用的,在分配时从列表中找到一块足够大的空间划分给对象,并更新列表上的记录。这种分配方式叫做”空闲列表”.
  3. 还有一个要考虑的问题是对象创建在虚拟机中十分频繁,即使是修改一个指针的值,在并发状态下也并不是线程安全的。解决这个问题有两种方案:
    • 对分配空间的动作进行同步处理,实际上虚拟机采用CAS和失败重试的方式保证更新操作的原子性。
    • 把内存分配的动作按线程划分在不同的空间进行,即每个线程在堆先分配一小块内存,称为本地线程分配缓冲(Thread Local Allocation Buffer,TLAB);先在线程自身的TLAB上分配,只有当TLAB使用完分配新的TLAB时,才需要同步锁定。
  4. 分配完内存后,虚拟机需要将分配到的内存空间都初始化为零值(不包括对象头),如果使用TLAB,这一工作过程也可以提前至TLAB分配时进行。这一步操作保证了对象的实例字段在Java代码中可以不赋初始值就直接使用。
  5. 接下来是虚拟机对对象进行必要的设置,例如,这个对象是哪个类的实例、如何找到类的元数据信息、对象的hash码、对象的GC分代年龄等信息。这些信息存放在对象的对象头中。到此为止,虚拟机创建了一个新的对象。
  6. 此时对象还没有初始化——方法还没有执行,所有的字段都还为零,在虚拟机执行new指令之后会紧接着执行方法,这样一个对象才完全生产出来。

在CMS的实现里面,为了能在多数情况下分配得更快,设计了一个叫作LinearAllocationBuffer的分配缓冲区,通过空闲列表拿到一大块分配缓冲区之后,在它里面仍然可以使用指针碰撞方式来分配。

对象的内存布局

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

对象头包括两部分信息

  • 第一部分用于存储对象自身运行时数据,如哈希码、GC分代年龄、锁状态标志、线程持有锁、偏向线程ID、偏向时间戳等,官方称为”Mark Word”。考虑到虚拟机的空间效率,Mark Word被设计成一个非固定的数据结构以便在极小的空间内存储尽量多的信息,会根据对象的状态复用自己的存储空间。
  • 另一个部分是类型指针,即对象指向它的类元数据的指针,虚拟机通过这个指针来确定这个对象是哪个类的实例。并不是所有的虚拟机实现都必须在对象数据上保留类型指针,另外,如果对象是个Java叔祖,那么对象头中必须有一块用于记录数组长度的数据,因为虚拟机可以通过Java对象的元数据信息确定Java对象的大小,但是从数组的元数据中无法确定数组的大小。

实例数据部分是对象真正存储的有效信息。

实例数据是程序代码中所定义的各种类型的字段内容,这部分的存储顺序会受到虚拟机分配策略参数(FieldsAllocationStyle)和字段在Java源代码定义顺序的影响。HotSpot虚拟机默认的分配策略为longs/doubles;ints/floats;shorts/chars;bytes/booleans,oop(Ordinary Object Pointers),从分配策略中可以看出长度相同的类型被分配到一起,在这个前提下,父类定义的变量会出现在子类之前。

对齐填充

对齐填充并不是必然存在的,也没有特殊含义。仅仅起着占位符作用,由于HotSpot要求对象起始地址必须是8字节的整数倍,当实例数据没有对齐时,就需要对齐填充来补全。

对象访问定位

建立对象是为了使用对象,Java程序需要通过虚拟机栈上的reference数据来操作堆上的具体对象。reference类型在Java虚拟机规范中只规定了一个指向对象的引用,并没有定义这个引用该如何实现定位、访问堆中的对象的基本位置。

目前主流的访问方式有使用句柄和直接指针两种方式。

  • 使用句柄访问

如果使用句柄的话,Java堆中会划分出一块内存作为句柄池,reference中存放的就是对象的句柄地址,而对象的句柄地址中包含了对象实例数据和类型数据各自的具体指针地址信息。

间接访问

  • 直接指针访问

如果使用直接指针访问,那么Java堆对象的布局中将放置类型数据的相关信息,reference中存储的就是对象地址。

直接访问

这两种访问方式各有优势:

  1. 使用句柄访问的好处是reference中存储的是稳定的句柄地址,对象移动(垃圾回收时会移动对象)时只会改变句柄中的实例数据指针,本身不用修改。
  2. 使用直接指针的最大好处是速度更快,它会节省一次指针定位的时间开销,由于java的对象访问十分频繁,节省的资源也十分可观。sun公司的HotSpot就是使用第二种方式访问对象的。

OutOfMemoryError异常

Java堆溢出

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
/**
* 摘自 深入理解Java虚拟机 2.4节
* VM option: -Xms20m -Xmx20m -XX:+HeapDumpOnOutOfMemoryError
* ********** output ********
* java.lang.OutOfMemoryError: GC overhead limit exceeded
* Dumping heap to java_pid1517.hprof ...
* Heap dump file created [26636949 bytes in 0.147 secs]
*/
public class HeapOOM {

static class OOMObject{
private String name = OOMObject.class.toString();
}

public static void main(String[] args){
List<OOMObject> list = new ArrayList<OOMObject>();

while(true){
list.add(new OOMObject());
}
}

}

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

因为HotSpot虚拟机并不区分虚拟机栈和本地方法区,所以对于HotSpot来说,-Xoss参数(设置本地方法栈大小)存在,但是无效。栈容量只由-Xss 参数设置。

关于虚拟机栈和本地方法栈,java虚拟机定义了两种异常:

  1. 如果线程请求的栈深度大于虚拟机所允许的最大深度,抛出异常StackOverflowError
  2. 如果虚拟机在扩展栈的时候无法申请到足够的内存空间,抛出异常OutOfMemoryError
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
/**
* 摘自 深入理解Java虚拟机 2.4节
* VM option: -Xss256k
* ************* output ************
* Exception in thread "main" java.lang.StackOverflowError
* at JavaVMStackSOF.stackLength(JavaVMStackSOF.java:10)
* at JavaVMStackSOF.stackLength(JavaVMStackSOF.java:10)
*/
public class JavaVMStackSOF {

private int stackLength =1 ;

public void stackLength(){
stackLength ++;
stackLength();
}

public static void main(String[] args){
JavaVMStackSOF javaVMStackSOF = new JavaVMStackSOF();
try{
javaVMStackSOF.stackLength();
}catch (Exception e){
e.printStackTrace();
}
}
}

在单线程下,无论是栈帧太大还是虚拟机容量太小,当内存无法分配时,虚拟机抛出的都是StackOverflowError。如果不仅限于单线程,通过不断建立线程的方式可以产生内存溢出异常,其原因是因为操作系统分配给每个进程的内存是有限制的,多开线程会消耗进程的内存空间,从而导致OutOfMemoryError

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
/**
* 摘自 深入理解Java虚拟机 2.4节
* VM option: -Xss2M
* ************* output ************
* win7 虚拟机 + Eclipse 死机
*/
public class JavaVMStackOOM{
private void dontStop(){
while(true){
}
}
private void stackLeakByThread(){
while(true){
Thread thread = new Thread(new Runnable(){
@Override
public void run(){
dontStop();
}
});
thread.start();
}
}
public static void main(String[] args){
JavaVMStackOOM javaVMStackOOM = new JavaVMStackOOM();
javaVMStackOOM.stackLeakByThread();
}
}

方法区和常量池溢出

JDK1.7开始逐步”去永久代”,这里我们把JDK1.7和JDK1.6及以前分开讨论。

在JDK1.6及以前,String.intern()是个Native方法,其作用是:如果字符串常量池中已经包含此String对象的字符串,则返回池中这个字符串的String对象;否则,将此String对象包含的字符串复制到永久代中,返回永久代中的String实例的引用。

在JDK1.6及以前,常量池分配在永久代中,可以通过-XX:PermSize-XX:MaxPermSize限制方法区大小,从而限制常量池容量。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
/**
* JDK1.6
* VM Option: -XX:PermSize=1M -XX:MaxPerSize=1M
* *********** output ************
* Exception in thread "main" java.lang.OutOfMemoryError: PermGen space
*/
public class RuntimeConstantPoolOOM {
public static void main(String[] args){
List<String> list = new ArrayList<String>();
int i = 0;
while(true){
list.add(String.valueOf(++i).toString());
}
}
}

从异常输出信息看,提示是”PermGen space”,说明是内存的永久代,也就是方法区,溢出。但是在JDK1.7及以后的版本,while循环会一直执行下去。

值得一提的是JDK1.7之后String.intern()的实现发生了变化。下面这段代码,在JDK1.6中的执行结果和1.7的执行结果是不同的。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
/**
* JDK1.6
* *********** output ************
* false
* false
* ---------------------------------
* JDK1.7
* *********** output ************
* true
* false
*/
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("计算机").append("软件").toString();
System.out.println(str2.intern()==str2);
}
}

原因是:

  • JDK 1.6 中,intern()方法会把首次遇到的字符串实例复制到永久代中,然后返回永久代中的字符串实例引用。而StringBuilder创建的字符串对象存在于堆中,所以返回false
  • JDK 1.7 中,intern()的实现不会再复制实例,只是在常量池中记录首次出现的实例引用,因此第一次出现的String和intern()返回的引用是同一个。第二次执行intern()方法时,返回的引用和当前不是同一个,不是首次出现。
使用cglib动态生成类导致方法区OOM
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
/**
* 摘自 深入理解Java虚拟机 2.4节
* VM Option: -XX:PermSize=1M -XX:MaxPerSize=1M
*/
public class JavaMethodAreaOOM {
static class OOMObject{

}
public static void main(String[] args){
while(true){
Enhancer enhancer = new Enhancer();
enhancer.setSuperClass(OOMObject.class);
enhancer.setUserCache(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();
}
}
}

直接内存溢出

直接内存可以通过 -XX:MaxDirectMemorySize指定,如果不指定,则默认与Java堆的大小一致。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
/**
* 摘自 深入理解Java虚拟机 2.4节
* VM Option: -Xmx20M -XX:MaxDirectMemorySize=10M
*/
public class DirectMemoryOOM{
private static final int size = 1024*1024;

public static void main(String[] args)throws Exception{
Field unsafeField = Unsafe.class.getDeclaredFields()[0];
unsafeField.setAccessible(true);
Unsafe unsafe = (Unsafe) unsafeField.get(null);
while(true){
unsafe.allocateMemory(size);
}
}
}
-------------本文结束感谢您的阅读-------------
坚持分享,您的支持将鼓励我继续创作!
0%