JVM概述

JVM探究

• • 1、JVM的位置
  • 2、JVM大致体系结构
  • 3、类加载器
  • 4、双亲委派机制
  • 5、沙箱安全机制
  • 6、Native
  • 7、PC寄存器
  • 8、方法区
  • 9、栈
  • 10、三种不同的JVM
  • 11、堆
  • 12、JMM

次博客仅做学习参考，部分内容存在改变huo。具体细节请参考书籍《深入理解java虚拟机》，现以出到了第三版

面试问题：

• 请谈谈你对JVM的理解？java8虚拟机和之前的变化更新？
• 什么是OOM，什么是栈溢出StackOverFlowError？怎么分析？
• JVM的常见调优参数有哪些？
• 内存快如何抓取，怎么分析Dump文件？
• 谈谈JVM中，类加载器的认识？

1、JVM的位置

2、JVM大致体系结构

3、类加载器

加载Class文件

3.1、运行流程图

3.2、模板类测试

测试代码：

package pers.mobian.jvm;

public class User {
    public static void main(String[] args) {
        User user1 = new User();
        User user2 = new User();
        User user3 = new User();

        System.out.println(user1.hashCode());
        System.out.println(user2.hashCode());
        System.out.println(user3.hashCode());

        Class<? extends User> aClass1 = user1.getClass();
        Class<? extends User> aClass2 = user1.getClass();
        Class<? extends User> aClass3 = user1.getClass();

        System.out.println(aClass1.hashCode());
        System.out.println(aClass2.hashCode());
        System.out.println(aClass3.hashCode());

    }
}

执行结果：

932607259
1740000325
1142020464
157627094
157627094
157627094

总结：

对于一个新建的类，可以实例化不同的对象，但是这些不同的对象，都是来自同一个模板对象，即xx.clss

3.3、加载器分类

1. 虚拟机自带的加载器
2. 启动类（根）加载器
3. 扩展类加载器（java9更名为PlatformClassLoade）
4. 应用程序（系统类）加载器

4、双亲委派机制

测试案例：

package java.lang;

public class String {
    //双亲委派机制
    //1. APP --> Platform --> BOOT(最终执行)
    
    public String toString(){
        return "Hello";
    }

    public static void main(String[] args) {
        String s = new String();
        System.out.println(s.getClass().getClassLoader());
    }

    /*
    * 1. 类加载器收到类加载的请求
    * 2. 将这个请求向上委托给父类加载器去完成，一直委托，直到根加载器
    * 3. 启动加载器检查是否能够加载当前这个类，能加载就结束，使用当前加载器。否则就抛出异常，通知子类加载器进行加载
    * 4. 重复步骤3
    * 5. 如果都没有那就报错：ClassNotFound
    *
    * */
}

执行结果

错误: 在类 java.lang.String 中找不到 main 方法, 请将 main 方法定义为:
public static void main(String[] args)
否则 JavaFX 应用程序类必须扩展javafx.application.Application

5、沙箱安全机制

java用来保证程序安全引入的一种安全机制

详情可以查看博客链接

javascript:void(0)

6、Native

//线程的start方法内
private native void start0();

饭是带有native关键字，说明这是java作用范围达不到的，它会去调用C语言的库

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

凡是带有native关键字的方法就会进入本地方法栈，其他的就是java栈

Native Interface本地接口

本地接口的作用是为了融合不同的语言，最初是为了融合C/C++程序，java在最初诞生时，为了让有一席之地，就想到了必须调用C/C++的程序，于是就在内存中专门开辟了一块区域处理标记为native的代码，具体做法为在Native Method Stack中等级native方法，在（Execution Engine）执行引擎的时候加载Native Libraies

目前该方法的使用越来越少，除非时与硬件相关的应用，比如用java程序驱动打印机或者管理设备。在企业级应用中比较少见。因为现在的异构领域间通信很发达，比如可以使用Socket通信，也可以使用Web Service等。

Native Method Stack

它的绝体做法是Native Method Stack中登记native方法，在（Execution Engine）执行引擎执行的时候加载Native Libraies（本地库）

7、PC寄存器

程序计数器：Program Counter Register

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

8、方法区

Method Area

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

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

static、final、Class、常量池

9、栈

一种数据结构

程序 = 数据结构 + 算法：持续学习

程序 = 框架 + 业务逻辑：吃饭

栈：先进后出、后进先出

队列：先进先出（FIFO：First Input First Output）

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

线程一旦结束，栈内存也就释放，对于栈来说，不存在垃圾回收

一旦线程结束，栈就Over

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

栈运行原理：栈帧

栈满了：StackOverflowError

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

10、三种不同的JVM

• Sun：HotSpot（我们使用的）
• BEA：JRockit
• IBM：J9 VM

11、堆

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

类加载器读取了类文件后，一般会把类、方法、常量、变量以及所有引用数据类型的真实对象

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

