【JVM基础】JVM入门基础

JVM的位置

应用程序（Java应用程序）在JRE上运行（JRE包含JVM），JRE在操作系统（Windows、Mac）上运行，操作系统在硬件体系（Intel、Spac…）上运行。

三种 JVM

• Sun公司：HotSpot 用的最多（我们使用）
• BEA：JRockit
• IBM：J9VM

JVM体系结构

JVM 调优：99%都是在方法区和堆，大部分时间调堆。 JNI（Java Native Interface）：本地方法接口

类加载器

作用：加载class文件
例如：new Student();（具体实例在堆里，引用变量名放栈里）

• 虚拟机自带的加载器
• 启动类（根）加载器
• 扩展类加载器
• 应用程序加载器

双亲委派机制

概念

当某个类加载器需要加载某个.class文件时，它首先把这个任务委托给他的上级类加载器，递归这个操作，如果上级的类加载器没有加载，自己才会去加载这个类。

例子

当一个 Hello.class 这样的文件要被加载时。
不考虑我们自定义类加载器，首先会在 AppClassLoader 中检查是否加载过，如果有那就无需再加载了。如果没有，那么会拿到父加载器，然后调用父加载器的 loadClass 方法。
父类中同理也会先检查自己是否已经加载过，如果没有再往上。注意这个类似递归的过程，直到到达 Bootstrap classLoader 之前，都是在检查是否加载过，并不会选择自己去加载。
直到 BootstrapClassLoader，已经没有父加载器了，这时候开始考虑自己是否能加载了，如果自己无法加载，会下沉到子加载器去加载，一直到最底层，如果没有任何加载器能加载，就会抛出ClassNotFoundException。

作用

• 1、防止重复加载同一个.class。通过委托去向上面问一问，加载过了，就不用再加载一遍。保证数据安全。
• 2、保证核心.class不能被篡改。通过委托方式，不会去篡改核心.class，即使篡改也不会去加载，即使加载也不会是同一个.class对象了。不同的加载器加载同一个.class也不是同一个Class对象。这样保证了Class执行安全。

比如：如果有人想替换系统级别的类：String.java。
篡改它的实现，在这种机制下这些系统的类已经被 Bootstrap classLoader 加载过了（为什么？因为当一个类需要加载的时候，最先去尝试加载的就是 BootstrapClassLoader ），所以其他类加载器并没有机会再去加载，从一定程度上防止了危险代码的植入。

沙箱安全机制

组成沙箱的基本组件

• 字节码校验器（bytecode verifier）
  确保 Java 类文件 .Class 遵循 Java 语言规范。这样可以帮助 Java 程序实现内存保护。但并不是所有的类文件都会经过字节码校验，比如核心类。
• 类装载器（class loader）
  其中类装载器在3个方面对 Java 沙箱起作用：
  • 它防止恶意代码去干涉善意的代码； //双亲委派模式
  • 它守护了被信任的类库边界；
  • 它将代码归入保护域，确定了代码可以进行哪些操作。

虚拟机为不同的类加载器载入的类提供不同的命名空间，命名空间由一系列唯一的名称组成，每一个被装载的类将有一个名字，这个命名空间是由 Java 虚拟机为每一个类装载器维护的，它们互相之间甚至不可见。

类装载器采用的机制是双亲委派模式。

1、从最内层 JVM 自带类加载器开始加载，外层恶意同名类得不到加载从而无法使用；

2、由于严格通过包来区分了访问域，外层恶意的类通过内置代码也无法获得权限访问到内层类，破坏代码就自然无法生效。

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

Native

凡是带了 native 关键字的，说明 Java 的作用范围达不到了，得回去调用底层C语言的库
凡是带了 native 关键字的方法会进入本地方法栈，其它的是 Java栈

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

调用本地方法接口（JNI）作用：

扩展 Java 的使用，融合不同的编程语言为 Java 所用
Java 诞生的初衷是融合C/C++程序，C、C++横行，想要立足，必须要有调用C、C++的程序，它在内存区城中专门开辟了块标记区城: Native Method Stack

Native Method Stack（本地方法栈）

登记 native 方法，在执行引擎（Execution Engine）执行的时候。通过JNI （本地方法接口）加载**本地方法库(Native Libraies)**中的方法。

在企业级应用中少见，与硬件有关应用：Java程序驱动打印机，系统管理生产设备等

PC寄存器（Program Counter Register）

程序计数器: Program Counter Register

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

方法区（Method Area）

方法区是被所有线程共享，所有字段和方法字节码，以及一些特殊方法，如构造函数，接口代码也在此定义，简单说：所有定义的方法的信息都保存在该区域，此区域属于共享区间；

静态变量、常量、类信息(构造方法、接口定义)、运行时的常量池（如：static，final,，Class（类模板）, 常量池）存在方法区中，但是实例变量存在堆内存中，和方法区无关。

栈（Java Stack）

为什么 main() 先执行，最后结束：（因为一开始 main() 先压入栈）

栈：栈内存，主管程序的运行，生命周期和线程同步。
线程结束，栈内存也就释放，对于栈来说，不存在垃圾回收问题。

