JVM初探

1、JVM的位置

图片说明

2、JVM体系结构

图片说明

本地方法接口：JNI（Java Native Interface)

3、类加载器

作用：加载class文件（栈存的是引用，真正的对象在堆里）

图片说明

四种加载器
- 1、虚拟机自带的加载器
- 2、启动类（根）加载器【BOOT】
- 3、扩展类加载器【EXT】
- 4、应用程序加载器【APP】
- 注：从4到1进行类的加载请求，1-4的类的加载执行
  
  根加载器加载rt.jar,扩展类加载器加载/jre/lib/ext目录下的jar,应用程序加载器加载classpath路径下的jar

3.1双亲委派机制

目的：安全，向上委派，再往下委派。APP-》EXT-》BOOT【最终执行】
1、类加载器收到类加载的请求
2、将这个请求向上委托给父级类加载器去完成，一直向上委托，直到启动类加载器
3、启动类加载器检查是否能够加载当前这个类，能加载就结束，使用当前的加载器，否则抛出异常委托给子级加载器进行加载。

4、重复步骤3，直到加载完成或者抛出异常ClassNotFound

package com.draco.parents;

/**
* 双亲委派机制
*/
public class Car {
 public static void main(String[] args) {
     Car car1 = new Car();
     Car car2 = new Car();
     Car car3 = new Car();

     //不同的实例
     System.out.println("car1 hashCode="+car1.hashCode());
     System.out.println("car2 hashCode="+car2.hashCode());
     System.out.println("car3 hashCode="+car3.hashCode());

     //同一个类模版
     Class<? extends Car> aClass1 = car1.getClass();
     Class<? extends Car> aClass2 = car2.getClass();
     Class<? extends Car> aClass3 = car3.getClass();

     System.out.println("aClass1 hashCode="+aClass1.hashCode());
     System.out.println("aClass2 hashCode="+aClass2.hashCode());
     System.out.println("aClass3 hashCode="+aClass3.hashCode());

     //由于类模版都是一个，以下就选择一个进行测试
     ClassLoader classLoader = aClass1.getClassLoader();

     System.out.println(classLoader);  //AppClassLoader

     System.out.println(classLoader.getParent());  //ExtClassLoader  所在位置：\jre\lib\ext

     System.out.println(classLoader.getParent().getParent());  //null 1.不存在  2.java程序获取不到  所在位置：rt.jar

 }
}

运行测试结果

3.2面试问题

为什么需要双亲委派机制？（即优点）
1. 双亲委派机制使得类加载出现层级，父级类加载类记载过的类，子级类加载器不会重复加载，可以防止类的重复加载
2. 使得类的加载出现优先级，防止了核心API被篡改，提高了安全，所以越基础的类就会越上层的类加载器进行加载，反而一般自己写的类，就会在应用程序加载器直接加载。
如何打破双亲委派？（待进一步了解）
- 自定义类加载，重写loadClass方法
- 使用线程上下文类加载器

4、沙箱安全机制

java安全模型的核心就是Java沙箱（sandbox）

4.1什么是沙箱

沙箱是一个限制程序运行的环境。沙箱机制就是将Java代码限定在虚拟机（JVM）特定的运行范围中，并且严格限制代码对本地系统资源的访问，通过这样的措施来保证对代码的有效隔离，放置对本地系统造成破环。
沙箱主要限制系统资源访问，主要包括CPU，内存，文件系统，网络等。
不同级别的沙箱对这些资源访问的限制是不一样的。
所有Java程序运行都可以指定沙箱，可以定制安全策略。

4.2组成沙箱的基本组件

字节码校验器（bytecode verifier):确保Java类文件遵循Java语言规范（比如少了分号）。这样可以帮助Java程序实现内存保护。但不是所有的类文件都会经过字节码校验，比如核心类。
类装载器(class loader)：其中类装载器再3个方面对Java沙箱起作用
- 它防止恶意代码去干涉善意代码
- 它守护了被信任的类库边界
- 它将代码归入保护域，确定了代码可以进行哪些操作
虚拟机为不同的类加载器载入的类提供了不同的命名空间，命名空间由一系列唯一的名称组成，每一个被装载的类将有一个名字，这个命名空间是由Java虚拟机为每一个类装载其伟华的，他们互相之间甚至不可见。
类装载器采用的机制是==双亲委派模式==。