• 新生区（伊甸园区） Young/New
• 养老区 old
• 永久区 Perm

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

假设内存满了，就会报OOM错误，堆内存不够！

java.lang.OutOfMemoryError:Java heap space

在JDK8以后，永久存储区改名为元空间（当然具体又有部分改变）

11.1、新生区、老年区、永久区

新生区

• 类：诞生和成长的地方，甚至死亡
• 伊甸园区：所有的对象都是在伊甸园区new出来的
• 幸存者区（0，1）

伊甸园区先产生对象，然后不停的增加，当伊甸园区满了以后，就会触发一次轻GC，存活的对象就进入到幸存者区。当幸存者区也满了以后，就会触发重GC，然后依然存活的对象就进入养老区。

老年区

经研究，99%的对象都是临时对象

永久区

• JDK1.7之前：永久代，常量池是在方法区

• JDK1.7 ：永久区，但是慢慢的退化，去永久代，常量池在堆中

• JDK1.8之后：无永久代，常量池在元空间

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

该区域出现的错误为OOM，可能的情况是：

• 一个启动类，加载了大量的第三方jar包
• Tomcat部署了太多的应用
• 大量动态生成的反射类

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

测试代码：

package pers.mobian;

import java.util.Random;

public class test {
    public static void main(String[] args) {

        //返回虚拟机试图使用的最大内存
        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=" + total + "字节\t" + (total / (double) 1024 / 1024) + "MB");

    }
}

执行结果：

//默认情况下，分配的总内存是电脑的1/4，初始化内存是电脑的1/64
max=2124414976字节	2026.0MB
total=134217728字节	128.0MB

11.2、堆内存调优

堆内存出错解决步骤：

1. 尝试扩大对内存看结果

   -Xms1024m -Xms1024m -XX:+PrintGCDetails

2. 分析内存，看是什么地方出了问题（使用专业工具）

在一个项目中，突然出现OOM故障，请问如何排除？

• Debug：一行一行的分析代码
• 能够看到代码第几行出错：内存快照分析工具，MAT、Jprofiler

MAT、Jprofiler作用：

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

11.3、GC

作用区域：内存调优区域

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

• 新生代
• 幸存区（from to）
• 老年代

GC分两种：轻GC（普通的GC），重GC（全局GC）

GC题目：

• JVM的内存模型和分区，包括每个区分别放了些什么？
• 堆里面的分区有哪些？并分别说说它们的特点。
• GC的算法有哪些？标记清除法，标记压缩法，复制算法，引用计数器（java未使用），怎么使用？
• 轻GC和重GC分别在什么时候发生？

引用计数法

复制算法

好处：没有内存碎片

坏处：浪费了一块幸存区的内存空间，即幸存to区。假设对象100%存活，耗费资源较大

复制算法最佳使用场景：对象存活度较低的时候，新生区

标记清除算法

缺点：两次扫描，严重浪费时间，会产生内存碎片

优点：不需要额外的空间

标记压缩算法：在标记清除算法的基础上进行压缩

总结：

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

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

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

没有最好的算法，只有最合适的算法------>即GC也称为分代收集算法

年轻代：存活率低，使用复制算法

老年代：区域大存活率高，使用标记清除（内存碎片不是太多）+标记压缩算法混合实现

12、JMM

12.1、什么是JMM？

java内存模型，Java Memory Mode

12.2、作用

缓存一致性协议，用于定义数据读写的规则

JMM定义了线程工作内存和主存之间的抽象关系：线程之间的共享变量存储在主内存（Main Memory）中，每个线程都有一个私有的本地内存（Local Memory）

使用volilate关键字解决共享对象可见性的问题。

12.3、如何学习

JMM对这八种指令的使用，制定了如下规则：

• 不允许read和load、store和write操作之一单独出现。即使用了read必须load，使用了store必须write
• 不允许线程丢弃他最近的assign操作，即工作变量的数据改变了之后，必须告知主存
• 不允许一个线程将没有assign的数据从工作内存同步回主内存
• 一个新的变量必须在主内存中诞生，不允许工作内存直接使用一个未被初始化的变量。就是怼变量实施use、store操作之前，必须经过assign和load操作
• 一个变量同一时间只有一个线程能对其进行lock。多次lock后，必须执行相同次数的unlock才能解锁
• 如果对一个变量进行lock操作，会清空所有工作内存中此变量的值，在执行引擎使用这个变量前，必须重新load或assign操作初始化变量的值
• 如果一个变量没有被lock，就不能对其进行unlock操作。也不能unlock一个被其他线程锁住的变量
• 对一个变量进行unlock操作之前，必须把此变量同步回主内存

JMM对这八种操作规则和对volatile的一些特殊规则就能确定哪里操作是线程安全，哪些操作是线程不安全的了。但是这些规则实在复杂，很难在实践中直接分析。所以一般我们也不会通过上述规则进行分析。更多的时候，使用java的happen-before规则来进行分析。