我们在研究类加载机制的时候,可以发现在装载阶段中有运行时数据,堆,方法区等名词。
在装载阶段会将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构以及在Java堆中生成一个代表这个类的java.lang.Class对象,作为对方法区中这些数据的访问入口。
说白了就是类文件被类装载器装载进来之后,类中的内容(比如变量,常量,方法,对象等这些数据得要有个去处,也就是要存储起来,存储的位置肯定是在JVM中有对应的空间)。这就是我们所说的运行时数据区。
官网 :docs.oracle.com/javase/spec…
1. 初识
我们可以根据官网提供的信息初步了解下运行时数据区。
在看下文前,我们首先需要对类加载机制中装载阶段有一定的了解:
通过一个类的全限定名获取定义此类的二进制字节流(由上可知,我们不一定从字节码文件中获得,还有上述很多种方式)。
那么这个时候我们是不是需要一个工具,来寻找获取我们的二进制字节流?
正好我们的java中恰好有这么一段代码模块。可以实现通过类全名来获取此类的二进制字节流这个动作,并且将这个动作放到java虚拟机外部去实现,以便让应用程序决定如何获取所需要的类,实现这个动作的代码模块成为“类加载器”。
将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构
在Java堆中生成一个代表这个类的java.lang.Class对象,作为对方法区中这些数据的访问入口
1.1 Method Area (方法区)
- 方法区是各个线程共享的内存区域,在虚拟机启动时创建;
The Java Virtual Machine has a method area that is shared among all Java Virtual Machine threads.
The method area is created on virtual machine start-up.
- 虽然Java虚拟机规范把方法区描述为堆的一个逻辑部分,但是它却又一个别名叫做Non-Heap(非堆),目的是与Java堆区分开来;
Although the method area is logically part of the heap,......
- 用于存储已被虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码等数据;
It stores per-class structures such as the run-time constant pool, field and method data, and the code for methods and constructors, including the special methods (§2.9) used in class and instance initialization and interface initialization.
- 当方法区无法满足内存分配需求时,将抛出OutOfMemoryError异常;
If memory in the method area cannot be made available to satisfy an allocation request, the Java Virtual Machine throws an OutOfMemoryError.
此时我们可以回看装载阶段的第2步,将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构如果这时候把从Class文件到装载的第(1)和(2)步合并起来理解的话,可以画个图:
1.2 Heap (堆)
- Java堆是Java虚拟机所管理内存中最大的一块,在虚拟机启动时创建,被所有线程共享。
- Java对象实例以及数组都在堆上分配。
The Java Virtual Machine has a heap that is shared among all Java Virtual Machine threads. The heap is the run-time data area from which memory for all class instances and arrays is allocated. The heap is created on virtual machine start-up.
此时回看装载阶段的第3步,在Java堆中生成一个代表这个类的java.lang.Class对象,作为对方法区中这些数据的访问入口。
此时装载(1)(2)(3)的图可以改动一下
1.3 Java Virtual Machine Stacks (虚拟机栈)
经过上面的分析,类加载机制的装载过程已经完成,后续的链接,初始化也会相应的生效。
假如目前的阶段是初始化完成了,后续做啥呢?肯定是Use使用咯,不用的话这样折腾来折腾去有什么意义?那怎样才能被使用到?换句话说里面内容怎样才能被执行?比如通过主函数main调用其他方法,这种方式实际上是main线程执行之后调用的方法,即要想使用里面的各种内容,得要以线程为单位,执行相应的方法才行。那一个线程执行的状态如何维护?一个线程可以执行多少个方法?这样的关系怎么维护呢?
- 虚拟机栈是一个线程执行的区域,保存着一个线程中方法的调用状态。换句话说,一个Java线程的运行状态,由一个虚拟机栈来保存,所以虚拟机栈肯定是线程私有的,独有的,随着线程的创建而创建。
Each Java Virtual Machine thread has a private Java Virtual Machine stack, created at the same time as the thread.
-
每一个被线程执行的方法,为该栈中的栈帧,即每个方法对应一个栈帧。
调用一个方法,就会向栈中压入一个栈帧;一个方法调用完成,就会把该栈帧从栈中弹出。
A Java Virtual Machine stack stores frames (§2.6).
A new frame is created each time a method is invoked. A frame is destroyed when its method invocation completes.
- 图解栈和栈帧
void a(){
b();
}
void b(){
c();
}
void c(){
}
- 栈帧
官网 :docs.oracle.com/javase/spec…
栈帧 :每个栈帧对应一个被调用的方法,可以理解为一个方法的运行空间。
每个栈帧中包括局部变量表(Local Variables)、操作数栈(Operand Stack)、指向运行时常量池的引用(Reference to the run-time constant pool)、方法返回地址(Return Address)和附加信息。
-
局部变量表:方法中定义的局部变量以及方法的参数存放在这张表中。
局部变量表中的变量不可直接使用,如需要使用的话,必须通过相关指令将其加载至操作数栈中作为操作数使用。
-
操作数栈:以压栈和出栈的方式存储操作数。
-
动态链接:每个栈帧都包含一个指向运行时常量池中该栈帧所属方法的引用,持有这个引用是为了支持方法调用过程中的动态连接(Dynamic Linking)。
-
方法返回地址:当一个方法开始执行后,只有两种方式可以退出,一种是遇到方法返回的字节码指令;一种是遇见异常,并且这个异常没有在方法体内得到处理。
- 结合字节码指令理解栈帧
javap -c Person.class > Person.txt
反编译文件,将其输出方便我们查看。
public class Person {
private String name = "Jack";
private int age;
private final double salary = 100;
private static String address;
private final static String hobby = "Programming";
private static Object obj = new Object();
public void say() {
System.out.println("person say...");
}
public static int calc(int op1, int op2) {
op1 = 3;
int result = op1 + op2;
Object obj = new Object();
return result;
}
public static void main(String[] args) {
calc(1, 2);
}
}
Compiled from "Person.java"
class Person {
...
public static int calc(int, int);
Code:
0: iconst_3 //将int类型常量3压入[操作数栈]
1: istore_0 //将int类型值存入[局部变量0]
2: iload_0 //从[局部变量0]中装载int类型值入栈
3: iload_1 //从[局部变量1]中装载int类型值入栈
4: iadd //将栈顶元素弹出栈,执行int类型的加法,结果入栈
5: istore_2 //将栈顶int类型值保存到[局部变量2]中
6: iload_2 //从[局部变量2]中装载int类型值入栈
7: ireturn //从方法中返回int类型的数据
...
}
关于index是从0开始还是从1开始,官网有相关说明:
在类方法调用时,从局部变量0开始的连续局部变量中传递任何参数。在实例方法调用时,总是使用局部变量0来传递对正在调用实例方法的对象的引用(在Java编程语言中是这样的)。任何参数随后都从局部变量1开始传递到连续的局部变量中。
On class method invocation, any parameters are passed in consecutive local variables starting from local variable 0. On instance method invocation, local variable 0 is always used to pass a reference to the object on which the instance method is being invoked (this in the Java programming language). Any parameters are subsequently passed in consecutive local variables starting from local variable 1.
1.4 The pc Register (程序计数器)
我们都知道一个JVM进程中有多个线程在执行,而线程中的内容是否能够拥有执行权,是根据CPU调度来的。
假如线程A正在执行到某个地方,突然失去了CPU的执行权,切换到线程B了,然后当线程A再获得CPU执行权的时候,怎么能继续执行呢?这就是需要在线程中维护一个变量,记录线程执行到的位置。
如果线程正在执行Java方法,则计数器记录的是正在执行的虚拟机字节码指令的地址;
如果正在执行的是Native方法,则这个计数器为空。
The Java Virtual Machine can support many threads of execution at once (JLS §17). Each Java Virtual Machine thread has its own pc (program counter) register. At any point, each Java Virtual Machine thread is executing the code of a single method, namely the current method (§2.6) for that thread. If that method is not native, the pc register contains the address of the Java Virtual Machine instruction currently being executed. If the method currently being executed by the thread is native, the value of the Java Virtual Machine's pc register is undefined. The Java Virtual Machine's pc register is wide enough to hold a returnAddress or a native pointer on the specific platform.
1.5 Native Method Stacks (本地方法栈)
如果当前线程执行的方法是Native类型的,这些方法就会在本地方法栈中执行。
那如果在Java方法执行的时候调用native的方法呢?看完下图之后大家应该就知道是如何调用的了。
除了上面五块内存之外,其实我们的JVM还会使用到其他两块内存:
-
直接内存(Direct Memory)
并不是虚拟机运行时数据区的一部分,也不是JVM规范中定义的内存区域,但是这部分内存也被频繁地使用,而且也可能导致OutOfMemoryError 异常出现,所以我们放到这里一起说一下。
在JDK1.4 中新加入了NIO(New Input/Output)类,引入了一种基于通道(Channel)与缓冲区(Buffffer)的I/O 方式,它可以使用Native 函数库直接分配堆外内存,然后通过一个存储在Java 堆里面的DirectByteBuffer 对象作为这块内存的引用进行操作。这样能在一些场景中显著提高性能,因为避免了在Java 堆和Native 堆中来回复制数据。
本机直接内存的分配不会受到Java 堆大小的限制,但是,既然是内存,则肯定还是会受到本机总内存的大小及处理器寻址空间的限制。因此在分配JVM空间的时候应该考虑直接内存所带来的影响,特别是应用到NIO的场景。
-
其他内存
Code Cache:JVM本身是个本地程序,还需要其他的内存去完成各种基本任务,比如,JIT编译器在运行时对热点方法进行编译,就会将编译后的方法储存在Code Cache里面;GC等功能。需要运行在本地线程之中,类似部分都需要占用内存空间。这些是实现JVM JIT等功能的需要,但规范中并不涉及。
2. 实操
2.1 栈指向堆
如果在栈帧中有一个变量,类型为引用类型,比如 Object obj = new Object(),这时候就是典型的栈中元素指向堆中的对象。
2.2 方法区指向堆
方法区中会存放静态变量,常量等数据。如果是下面这种情况,就是典型的方法区中元素指向堆中的对象。
private static Object obj=new Object();
2.3 堆指向方法区
堆还能指向方法区?我也不太信…
注意,方法区中会包含类的信息,堆中会有对象,那怎么知道对象是哪个类创建的呢?
一个对象怎么知道它是由哪个类创建出来的?怎么记录?这就需要了解一个Java对象的具体信息咯。
2.4 Java对象内存模型
一个Java对象在内存中包括3个部分:对象头、实例数据和对齐填充。(这一块在并发编程中也会用到)
2.4.1 验证hashCode的储存方式
这就需要用到jol工具了。
依赖
<dependency>
<groupId>org.openjdk.jol</groupId>
<artifactId>jol-core</artifactId>
<version>RELEASE</version>
</dependency>
实体类
public class Worker {
private Integer id;
private String username;
private String password;
public Integer getId() {
return id;
}
public String getPassword() {
return password;
}
public String getUsername() {
return username;
}
public void setUsername(String username) {
this.username = username;
}
public void setPassword(String password) {
this.password = password;
}
public void setId(Integer id) {
this.id = id;
}
@Override
public String toString() {
return super.toString();
}
public static void printf(Worker p) {
// 查看对象的整体结构信息
// JOL工具类
System.out.println(ClassLayout.parseInstance(p).toPrintable());
}
}
测试代码
public class Test {
public static void main(String[] args) {
Worker work = new Worker();
System.out.println(work);
Worker.printf(work);
System.out.println(work.hashCode());
}
}
测试结果
1956725890这个数字是我们的HashCode值,转换成16进制可得74a14482,经过对比。
2.4.2 **Class Pointer **引用方式
引用定位到对象的方式有两种,一种叫句柄池访问,一种叫直接访问。
两者区别:
-
句柄池:
使用句柄访问对象,会在堆中开辟一块内存作为句柄池,句柄中储存了对象实例数据(属性值结构体)的内存地址,访问类型数据的内存地址(类信息,方法类型信息),对象实例数据一般也在heap中开辟,类型数据一般储存在方法区中。
优点:reference存储的是稳定的句柄地址,在对象被移动(垃圾收集时移动对象是非常普遍的行为)时只会改变句柄中的实例数据指针,而reference本身不需要改变。
缺点:增加了一次指针定位的时间开销。
-
直接访问:
直接指针访问方式指reference中直接储存对象在heap中的内存地址,但对应的类型数据访问地址需要在实例中存储。
优点:节省了一次指针定位的开销。
缺点:在对象被移动时(如进行GC后的内存重新排列),reference本身需要被修改。
2.4.3 指针压缩
在32位系统中,类型指针为4字节32位,在64位系统中类型指针为8字节64位,但是JVM会默认的进行指针压缩,所以我们上图输出结果中类型指针也是4字节32位。如果我们关闭指针压缩的话,就可以看到64位的类型指针了,所以我们通常在部署服务时,JVM内存不要超过32G,因为超过32G就无法开启指针压缩了。
关闭指针压缩 : -XX:+UseCompressedOops
2.4.4 对齐填充
没有对齐填充就可能会存在数据跨内存地址区域存储的情况
在没有对齐填充的情况下,内存地址存放情况如下:
因为处理器只能0x00-0x07,0x08-0x0F这样读取数据,所以当我们想获取这个long型的数据时,处理器必须要读两次内存,第一次(0x00-0x07),第二次(0x08-0x0F),然后将两次的结果才能获得真正的数值。
那么在有对齐填充的情况下,内存地址存放情况是这样的:
现在处理器只需要直接一次读取(0x08-0x0F)的内存地址就可以获得我们想要的数据了。
对齐填充存在的意义就是为了提高CPU访问数据的效率,这是一种以空间换时间的做法;正如我们所见,虽然访问效率提高了(减少了内存访问次数),但是在0x07处产生了1bit的空间浪费。
做一个小小的测试:
比如我们在上文给出的worker类中添加一个参数:
然后这个时候我们重新运行测试类:
这个时候由于一个就发生了对齐填充。