栈存放：8大基本类型+对象引用+实例的方法。
栈运行原理：栈帧（局部变量表+操作数栈）每调用一个方法都有一个栈帧。
栈满了 main() 无法结束，会抛出错误：栈溢出 StackOverflowError

栈 + 堆 + 方法区：交互关系

堆（Heap）

一个 JVM 只有一个堆内存，堆的大小是可以调节的。
类加载器读取了类文件后，一般会把 类，方法，常量，变量，保存所有引用类型的真实对象放到堆中。

堆内存细分3个区域：

• 新生区（伊甸园区） Young / new
• 养老区 old
• 永久区 Perm ，在JDK8以后，永久存储区改了个名字 (元空间)

GC 垃圾回收，主要是在 伊甸园区 和 养老区。

假设内存满了，报错 OOM：堆内存不够 OutOfMemoryError:Java heap space

//-Xms8m -Xmx8m -XX:+PrintGCDetails
public static void main(String[] args) {
    String str = "javajavajavajava";

    while (true){
        str += str + new Random().nextInt(888888888)+ new Random().nextInt(21_0000_0000);
    }
}
//OutOfMemoryError:Java heap space 堆内存满了

新生区 （伊甸园+幸存者区*2）

• 类诞生和成长甚至死亡的地方
• 伊甸园，所有对象都是在伊甸园区 new 出来的
• 幸存者区（from, to），轻GC定期清理伊甸园，活下来的放入幸存者区，幸存者区满了之后重GC 清理伊甸园+幸存者区，活下来的放入养老区。都满了就报 OOM。

注：经过研究，99%的对象都是临时对象！直接被清理了

老年区

新生区剩下来的，轻GC杀不死了

永久区

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

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

常量池一直在方法区，其中的字符串池 JDK1.7之后保存到了堆中。

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

方法区又称非堆 (non-heap)，本质还是堆，只是为了区分概念。

元空间逻辑上存在，物理上并不存在。

堆内存调优

public static void main(String[] args) {
    //返回虚拟机试图使用的最大内存
    long max = Runtime.getRuntime().maxMemory(); //字节 1024*1024
    //返回jvm初始化的总内存
    long total = Runtime.getRuntime().totalMemory();

    System.out.println("max="+max+"字节\t"+(max/(double)1024/1024+"MB"));
    System.out.println("total="+total+"字节\t"+(total/(double)1024/1024+"MB"));
    /* 运行后：
    max=1866465280字节   1780.0MB
    total=126877696字节  121.0MB
     */
    //默认情况下，分配的总内存占电脑内存1/4 初始化1/64
}

报OOM怎么办？

• 1.尝试扩大堆内存，如果还报错，说明有死循环代码 或垃圾代码
  Edit Configration>add VM option> 输入：-Xms1024m -Xmx1024m -XX:+PrintGCDetails
  
  新生区+养老区：305664K+699392K=1005056K = 981.5M ，说明元空间物理并不存在。

• 2.分析内存，看一下哪个地方有问题（专业工具）
  能够看到代码第几行出错：内存快照分析工具，MAT，Jprofiler
  MAT，Jprofiler作用：

  • 分析Dump内存文件，快速定位内存泄漏；
  • 获得堆中的数据
  • 获得大的对象

//-Xms 设置初始化内存分配大小 默认1/64
//-Xmx 设置最大分配内存，默认1/4
//-XX:+PrintGCDetails 打印GC垃圾回收信息
//-XX:+HeapDumpOnOutOfMemoryError //oom DUMP
//-Xms1m -Xmx8m -XX:+HeapDumpOnOutOfMemoryError
public class Demo03 {
    byte[] array = new byte[1*1024*1024]; //1m

    public static void main(String[] args) {
        ArrayList<Demo03> list = new ArrayList<>();
        int count = 0;
        try {
            while (true){
                list.add(new Demo03()); //不停地把创建对象放进列表
                count = count + 1;
            }
        } catch (Exception e) {
            System.out.println("count: "+count);
            e.printStackTrace();
        }
    }
}

GC（垃圾回收）

JVM在进行GC时，并不是对新生代、幸存区、老年区，这三个区域统一回收。大部分时候回收的是新生代

GC两种：轻GC，重GC (Full GC，全局GC)

引用计数法

一般 JVM 不用，大型项目对象太多了

复制算法

-XX:MaxTenuringThreshold=15 设置进入老年代的存活次数条件。


好处：没有内存的碎片，内存效率高
坏处：浪费了内存空间（一个幸存区永远是空的）；假设对象100%存活，复制成本很高。
复制算法最佳使用场景：对象存活度较低的时候，新生区。

标记清除

优点：不需要额外空间，优化了复制算法。
缺点：两次扫描，严重浪费时间，会产生内存碎片。

标记压缩（标记整理）：再优化

三部曲：标记–清除–压缩

标记清除压缩：再优化

每标记清除几次就压缩一次，或者内存碎片积累到一定程度就压缩。

分代收集算法

