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());
    }
}

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

546718765
167185492
592179046
jdk.internal.loader.ClassLoaders$AppClassLoader@2437c6dc
jdk.internal.loader.ClassLoaders$PlatformClassLoader@737996a0
null

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

沙箱安全机制

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

Native 和方法区

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

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

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

栈、队列、堆

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

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

队列Queue FIFO先进先出

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

-Xms1024m -Xmx1024m -XX:+PrintGCDetails

三种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)

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：