JVM（待续）

JVM

JVM的概述

1.JVM的位置

2.JVM的体系结构

类加载器（ClassLoader）

1.类对象的生命周期

类的加载指的是将类的.class文件中的二进制数据读入到内存中，将其放在运行时数据区的方法区内，然后在堆区创建一个java.lang.Class对象，用来封装类在方法区内的数据结构。类的加载的最终产品是位于堆区中的 Class对象， Class对象封装了类在方法区内的数据结构，并且向Java程序员提供了访问方法区内的数据结构的接口

以下几个阶段并被同步，这些阶段通常都是互相交叉地混合进行的，通常在一个阶段执行的过程中调用或激活另一个阶段，所以它们的总体流程按开始时间升序排列

1.加载

• 通过一个类的全限定名来获取其定义的二进制字节流
• 将这个字节流所代表的静态存储结构（不要和静态成员变量混淆）转化为方法区的运行时数据结构
• 在Java堆中生成一个代表这个类的 java.lang.Class对象，作为对方法区中这些数据的访问入口==（受限于实力，这个只是第一版，暂且还不是很清楚Class对象在堆还是方法区，我的认知是在堆，主要是知乎大佬都这么说，R大nb，等强一点再去看源码好了，毕竟现在都是听别人说的）==
• JDK7以上版本，静态域存储于定义类型的Class对象中，Class对象如同堆中其他对象一样，存在于GC堆中

2.连接

1. 验证：确保被加载类的正确性

   • 文件格式验证，验证字节流是否为Class文件格式的规范
   • 元数据验证，对字节码描述的信息进行语义分析
   • 字节码验证，确保程序语义合法符合逻辑
   • 符号饮用验证，确保解析动作正确执行

2. 准备：被类静态变量分配内存，并初始化为默认值

   • public static final int value=3;在初始化时会被赋值为3

3. 解析：符号引用转化为直接引用（逻辑地址转化为内存地址）

   • 符号引用在Class文件中它以CONSTANT_Class_info、CONSTANT_Fieldref_info、CONSTANT_Methodref_info等类型的常量出现

   • 在编译时java类并不知道所引用类的实际地址，因此只能使用符号引用替代，目的是无歧义的定位到目标

   • 直接引用则是能定位到目标的指针，偏移量或句柄

   • 参考文献：符号引用和常量引用

3.初始化

对类变量初始化

只有当对类的主动使用的时候才会导致类的初始化，总共有6种，之前在《注解与反射》时讲过，不重复

初始化步骤：

1. 假如这个类还没有被加载和连接，则程序先加载并连接该类（由此可见类加载属于懒加载和懒连接）
2. 假如该类的直接父类还没有被初始化，则先初始化其直接父类
3. 假如类中有初始化语句，则系统依次执行这些初始化语句

4.结束生命周期

• 执行了 System.exit()方法
• 程序正常执行结束
• 程序在执行过程中遇到了异常或错误而异常终止
• 由于操作系统出现错误而导致Java虚拟机进程终止

2.类加载器

加载机制

• 全盘负责，当一个类加载器负责加载某个Class时，该Class所依赖的和引用的其他Class也将由该类加载器负责载入，除非显示使用另外一个类加载器来载入
• 父类委托，先让父类加载器试图加载该类，只有在父类加载器无法加载该类时才尝试从自己的类路径中加载该类
• 缓存机制，缓存机制将会保证所有加载过的Class都会被缓存，当程序中需要使用某个Class时，类加载器先从缓存区寻找该Class，只有缓存区不存在，系统才会读取该类对应的二进制数据，并将其转换成Class对象，存入缓存区。这就是为什么修改了Class后，必须重启JVM，程序的修改才会生效

3.类的加载

类加载有3种方式

1. 由 new 关键字创建一个类的实例
2. 调用 Class.forName() 方法
3. 调用某个 ClassLoader 实例的 loadClass() 方法

public class TestDemo1 {
    public static void main(String[] args) throws ClassNotFoundException {
        ClassLoader loader = TestDemo1.class.getClassLoader();
        loader.loadClass("com.hznu.ch.classloader.Test");//不会被执行静态块

        Class c1 = Class.forName("com.hznu.ch.classloader.Test");//会被执行静态块
    }
}

class Test {
    public static int i;

    static {
        System.out.println("被执行！！！！");
    }
}

4.双亲委派机制

工作流程

