深入理解Java虚拟机

JVM内存模型

.class文件在进入类加载器后，进行加载-连接-初始化

类加载器

public class User {
    private String name;
    private Integer age;

    public static void main(String[] args) {
        User user = new User();
        User user1 = new User();
        User user2 = new User();
        System.out.println(user.hashCode());
        System.out.println(user1.hashCode());
        System.out.println(user2.hashCode());

        Class<? extends User> aClass = user.getClass();
        ClassLoader classLoader = aClass.getClassLoader();
        System.out.println(classLoader);
        System.out.println(classLoader.getParent());
        System.out.println(classLoader.getParent().getParent());
    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

结果如下，可见，一个类的多个对象的hashCode是不相同的，这个类的类加载器是应用程序加载器，再往上是扩展类加载器(改名为平台类加载器 jdk11)，在向上是null，这个就是根加载器，因为使用c++写的
向上委派查询，如果上层查到的话就返回，没有的情况下就会，抛出异常，向下查找紫子类加载器。都没有的抛出异常 class not found exception

546718765
167185492
592179046
jdk.internal.loader.ClassLoaders$AppClassLoader@2437c6dc
jdk.internal.loader.ClassLoaders$PlatformClassLoader@737996a0
null
1
2
3
4
5
6

目的是为了安全，防止人为建包的破坏

沙箱安全机制

java安全的核心就是java沙箱，沙箱就是一个限制程序运行的环境，将java代码限定到指定的虚拟机的特定运行范围中，严格控制它对资源的访问，确保对代码的有效隔离，防止恶意代码对本地系统的破坏
字节码校验：并不是所有的类都会经过字节码校验，核心类String等就经过了安全的校验

Native 和 方法区

    public static void main(String[] args) {
        new Thread(()->{}).start();
    }
    
	private native void start0();
1
2
3
4
5

native是c++写的，一旦使用这个关键字，就会进入本地方法栈，会找JNI接口，java本地的接口作用，调用本地方法库，扩展功能，融合c，c++等语言

方法区属于共享的区域，存储静态变量，常量，类信息（构造方法，接口定义），运行时的常量池存在在堆内存中。但是实例变量存在堆内存中，和方法区无关

栈、队列、堆

栈Stack FIFO先进后出，主管程序的运行，生命周期和线程同步，线程结束，栈内存就释放，对于栈，不存在垃圾回收

存放的数据：8大基本数据类型 + 对象的引用 + 实例的方法

队列Queue FIFO先进先出

堆Heap，是最高效的优先级队列的数据结构。堆通常是一个可以被看做一棵完全二叉树的数组对象
元空间（非堆），逻辑上存在，物理上不存在

-Xms1024m -Xmx1024m -XX:+PrintGCDetails
1

三种JVM

• sun HotSpot

C:\Users\86199>java -version
java version "11.0.16.1" 2022-08-18 LTS
Java(TM) SE Runtime Environment 18.9 (build 11.0.16.1+1-LTS-1)
Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11.0.16.1+1-LTS-1, mixed mode)
1
2
3
4

• JRocket 世界上最快的JVM，财务办公方向
• J9VM IBM的JDK

垃圾回收

判断垃圾

引用计数法
可达性分析法
回收方法区

垃圾回收算法

• 标记清除法

标记需要回收的对象，标记完成之后，统一回收所有被标记的对象，也可以反过来，先标记存活的对象，统一回收未标记的对象
缺点：效率不稳定，内存空间碎片化

• 标记整理法

让所有存活的对象移动到一起，然后清除边界以外的内存

• 标记复制法

解决了标记清除在回收大量对象的时候执行效率低下的问题，产生了大量的空间复制的开销

一次完整的GC

新创建的对象一般会被分配在新生代中，常用的新生代的垃圾回收器是 ParNew 垃圾回收器，它按照 8:1:1 将新生代分成 Eden 区，以及两个 Survivor 区。某一时刻，我们创建的对象将 Eden 区全部挤满，这个对象就是挤满新生代的最后一个对象。此时，Minor GC 就触发了。

在正式 Minor GC 前，JVM 会先检查新生代中对象，是比老年代中剩余空间大还是小。为什么要做这样的检查呢？原因很简单，假如 Minor GC 之后 Survivor 区放不下剩余对象，这些对象就要进入到老年代，所以要提前检查老年代是不是够用。这样就有两种情况：

• 老年代剩余空间大于新生代中的对象大小，那就直接Minor GC，GC完survivor不够放，老年代也绝对够放；
• 老年代剩余空间小于新生代中的对象大小，这个时候就要查看是否启用了“老年代空间分配担保规则”，具体来说就是看 -XX:-HandlePromotionFailure 参数是否设置了。
  老年代空间分配担保规则是这样的，如果老年代中剩余空间大小，大于历次 Minor GC 之后剩余对象的大小，那就允许进行 Minor GC。因为从概率上来说，以前的放的下，这次的也应该放的下。那就有两种情况：
  老年代中剩余空间大小，大于历次Minor GC之后剩余对象的大小，进行 Minor GC；
  老年代中剩余空间大小，小于历次Minor GC之后剩余对象的大小，进行Full GC，把老年代空出来再检查。
  开启老年代空间分配担保规则只能说是大概率上来说，Minor GC 剩余后的对象够放到老年代，所以当然也会有万一，Minor GC 后会有这样三种情况：
• Minor GC 之后的对象足够放到 Survivor 区，皆大欢喜，GC 结束；
• Minor GC 之后的对象不够放到 Survivor 区，接着进入到老年代，老年代能放下，那也可以，GC 结束；
• Minor GC 之后的对象不够放到 Survivor 区，老年代也放不下，那就只能 Full GC。

前面都是成功 GC 的例子，还有 3 中情况，会导致 GC 失败，报 OOM：

• 紧接上一节 Full GC 之后，老年代任然放不下剩余对象，就只能 OOM；
• 未开启老年代分配担保机制，且一次 Full GC 后，老年代任然放不下剩余对象，也只能 OOM；
• 开启老年代分配担保机制，但是担保不通过，一次 Full GC 后，老年代任然放不下剩余对象，也是能 OOM。

Full GC会“Stop The World”，即在GC期间全程暂停用户的应用程序。