JVM-复习（一）

不想当咸鱼的咸鱼
187 阅读13分钟

从源码到文件

class Person{    
	private String name;    
    private int age;    
    private static String address;    
    private final static String hobby="Programming";    
    public void say(){        
    	System.out.println("person say...");    
    }    
    public int calc(int op1,int op2){       
   		 return op1+op2;    
    } 
}
  • .class文件简单分析

cafe babe：magic

0000 0034：对应10进制的52，代表JDK8中的一个版本

0027：对应十进制27，代表常量池中27个常量

魔数与class文件版本 
常量池 
访问标志 
类索引、父类索引、接口索引 
字段表集合 
方法表集合 
属性表集合

类加载机制

  • 装载：查找和导入class文件
  1. 通过一个类的全限定名获取定义此类的二进制字节流
  2. 将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构
  3. 在堆中生成一个代表这个类 java.lang.Class 对象，作为方法区中这些数据的唯一入口
  • 验证：验证被加载类的正确性
  1. 文件格式验证
  2. 元数据验证
  3. 字节码验证
  4. 符号引用验证
  • 准备：为类的静态变量分配内存，初始化为默认值
  • 解析：把类中的符号转换为直接引用
  • 初始化：对类的静态变量，静态代码快执行初始化操作（按照顺序执行）

类装载器 ClassLoader

在装载(Load)阶段，其中第(1)步:通过类的全限定名获取其定义的二进制字节流，需要借助类装载器完成，顾名思义，就是用来装载Class文件的。

(1)通过一个类的全限定名获取定义此类的二进制字节流

  • Java中可以划分为四种类加载器

引用类加载器、扩展类加载器、系统类加载器、自定义类加载器。

  • 加载原则

检查某个类是否已经加载：顺序是自底向上，从Custom ClassLoader到BootStrap ClassLoader逐层检查，只要某个Classloader已加载，就视为已加载此类，保证此类只被ClassLoader加载一次。

ClassLoader有一个private字段classes，它是一个Vector，包含了这个类加载器已经加载了的类的Class对象(之所以设置它是为了防止它们被gc)

加载的顺序：加载的顺序是自顶向下，也就是由上层来逐层尝试加载此类。

  • 双亲委派机制

定义：如果一个类加载器在接到加载类的请求时，它首先不会自己尝试去加载这个类，而是把这个请求任务委托给父类加载器去完成，依次递归，也就是说先会被引用类加载器加载，如果父类加载器可以完成类加载任务，就成功返回；只有父类加载器无法完成此加载任务时，才自己去加载。

优势：Java类随着加载它的类加载器一起具备了一种带有优先级的层次关系。比如，Java中的Object类，它存放在rt.jar之中,无论哪一个类加载器要加载这个类，最终都是委派给处于模型最顶端的启动类加载器进行加载，因此Object在各种类加载环境中都是同一个类。如果不采用双亲委派模型，那么由各个类加载器自己去加载的话，那么系统中会存在多种不同的Object类。

破坏：可以继承ClassLoader类，然后重写其中的loadClass方法，其他方式大家可以自己了解拓展一下。

运行时数据区

在装载阶段的第(2),(3)步可以发现有运行时数据，堆，方法区等名词

(2)将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构

(3)在Java堆中生成一个代表这个类的java.lang.Class对象，作为对方法区中这些数据的访问入口

说白了就是类文件被类装载器装载进来之后，类中的内容(比如变量，常量，方法，对象等这些数据得要有个去处，也就是要存储起来，存储的位置肯定是在JVM中有对应的空间)

Method Area(方法区)

方法区是各个线程共享的内存区域，在虚拟机启动时创建。

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

虽然Java虚拟机规范把方法区描述为堆的一个逻辑部分，但是它却又一个别名叫做Non-Heap(非堆)，目 的是与Java堆区分开来。 当方法区无法满足内存分配需求时，将抛出OutOfMemoryError异常。

不断创建大量的类，导致类信息过多等。比如使用框架或者对代码进行修改的时候，不会对原来的类进行直接修改，而是对类进行增强，增强的类越多，就会需要更大的方法区来保存动态生成的class从而造成方法区溢出。

  1. 方法区在JDK 8中就是Metaspace，在JDK6或7中就是Perm Space
  2. Run-Time Constant Pool Class文件中除了有类的版本、字段、方法、接口等描述信息外，还有一项信息就是常量池，用于存放编译时期生成的各种字面量和符号引用，这部分内容将在类加载后进入方法区的运行时常量池中存放。