从最内层JVM自带类加载器开始加载，外层恶意同名类得不到加载从而无法使用；
由于严格通过包来区分了访问域，外层恶意的类通过内置代码也无法获得权限访问到内层类，破坏代码就自然无法生效。

存取控制器（access controller）：存取控制器可以控制核心API对操作系统的存取权限，而这个控制的策略设定，可以由用户指定。
安全管理器（security manager）：是核心API和操作系统之间的主要接口。实现权限控制，比存取控制器优先级高。
安全软件包（security package）：java.security下的类和扩展包下的类，允许用户为自己的应用增加新的安全特性，包括：
- 安全提供者
- 消息摘要
- 数字签名
- 加密
- 鉴别

5、Native

编写一个多线程启动类

public static void main(String[] args) {
 new Thread(() -> {},"Thread1").start();
}

点进去start方法

public synchronized void start() {

 if (threadStatus != 0)
     throw new IllegalThreadStateException();

 group.add(this);

 boolean started = false;
 try {
     start0(); // 调用了start0()方法
     started = true;
 } finally {
     try {
         if (!started) {
             group.threadStartFailed(this);
         }
     } catch (Throwable ignore) {

     }
 }
}
// 凡是带了native关键字的，就说明Java的作用范围达不到了，会去调用底层C语言的库
private native void start0(); //start0()方法的定义，这个方***调用底层C

Java在内存区域中专门开辟了一块标记区域——本地方法栈，用来登记native方法，凡是带了native关键字的，会进入到本地方法栈中，调用本地方法接口（JNI），在执行引擎（Execution Engine）执行的时候，加载本地方法库（Native Libraies）中的方法。

JNI的作用：扩展Java的使用，融合不同的编程语言为Java所用，不过最初是想融合C，C++的，因为Java诞生的时候，C，C++横行，想要立足的话就要有能调用C的程序
本地方法栈：具体做法是，在Native Method Stack中登记native方法，在执行引擎执行的时候加载Native Libraies【本地库】

6、PC寄存器

程序计数器：Program Counter Register

每个线程都有一个程序计数器，是线程私有的，就是一个指针，指向方法区中的方法字节码(用来存储指向一条指令的地址，也即将要执行的指令代码)，在执行引擎读取下一条指令, 是一个非常小的内存空间，几乎可以忽略不计

7、方法区

方法区：Method Area

方法区是被所有线程共享，所有字段和方法字节码，以及一些特殊方法，如构造函数，接口代码也在此定义，简单说，所有定义的方法的信息都保存在该区域，此区域属于共享区间；
静态变量、常量、类信息(构造方法、接口定义)、运行时的常量池存在方法区中，但是实例变量存在堆内存中，和方法区无关。简单的来说就是：==static、final、Class、常量池==

8、栈

栈：栈内存，主管程序的运行，生命周期和线程同步

线程结束，栈内存也就释放了，对于栈来说，不存在垃圾回收问题，一旦线程结束，栈就over了
8.1 栈里面存放什么

栈：8大基本类型+对象的引用+实例的方法

8.2 栈运行原理

栈帧
图片说明
栈满了：StackOverflowError

8.3 栈堆方法区的交互关系

图片说明

9、三种JVM

Sun公司 HotSpot Java HotSpot(TM) 64-Bit Server VM (build 25.121-b13, mixed mode)
BEA JRockit
IBM J9VM

10、堆

Heap,一个JVM只有一个堆内存，堆内存的大小是可以调节的

10.1 堆里面存放什么

类加载器读取了类文件后，一般会把什么东西放在堆中？ 类，方法，常量，变量，保存我们所有引用类型的真实对象

堆内存中还要细分为三个区域：

新生区（伊甸园区）young/new
养老区 old
永久区 perm