如果一个类加载器收到了类加载的请求，它首先不会自己去尝试加载这个类，而是把请求委托给父加载器去完成，依次向上，因此，所有的类加载请求最终都应该被传递到顶层的启动类加载器中，只有当父加载器在它的搜索范围中没有找到所需的类时，即无法完成该加载，子加载器才会尝试自己去加载该类

图解

源码

public Class<?> loadClass(String name) throws ClassNotFoundException {
        return loadClass(name, false);
}
protected Class<?> loadClass(String name, boolean resolve)
        throws ClassNotFoundException
    {
        synchronized (getClassLoadingLock(name)) {
            // First, check if the class has already been loaded
          	// 判断是否被缓存
            Class<?> c = findLoadedClass(name);
            if (c == null) {
                long t0 = System.nanoTime();
                try {
                  	// 如果存在父类加载器，就委托给父类加载器
                    if (parent != null) {
                        c = parent.loadClass(name, false);
                    } else {
                       	// 如果是BootStrap加载器，就调用本地方法，调用C++的方法
                        c = findBootstrapClassOrNull(name);
                    }
                } catch (ClassNotFoundException e) {
                    // ClassNotFoundException thrown if class not found
                    // from the non-null parent class loader
                }

              	// 父类加载失败，尝试自己加载
                if (c == null) {
                    // If still not found, then invoke findClass in order
                    // to find the class.
                    long t1 = System.nanoTime();
                    c = findClass(name);// 这个方法会被每个加载器类重写

                    // this is the defining class loader; record the stats
                    sun.misc.PerfCounter.getParentDelegationTime().addTime(t1 - t0);
                    sun.misc.PerfCounter.getFindClassTime().addElapsedTimeFrom(t1);
                    sun.misc.PerfCounter.getFindClasses().increment();
                }
            }
            if (resolve) {
                resolveClass(c);
            }
            return c;
        }
}

好处

• 系统类防止内存中出现多份同样的字节码
• 保证Java程序安全稳定运行，不会被自定义类注入

5.一点关于java类加载器的理解

之前一直不是很明白java作为半动态语言的特性，今天好像突然有所感悟，拿c++举例子好了，如果我们在网络上传输信息，作为客户端我希望c++能new一个对象出来，并且只提供了字节码（类似于java的.class的东西），对于这个要求，我自认为c++很难完成，但反观java，你给我字节码，那我完全可以通过加载器去反射出一个类对象来啊，并就这些在运行时调用这个字节码对应的类的一些方法和属性。这仅是我的一些个人理解，可能有偏差，望大佬纠正…

沙箱安全机制

1.什么是沙箱

沙箱是一个限制程序运行的环境。沙箱机制就是将 Java 代码限定在虚拟机(JVM)特定的运行范围中，并且严格限制代码对本地系统资源访问，通过这样的措施来保证对代码的有效隔离，防止对本地系统造成破坏。沙箱主要限制系统资源访问，那系统资源包括什么？——CPU、内存、文件系统、网络。不同级别的沙箱对这些资源访问的限制也可以不一样

2.JDK安全模型

• jdk1.0

• jdk1.1

• Jdk1.2

• Jdk1.6

沙箱的基本组成

• 字节码校验器
• 类装载器
• 存取控制器
• 安全管理器
• 安全软件包

Native

private native void start0();

带有native关键字的，说明java作用范围达不到，会去调用本地底层C语言的库

调用native的基本流程：

1. 进入本地方法栈
   • 本地方法栈用于登记native方法
2. 调用本地方法接口——JNI
   • JNI作用：扩展java的使用，融合不同的语言为java所用，最初是为了使用C/C++
3. 通过本地方法接口调用本地方法库中的方法

PC寄存器

程序计数器（Program Counter Register）是一块较小的内存空间，它的作用可以看做是当前线程所执行的字节码的行号指示器。在虚拟机的概念模型里（仅是概念模型，各种虚拟机可能会通过一些更高效的方式去实现），字节码解释器工作时就是通过改变这个计数器的值来选取下一条需要执行的字节码指令，分支、循环、跳转、异常处理、线程恢复等基础功能都需要依赖这个计数器来完成

简单来说，每一个线程都有一个PC寄存器，就是一个指针，指向下一条指令

方法区（Method Aear）

别名：Non-Heap（非堆）