常量池和运行时常量池每个类都有。

常量池是存在于编译好的字节码文件的，是静态的。

运行时常量池是在运行时加载类后将字节码的静态内容加载到内存，并在需要的时候解析。

方法区还存放一个方法表，简单说就是符号对应着方法的真正入口，

Heap(堆)

Java堆是Java虚拟机所管理内存中最大的一块，在虚拟机启动时创建，被所有线程共享。

Java对象实例以及数组都在堆上分配。

虚拟机栈

虚拟机栈是一个线程执行的区域，保存着一个线程中方法的调用状态。

换句话说，一个Java线程的运行状态，由一个虚拟机栈来保存，所以虚拟机栈肯定是线程私有的，独有的，随着线程的创建而创建。

每一个被线程执行的方法，为该栈中的栈帧，即每个方法对应一个栈帧。 调用一个方法，就会向栈中压入一个栈帧；一个方法调用完成，就会把该栈帧从栈中弹出。

The pc Register(程序计数器)

我们都知道一个JVM进程中有多个线程在执行，而线程中的内容是否能够拥有执行权，是根据CPU调度来的。假如线程A正在执行到某个地方，突然失去了CPU的执行权，切换到线程B了，然后当线程A再获得CPU执行权的时候，怎么能继续执行呢？这就是需要在线程中维护一个变量，记录线程执行到的位置。

每条线程需要有一个独立的程序计数器(线程私有)

程序计数器占用的内存空间很小，由于Java虚拟机的多线程是通过线程轮流切换，并分配处理器执行时间的方式来实现的，在任意时刻，一个处理器只会执行一条线程中的指令。因此，为了线程切换后能够恢复到正确的执行位置。

如果线程正在执行Java方法，则计数器记录的是正在执行的虚拟机字节码指令的地址；

如果正在执行的是Native方法，则这个计数器为空。

Native Method Stacks(本地方法栈)

如果当前线程执行的方法是Native类型的，这些方法就会在本地方法栈中执行。

本地方法栈也是每个线程独有的。

理解虚拟机栈和栈帧

  • 每个栈帧对应一个被调用的方法，可以理解为一个方法的运行空间。

每个栈帧中包括局部变量表、操作数栈、指向运行时常量池的引用、方法返回地址和附加信息。

  1. 局部变量表:方法中定义的局部变量以及方法的参数存放在这张表中局部变量表中的变量不可直接使用，如需要使用的话，必须通过相关指令将其加载至操作数栈中作为操作数使用。
  2. 操作数栈:以压栈和出栈的方式存储操作数的（也是一个栈结构）
  3. 动态链接:每个栈帧都包含一个指向运行时常量池中该栈帧所属方法的引用，持有这个引用是为了支持方法调用过程中的动态连接(Dynamic Linking)。
  4. 方法返回地址:当一个方法开始执行后,只有两种方式可以退出，一种是遇到方法返回的字节码指令；一种是遇见异常，并且这个异常没有在方法体内得到处理。

引用问题

如果在栈帧中有一个变量，类型为引用类型，比如Object obj=new Object()，这时候就是典型的栈中元素指向堆中的对象。

方法区中会存放静态变量，常量等数据。如果是下面这种情况，就是典型的方法区中元素指向堆中的对象。

方法区中会包含类的信息，堆中会有对象，那怎么知道对象是哪个类创建的呢？

Java对象内存布局

一个Java对象在内存中包括3个部分：对象头、实例数据和对齐填充

堆内存布局

一块是非堆区，一块是堆区。堆区分为两大块，一个是Old区，一个是Young区。Young区分为两大块，一个是Survivor区（S0+S1），一块是Eden区。Eden:S0:S1=8:1:1 S0和S1一样大，也可以叫From和To。

  • 对象创建所在区域

一般情况下，新创建的对象都会被分配到Eden区，一些特殊的大的对象会直接分配到Old区。

  • 对象的回收