个人理解是堆中的方法是实例对象的方法，方法区中的方法是Class模板（xxx.class被加载后生成类似于xxx对象工厂）的方法，栈中的方法是正在被执行的方法

==GC垃圾回收，主要在伊甸园区和养老区==
图片说明

假设内存满了，OOM，堆内存不够！java.lang.OutOfMemoryError: Java heap space

package com.draco.heapOverflow;
import java.util.Random;

/**
 * 堆溢出
 */
public class HeapOver {
    public static void main(String[] args) {
        String name = "adfjkllkjfdsa";
        while(true){
            name += name + new Random().nextInt(888888888)+new Random().nextInt(999999999);
        }
    }
}

图片说明

在JDK8以后，永久存储区改了个名字叫：==元空间==

10.2 新生区

对象很大，直接在老年区生成

新生区：类诞生和成长的地方，甚至死亡；

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

真理：进过研究，99%的对象都是临时对象！

10.3 养老区

新生区没干掉，没杀死的来到了养老区~

10.4 永久区

这个区域是常驻内存的。用来存放JDK自身携带的Class对象，Interface元数据，存储的是Java运行时的一些环境或类信息，这个区域不存在垃圾回收！当关闭VM虚拟机就会释放这个区域的内存。

也会OOM：一个启动类加载了大量的第三方jar包；tomcat部署了太多的应用；大量动态生成的反射类等不断的被加载，直到内存满，就会出现OOM。

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

但是，元空间：逻辑上存在，物理上不存在
```
package snow.dong.javaVM;

public class TestVM {
 public static void main(String[] args) {
     //返回jvm试图使用的最大内存
     long max=Runtime.getRuntime().maxMemory();
     //返回jvm的初始化内存
     long total=Runtime.getRuntime().totalMemory();
     System.out.println("max="+max+"字节\t"+(max/(double)(1024*1024))+"MB");
     System.out.println("total="+max+"字节\t"+(total/(double)(1024*1024))+"MB");

     //默认情况下，试图分配的最大内存是电脑内存的1/4,而初始化内存是1/64
     //-Xms1024m -Xmx1024m -XX:PrintGCDetails
 }
}
```
运行结果：

简单计算：本机计算机内存7.9G=8089.6MB，7.9G/4=2022.4MB，7.9G/64=126.4MB（基本上符合上面的1/4,1/64比例）

当修改了VM选项后：-Xms1024m -Xmx1024m -XX:PrintGCDetails，输出结果：

简单计算：新生区：305664K != 262144K+43520K+43520K(到底为什么呢)；养老区：699392K
新生区+老年区=1,005,056k，除以1024后 = 981.5MB，等于jvm试图分配的最大内存，所以说元空间逻辑上存在，物理上不存在。
元空间使用的是计算机物理内存，不是jvm占用的内存*

10.5 出现OOM分析

尝试扩大堆内存去查看内存结果
-Xms1024m -Xmx1024m -XX:+PrintGCDetails
若不行，分析内存，看一下是哪个地方出现了问题（专业工具）
- 能够看到代码第几行出错：内存快照分析工具，MAT（eclipse），Jprofiler
- Dubug，一行行分析代码！（不现实）

一个具体案例代码说明出现java.lang.OutOfMemoryError：

package snow.dong.javaVM;
import java.util.Random;

public class TestOOM {
 public static void main(String[] args) {
     String str="simpleString";
     while(true){
         str+=str+new Random().nextInt(888888888)+new Random(99999999);
     }
 }
}

运行会出现Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
尝试改变虚拟机内存去查看内存结果 -Xms8m -Xmx8m -XX:+PrintGCDetails
运行结果如下：