此区域属于共享区域，静态变量（还不确定），常量，类信息（构造方法，接口定义等，不包括Class对象），运行时常量池存在方法区中，但是实例变量存在堆内存中，与方法区无关

三种JVM

1. Sun公司的HotSpot 是目前使用范围最广的Java虚拟机

2. BEA公司的JRockit（原来的 Bea JRockit）电脑软件，系列产品是一个全面的Java运行时解决方案组合

3. IBM公司的J9 VM 是一个高性能的企业级 Java 虚拟机

栈（Stack）

对栈来说，不存在垃圾回收问题，因为栈调用完就扔掉，不会存在长时间停留的内存块

1.java栈

线程私有，生命周期与线程相同。每个方法被执行的时候都会同时创建一个栈帧用于存储局部变量表，操作栈，动态链接，方法出口等信息。每一个方法被调用直至执行完成的过程，就对应着一个栈帧在虚拟机栈中从入栈到出栈的过程

局部变量表存放了编译期可知的各种基本数据类型（boolean、byte、char、short、int、float、long、double），对象引用和returnAddress类型（指向了一条字节码指令的地址）

局部变量表所需的内存空间在编译期间完成分配，当进入一个方法时，这个方法需要在帧中分配多大的局部变量空间是完全确定的，在方法运行期间不会改变局部变量表的大小，long，double占2个局部变量空间，其余占1个

两种ERROR：

• 固定长度的虚拟机栈——StackOverflowError——栈深度大于虚拟机所允许的深度
• 动态扩展——OutOfMemoryError——扩展时无法申请到足够的内存

2.本地方法栈（Native Method Stack）

本地方法栈为JVM调用native方法服务

堆（Heap）

1.图示（JDK1.8以后）

2.新生区

• 伊甸园区：所有的对象都是在伊甸园区new出来的
• 幸存者（0，1）区

3.老年区

经过多次淘汰以后的数据存放的位置

4.永久区（元空间）

这个区域常驻内存，用来存放JDK自身携带的Class对象,Interface元数据，存储的是java运行时的一些环境，这个区域不存在垃圾回收

• jdk1.6之前：常量池在方法区
• jdk1.7：永久代慢慢退化，去永久代，常量池在堆中
• jdk1.8之后：无永久代，常量池在元空间

元空间和方法区的关系：元空间是对方法区的具体实现，方法区是JVM规范的抽象定义

堆内存调优

1.参数

• -Xms设置堆的最小空间大小。
• -Xmx设置堆的最大空间大小。
• -XX:NewSize设置新生代最小空间大小。
• -XX:MaxNewSize设置新生代最大空间大小。
• -XX:PermSize设置永久代最小空间大小。
• -XX:MaxPermSize设置永久代最大空间大小。
• -Xss设置每个线程的堆栈大小。

2.实践

public class Main {
    public static void main(String[] args) {
        long maxMemory = Runtime.getRuntime().maxMemory();
        long totalMemory = Runtime.getRuntime().totalMemory();
        System.out.println("试图使用的最大内存=" + maxMemory / (double) 1024 / 1024 + "MB");
        System.out.println("jvm初始化总内存=" + totalMemory / (double) 1024 / 1024 + "MB");
    }
}
//-Xms1024m -Xmx1024m -XX:+PrintGCDetails
/* （305664K + 699392K）/ 1024 = 981.5MB，正好是jvm试图使用的的、最大内存 ，从这里我们可以看出元空间的内存是本地内存，并不是jvm中的内存


试图使用的最大内存=981.5MB
jvm初始化总内存=981.5MB
Heap
 PSYoungGen      total 305664K, used 15729K [0x00000007aab00000, 0x00000007c0000000, 0x00000007c0000000)
  eden space 262144K, 6% used [0x00000007aab00000,0x00000007aba5c420,0x00000007bab00000)
  from space 43520K, 0% used [0x00000007bd580000,0x00000007bd580000,0x00000007c0000000)
  to   space 43520K, 0% used [0x00000007bab00000,0x00000007bab00000,0x00000007bd580000)
 ParOldGen       total 699392K, used 0K [0x0000000780000000, 0x00000007aab00000, 0x00000007aab00000)
  object space 699392K, 0% used [0x0000000780000000,0x0000000780000000,0x00000007aab00000)
 Metaspace       used 3126K, capacity 4496K, committed 4864K, reserved 1056768K
  class space    used 343K, capacity 388K, committed 512K, reserved 1048576K
*/