比如有对象A，B，C等创建在Eden区，但是Eden区的内存空间肯定有限，比如有100M，假如已经使用了 100M或者达到一个设定的临界值，这时候就需要对Eden内存空间进行清理，即垃圾收集(Garbage Collect)， 这样的GC我们称之为Minor GC，Minor GC指得是Young区的GC。 经过GC之后，有些对象就会被清理掉，有些对象可能还存活着，对于存活着的对象需要将其复制到Survivor区，然后再清空Eden区中的这些对象。

  1. Minor GC:新生代
  2. Major GC:老年代
  3. Full GC:新生代+老年代

Survivor区详解

由图解可以看出，Survivor区分为两块S0和S1，也可以叫做From和To。

在同一个时间点上，S0和S1只能有一个区有数据，另外一个是空的。

接着上面的GC来说，比如一开始只有Eden区和From中有对象，To 中是空的。 此时进行一次GC操作，From区中对象的年龄就会+1，我们知道Eden区中所有存活的对象会被复制到To 区， From区中还能存活的对象会有两个去处。

若对象年龄达到之前设置好的年龄阈值，此时对象会被移动到Old区，如果Eden区和From区没有达到阈值的对象会被复制到To区。此时Eden区和From区已经被清空(被GC的对象肯定没了，没有被GC的对象都有了各自的去处)。 这时候From和To交换角色，之前的From变成了To，之前的To变成了From。

也就是说无论如何都要保证名为To的Survivor区域是空的。 Minor GC会一直重复这样的过程，直到To区被填满，然后会将所有对象复制到老年代中。

Old区详解

从上面的分析可以看出，一般Old区都是年龄比较大的对象，或者相对超过了某个阈值的对象。 在Old区也会有GC的操作，Old区的GC我们称作为Major GC。

对象的理解

我是一个普通的Java对象,我出生在Eden区,在Eden区我还看到和我长的很像的小兄弟,我们在Eden区中玩了挺长时间。有 一天Eden区中的人实在是太多了,我就被迫去了Survivor区的“From”区,自从去了Survivor区,我就开始漂了,有时候在 Survivor的“From”区,有时候在Survivor的“To”区,居无定所。直到我18岁的时候,爸爸说我成人了,该去社会上闯闯 了。 于是我就去了年老代那边,年老代里,人很多,并且年龄都挺大的,我在这里也认识了很多人。在年老代里,我生活了20年(每次GC加一岁),然后被回收。

  • 为什么需要 service 区

如果没有Survivor,Eden区每进行一次Minor GC,并且没有年龄限制的话，存活的对象就会被送到老年代。 这样一来，老年代很快被填满,触发Major GC(因为Major GC一般伴随着Minor GC,也可以看做触发了Full GC)。 老年代的内存空间远大于新生代,进行一次Full GC消耗的时间比Minor GC长得多。 执行时间长有什么坏处?频发的Full GC消耗的时间很长,会影响大型程序的执行和响应速度。

可能你会说，那就对老年代的空间进行增加或者较少咯。 假如增加老年代空间，更多存活对象才能填满老年代。虽然降低Full GC频率，但是随着老年代空间加大,一旦发生Full GC,执行所需要的时间更长。 假如减少老年代空间，虽然Full GC所需时间减少，但是老年代很快被存活对象填满,Full GC频率增加。

所以Survivor的存在意义,就是减少被送到老年代的对象,进而减少Full GC的发生,Survivor的预筛选保证,只有经历16 次Minor GC还能在新生代中存活的对象,才会被送到老年代。

  • 为什么需要两个Survivor区？

最大的好处就是解决了碎片化。也就是说为什么一个Survivor区不行?第一部分中,我们知道了必须设置Survivor区。假设现在只有一个Survivor区,我们来模拟一下流程: 刚刚新建的对象在Eden中,一旦Eden满了,触发一次Minor GC,Eden中的存活对象就会被移动到Survivor区。

这样继续循环下去,下一次Eden满了的时候,问题来了,此时进行Minor GC,Eden和Survivor各有一些存活对象,如果此时把Eden区的 存活对象硬放到Survivor区,很明显这两部分对象所占有的内存是不连续的,也就导致了内存碎片化。

永远有一个Survivor space是空的,另一个非空的Survivor space无碎片

  • 新生代中Eden:S1:S2为什么是8:1:1？

新生代中的可用内存：复制算法用来担保的内存为9：1

可用内存中Eden：S1区为8：1

即新生代中Eden:S1:S2 = 8：1：1

avatar
文章
阅读
粉丝