[GC (Allocation Failure) [PSYoungGen: 1536K->488K(2048K)] 1536K->672K(7680K), 0.0020552 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
[GC (Allocation Failure) [PSYoungGen: 1770K->493K(2048K)] 1954K->904K(7680K), 0.0009501 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
[GC (Allocation Failure) [PSYoungGen: 1612K->408K(2048K)] 2023K->1736K(7680K), 0.0006020 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
[GC (Allocation Failure) [PSYoungGen: 1915K->440K(2048K)] 3243K->2859K(7680K), 0.0007314 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
[GC (Allocation Failure) [PSYoungGen: 1955K->344K(2048K)] 5829K->4945K(7680K), 0.0008610 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
[Full GC (Ergonomics) [PSYoungGen: 344K->0K(2048K)] [ParOldGen: 4601K->1332K(5632K)] 4945K->1332K(7680K), [Metaspace: 3261K->3261K(1056768K)], 0.0043807 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
[GC (Allocation Failure) [PSYoungGen: 815K->96K(2048K)] 3602K->2883K(7680K), 0.0004013 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
[GC (Allocation Failure) [PSYoungGen: 96K->64K(2048K)] 2883K->2851K(7680K), 0.0001948 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
[Full GC (Allocation Failure) [PSYoungGen: 64K->0K(2048K)] [ParOldGen: 2787K->2788K(5632K)] 2851K->2788K(7680K), [Metaspace: 3292K->3292K(1056768K)], 0.0047032 secs] [Times: user=0.02 sys=0.00, real=0.00 secs] 
[GC (Allocation Failure) [PSYoungGen: 0K->0K(2048K)] 2788K->2788K(7680K), 0.0003798 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
[Full GC (Allocation Failure) [PSYoungGen: 0K->0K(2048K)] [ParOldGen: 2788K->2768K(5632K)] 2788K->2768K(7680K), [Metaspace: 3292K->3292K(1056768K)], 0.0052979 secs] [Times: user=0.00 sys=0.00, real=0.01 secs] 
Heap
PSYoungGen      total 2048K, used 79K [0x00000000ffd80000, 0x0000000100000000, 0x0000000100000000)
eden space 1536K, 5% used [0x00000000ffd80000,0x00000000ffd93ea8,0x00000000fff00000)
from space 512K, 0% used [0x00000000fff80000,0x00000000fff80000,0x0000000100000000)
to   space 512K, 0% used [0x00000000fff00000,0x00000000fff00000,0x00000000fff80000)
ParOldGen       total 5632K, used 2768K [0x00000000ff800000, 0x00000000ffd80000, 0x00000000ffd80000)
object space 5632K, 49% used [0x00000000ff800000,0x00000000ffab43a8,0x00000000ffd80000)
Metaspace       used 3340K, capacity 4496K, committed 4864K, reserved 1056768K
class space    used 363K, capacity 388K, committed 512K, reserved 1048576K
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
 at java.util.Arrays.copyOf(Arrays.java:3332)
 at java.lang.AbstractStringBuilder.ensureCapacityInternal(AbstractStringBuilder.java:124)
 at java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:674)
 at java.lang.StringBuilder.append(StringBuilder.java:208)
 at snow.dong.javaVM.TestOOM.main(TestOOM.java:8)

10.6 使用工具来分析OOM原因

MAT，Jprofiler作用：
- 分析Dump内存文件，快速定位内存泄漏
- 获得堆中的数据
- 获得大的对象
- ......

代码展示栈溢出，然后用工具解析：

package snow.dong.javaVM;
import java.util.ArrayList;

public class TestOOM02 {
    byte[] arr=new byte[1*1024*1024];

    public static void main(String[] args) {
        ArrayList<TestOOM02> list=new ArrayList<>();
        int count=0;
        try{
            while(true){
                list.add(new TestOOM02());
                count++;
            }
        }catch (Error e){//注意这里是捕获Error不是Exception
            System.out.println("count="+count);
            e.printStackTrace();
        }
    }
}

设置VM options -Xms1m -Xmx8m -XX:+HeapDumpOnOutOfMemoryError后，再次运行，控制台输出：
图片说明

找到HPROF快照
图片说明
双击打开

10.7 VM options参数

-Xms 设置初始化内存分配大小，默认1/64
-Xmx 设置最大分配内存，默认1/4
-XX:+PrintGCDetails 打印GC垃圾回收信息
-XX:+HeapDumpOnOutOfMemoryError 生成oomDump文件
-Xms1m -Xmx8m -XX:+HeapDumpOnOutOfMemoryError
-Xms1024m -Xmx1024m -XX:+PrintGCDetails

11、GC垃圾回收

11.1 GC的作用区域

图片说明

JVM在进行GC时，并不是对这三个区域统一回收，大部分时候，回收都是新生区

新生区
幸存区（form to）【会交换的，不是一成不变的】
老年区
GC两种类型：轻GC（普通的GC），重GC（全局GC）

11.2 GC相关题目

JVM的内存模型和分区~详细到每个区放什么？
堆里面的分区有哪些？Eden，from，to，old，说说他们的特点~
GC的算法有哪些？标记清除法，标记整理/压缩法，复制算法，引用计数法，怎么用的？
轻GC和重GC分别在什么时候发生？

11.3 GC算法

判断对象是否存活：引用计数和可达性分析

引用计数法

图片说明

哪个对象的引用数为0，就会回收哪个对象

可达性分析

可达性分析：引用链法，查询对象从GCRoot-》虚拟机栈-》方法区静态方法-》方法区常量池-》本地栈JNI，若无引用则GC

复制算法

图片说明

一般新生代（伊甸园区、幸存区）会使用复制算法，生成新的to区

好处：没有内存的碎片
坏处：浪费了内存空间，多了一半空间永远是空to
复制算法最佳使用场景：对象存活度较低的时候，也就是新生区*
每次GC后都会将Eden中活着的对象移到幸存区：一旦Eden区被GC后，就会是空的！

标记清除

图片说明

缺点：两次扫描，严重浪费时间，会产生内存碎片
优点：不需要额外的空间

标记压缩（标记整理）

对于标记清除的再压缩
图片说明

但是又多了一个移动成本

标记清除整理算法

先标记清除几次，然后再压缩
参考老年区的收集算法CMS（Concurrent Mark Sweep），其中“Concurrent”并发是指垃圾收集的线程和用户执行的线程是可以同时执行的。

12 总结

内存效率：复制算法 > 标记清除算法 > 标记压缩算法（时间复杂度）
内存整齐度：复制算法 = 标记压缩算法 > 标记清除算法
内存利用率：标记压缩算法 = 标记清除算法 > 复制算法

思考：难道没有最优算法吗？

答案：没有，没有最好的算法，只有最合适的——>GC：分代收集算法

年轻代：

存活率低
复制算法

老年代：

区域大，存活率高
标记清除（内存碎片不是太多） + 标记压缩混合实现

13 JMM

13.1 什么是JMM

JMM: java Memory model

13.2 它是什么算法

作用：缓存一致性协议，用于定义数据读写的规则
JMM定义了线程工作内存和主内存之间的抽象关系，线程之间的共享内存存储在主内存中（Main Memory）中，每个线程都有一个私有的本地内存（local memory）

解决共享对象可见性的这个问题：voliate

13.3 它该如何学习？

JMM：抽象的概念，理论
voliate等等

资源来源：

JVM简单学习

JVM初探

1、JVM的位置

2、JVM体系结构

3、类加载器

3.1双亲委派机制

3.2面试问题

4、沙箱安全机制

4.1什么是沙箱

4.2组成沙箱的基本组件

5、Native

6、PC寄存器

7、方法区

8、栈

8.1 栈里面存放什么

8.2 栈运行原理

8.3 栈堆方法区的交互关系

9、三种JVM

10、堆

10.1 堆里面存放什么

10.2 新生区

10.3 养老区

10.4 永久区

10.5 出现OOM分析

10.6 使用工具来分析OOM原因

10.7 VM options参数

11、GC垃圾回收

11.1 GC的作用区域

11.2 GC相关题目

11.3 GC算法

引用计数法

可达性分析

复制算法

标记清除

标记压缩（标记整理）

标记清除整理算法

12 总结

13 JMM

13.1 什么是JMM

13.2 它是什么算法

13.3 它该如何学习？