根据内存对象的存活周期不同，将内存划分成几块，JVM一般将内存分成新生代和老生代。
在新生代中，有大量对象死去和少量对象存活，所以采用复制算法，只需要付出少量存活对象的复制成本就可以完成收集；
老年代中因为对象的存活率极高，没有额外的空间对他进行分配担保，所以采用标记清理或者标记整理算法进行回收；

总结

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

内存整齐度：复制算法 = 标记压缩算法 > 标记清除算法

内存利用率：标记压缩算法 = 标记清除算法 > 复制算法

没有最好的算法，只有合适的算法（GC也被称为分代收集算法）。

• 年轻代：存活率低，用复制算法。
• 老年代：存活率高，区域大，用标记-清除-压缩。

引用计数法的问题：无法解决循环引用

JVM有一个回收算法是引用计数算法，每当对象被引用一次，就+1，释放一个引用就-1，当垃圾回收时，引用计数为 0 的对象就会被 GC 掉。但这个方法有个问题，就是无法解决循环引用的问题。
循环引用就是对象 A 引用了对象 B ，对象 B 引用了对象 A，构成了一个引用环。彼此都没发挥什么作用，但却不会被 GC。为了解决这个问题，就有了可达性分析回收算法。

可达性分析回收算法

算法中定义了几个 GC Root对象，这几个 root对象在 GC时不会被 JVM 回收掉，然后通过这些对象像树枝一样向外延伸，被引用到的对象说明还存活使用，就不会被 GC，没有被这些 root对象引用到的就会被 GC 掉。从而解决了循环引用问题。

GC Root 对象

Root对象主要包括：

①系统类加载器（bootstrap）加载的类。

②JVM 方法区中静态属性引用的对象。

③JVM 常量池中引用的对象。

④JVM 虚拟机栈中引用的对象。

⑤JVM 本地方法栈中引用的对象。

⑥活动着的线程。

官方解释：
GC roots： The so-called GC (Garbage Collector) roots are objects
special for garbage collector. Garbage collector collects those
objects that are not GC roots and are not accessible by references
from GC roots. There are several kinds of GC roots. One object can
belong to more than one kind of root. The root kinds are:

• Class - class loaded by system class loader. Such classes can never be unloaded. They can hold objects via static fields. Please
  note that classes loaded by custom class loaders are not roots, unless
  corresponding instances of java.lang.Class happen to be roots of
  other kind(s).
• Thread - live thread
• Stack Local - local variable or parameter of Java method
• JNI Local - local variable or parameter of JNI method
• JNI Global - global JNI reference
• Monitor Used - objects used as a monitor for synchronization
• Held by JVM - objects held from garbage collection by JVM for its purposes. Actually the list of such objects depends on JVM implementation. Possible known cases are: the system class loader, a few important exception classes which the JVM knows about, a few pre-allocated objects for exception handling, and custom class loaders when they are in the process of loading classes. Unfortunately, JVM provides absolutely no additional detail for such objects. Thus it is up to the analyst to decide to which case a certain “Held by JVM” belongs

强引用：

强引用就是引用了通过new 的方式创建的对象。在root搜索算法的里面，说的引用都指的是强引用关系。

Object obj = new Object();

obj这个变量引用了一个object对象，只有obj这个引用被释放了，对象才会被GC。比如

obj=null;  

这样对象就会被释放。

软引用：

软引用的对象只有在内存不足的时候才会被回收掉，如果GC时，内存充足，那么软引用类型不会被回收。

软引用的作用是：软引用可用来实现内存敏感的高速缓存。如果内存充足，就可以一直把缓存放在内存中，加快数据访问速度。如果内存不足了，缓存就会被回收掉。

Object obj = new Object();
SoftReference<Object> softReference = new SoftReference<>(obj);

弱引用：

弱引用只会生存很短的时间，在第一次经历GC时，无论内存是否充足，都会被回收掉。

弱引用的作用就是：如果一个对象是偶尔的使用，并且希望在使用时随时就能获取到，但又不想影响此对象的垃圾收集，那么就可以将对象修饰为为弱引用类型。弱引用还可以用于监控对象是否已经被垃圾回收器标记为即将回收的垃圾，可以通过弱引用的isEnQueued方法返回对象是否被垃圾回收器标记。还有一种情况：当你想引用一个对象，但是这个对象有自己的生命周期，你不想介入这个对象的生命周期，这时候就可以用弱引用。

Object obj = new Object();
WeakReference<Object> weakReference = new WeakReference(obj);

虚引用：

虚引用就是假的引用，如果一个对象与虚引用关联， 则跟没有引用与之关联一样，在任何时候都可能被垃圾回收器回收。虚引用必须配合引用队列使用。

虚引用的作用：因为虚引用必须和引用队列关联使用，当垃圾回收器准备回收一个对象时， 如果发现它还有虚引用，就会把这个虚引用加入到与之关联的引用队列中。所以程序可以通过判断引用队列中是否已经加入了虚引用，来了解被引用的对象是否将要被垃圾回收。 如果程序发现某个虚引用已经被加入到引用队列，那么就可以在所引用的对象的内存被回收之前采取必要的行动。

Object obj = new Object();
ReferenceQueue queue = new ReferenceQueue();
PhantomReference<Object> pf = new PhantomReference<Object>(obj,queue);