public class Hello {
    public static void main(String[] args) {
        String str = "abc";
        while (true)
            str += new Random().nextInt(888888) + new Random().nextInt(99999999);
    }
}
//-Xms2m -Xmx2m -XX:+PrintGCDetails
// 从下面这条可以看出来，重GC也无法进行垃圾回收了，所以就抛出了OOM
//[Full GC (Allocation Failure) [PSYoungGen: 372K->372K(1024K)] [ParOldGen: 446K->446K(512K)] 818K->818K(1536K), [Metaspace: 3593K->3593K(1056768K)], 0.0075471 secs] [Times: user=0.01 sys=0.00, real=0.01 secs] 

GC（garbage collection）算法

jvm进行GC时，并不是对三个区域统一回收。大部分时候，回收的都是新生代（伊甸园区&幸存者0|1区）

GC两种类型：轻GC，重GC

1.对象存活判断

引用计数法

通过对对象引用的个数来判断是否存活，类似于C++中的智能指针，计数器本身会有开销，且java中类较多，所以引用计数法不常用甚至基本不用

可达性分析

从GC Roots开始向下搜索，搜索所走过的路径称为引用链。当一个对象到GC Roots没有任何引用链相连时，则证明此对象是不可用的，即不可达对象

在Java语言中，GC Roots包括：

• 虚拟机栈中引用的对象。
• 方法区中类静态属性实体引用的对象。
• 方法区中常量引用的对象。
• 本地方法栈中JNI引用的对象。

2.垃圾收集算法

标记-清除算法

空间效率：标记和清除的效率都不高

空间占用率：标记清除之后会产生大量不连续内存碎片，分配较大内存对象的时候无法得到足够的连续内存而不得不提前触发一次GC

复制算法

空间利用率：内存缩小为原来的一半，持续复制长生存期的对象则导致效率降低，但不用考虑内存碎片的问题

标记-压缩算法

比标记-清除多了一步压缩的操作

分代收集算法

“分代收集”（Generational Collection）算法，把Java堆分为新生代和老年代，这样就可以根据各个年代的特点采用最适当的收集算法。在新生代中，每次垃圾收集时都发现有大批对象死去，只有少量存活，那就选用复制算法，只需要付出少量存活对象的复制成本就可以完成收集。而老年代中因为对象存活率高、没有额外空间对它进行分配担保，就必须使用“标记-清理”或“标记-整理”算法来进行回收

运行时常量池

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

思考（对于String的扩展）

之前以为知道了String的底层，现在才发现是一点也不知道的说，进入正题

创建String的方法：

• 直接写双引号常量来创建：String str=“123”;

• new String()对象

• 两个双引号字符串相加

和直接写双引号常量来创建String一样的图，就是判断条件变成了连接以后的字符串以及相加的两个字符串

• 两个new String()的字符串相加

和new String()对象一样，判断条件改成两个对象的字面量，不包括连接后的String对象对应的字面量

• 双引号字面量与new String()相加

首先创建两个对象，一个是new String的对象（堆中），一个是相加后的对象(堆中)

然后判断双引号字符串字面量和new String的字面量在常量池是否存在

• 双引号字符串常量和字符串变量相加

首先创建一个对象，是相加后的结果对象(存放堆中，不会找常量池)

然后判断双引号字符串字面量在常量池是否存在

intern()的分析

总结

出现字面量的都需要去查看一下常量池，以及字面量相加的结果也需要去查看常量池

判断逻辑也都是查看字符串常量是否存在，存在返回引用地址或常量值地址，不存在就创建并返回常量值的地址

参考文献

一文弄懂String常量池，String常见面试题，以及intern()方法

Class类文件结构

类型	名称	数量
u4	magic	1
u2	minor_version	1
u2	major_version	1
u2	constant_pool_count	1
cp_info	constant_pool	constant_pool_count - 1
u2	access_flags	1
u2	this_class	1
u2	super_class	1
u2	interfaces_count	1
u2	interfaces	interfaces_count
u2	fields_count	1
field_info	fields	fields_count
u2	methods_count	1
method_info	methods	methods_count
u2	attribute_count	1
attribute_info	attributes	attributes_count

1.魔数和Class文件版本

前四个字节：魔数，魔数的唯一作用是确定这个文件是否为虚拟机接收的Class文件

5，6字节：次版本号

7，8字节：主版本号，可以被对应版本号及以上的JDK执行