从头捋捋jvm(-java虚拟机)

jvm 是Java Virtual Machine（Java虚拟机）的缩写，java 虚拟机作为一种跨平台的软件是作用于操作系统之上的，那么认识并了解它的底层运行逻辑对于java开发人员来说很有必要！

让我们来看看它一次编译，到处运行的牛叉之处！
废话不多说，先看看jvm的架构图(无论何时脑子里要有这样一张图)：

总概
从这副架构图可以看出jvm由类装载器、运行时数据区、执行引擎、本地方法接口还有垃圾回收器构成;其中垃圾回收器作用在整个jvm内存中（主要作用在堆和方法区），所以图中没有具体体现，但是我们要知道这么个东西，后面会聊jvm内存调优主要是在调堆

接下来，我们再结合jvm架构图一个个分析下：

类加载器

了解类加载器就是了解代码编译执行的机制

1.加载：查找并加载类的二进制数据

2.连接：

• 验证：保证被加载的类的正确性；
• 准备：给类静态变量分配内存空间，赋值一个默认的初始值；
• 解析：把类中的符号引用转换为直接引用

  把java编译为class文件的时候，虚拟机并不知道所引用的地址；助记符：符号引用转为真正的直接引用，找到对应的直接地址！

3.初始化：给类的静态变量赋值正确的值；

来看下这行代码的执行顺序：

package jvm;

public class TestClassLoader {
    public static int a = 1;
    // 1、加载  编译TestClassLoader文件为 .class 文件，通过类加载，加载到JVM

    // 2、连接
    //验证(1)  保证Class类文件没有问题
    //准备(2)  给int类型分配内存空间，a = 0；
    //解析(3)  符号引用转换为直接引用

    // 3、初始化
    //经过这个阶段的解析，把1 赋值给 变量 a；
}

了解了这个加载执行顺序后，我们再来看看下面这段代码，请你说说程序是如何输出的?

Demo1代码：

package jvm;
/** 
*JVM 参数：
*-XX:+TraceClassLoading // 用于追踪类的加载信息并打印出来
*分析项目启动为什么这么慢，快速定位自己的类有没有被加载！
*rt.jar jdk 出厂自带的，最高级别的类加载器要加载的！
*/ 
public class Demo1 {
    public static void main(String[] args) {
        System.out.println(Children1.str2);
        Children1.sayHello();
        // 输出:
        //      Parent1 static
        //      Children1 static
        //      hello,str2
        //      hello,str1
    }
}
class Parent1{
    public static String str1 = "hello,str1";
    public static void sayHello(){
        System.out.println(str1);
    }

    static {
        System.out.println("Parent1 static");
    }
}
class Children1 extends Parent1{
    public static String str2 = "hello,str2";
    public static void sayHello(){
        System.out.println(str1);
    }
    
    static {
        System.out.println("Children1 static");
    }
}

可以看出，子类继承父类 会优先加载父类的 然后静态块是先于方法和静态变量的.那么常量又是怎样的呢？

Demo2代码：

package jvm;

public class Demo2 {
    public static void main(String[] args) {
        System.out.println(Parent2.STR2);
        // 输出：
        // hello static final
    }
}
class Parent2{
    public static final String STR2 = "hello static final";
    static {
        System.out.println("Parent2 static"); // 这句话会输出吗？
    }
}

Demo3代码:

package jvm;

import java.util.UUID;
public class Demo3 {
    public static void main(String[] args) {
        System.out.println(Parent3.STR3);
        // 输出： Parent3 static
        //       ee33c452-70e2-47a6-946a-99261819a49d
    }
}
class Parent3{
    public static final String STR3 = UUID.randomUUID().toString();
    static {
        System.out.println("Parent3 static"); // 这句话会输出吗？
    }
}

理解：根据上面的jvm架构图可以知道类信息，常量，静态变量，编译后运行代码都是存在方法区里的，而常量是存在方法区的常量池中的。

而对于编译期可以“确定值”的常量：例如Demo2中STR2 是存放在Demo2类调用者所在的常量池中的，当STR2放到常量池后Demo2与Parent2类的关系就没有了！

对于编译期“不确定值”的常量：例如Demo3中STR3 是不存在Demo3的调用者的常量池中的，在程序运行期间会主动使用Demo3所在的类，会加载其静态块！

上面的程序Parent2.STR2输出后就退出了Parent2类，因为程序加载Parent2类是直接调用了常量池中关于STR2的引用，无需再加载类的其他信息包括静态块，说白了按我的理解就是常量池和类的其他信息不在一个内存区，程序根据指令扫描的时候无需扫描不相关的内存区！说到池(池？嗯，等等是不是和线程池和队列有关，哈哈。学东西要养成发散思维的习惯，这样就能串起来很多知识点，渐渐形成自己的知识面。)接下来就来扩展一下：

package jvm;
/**
 * 思考：
 * String == 比较的是什么？
 * 八大基本类型哪些实现了池化技术
 */
public class Exclude {
    public static void main(String[] args) {
        String java = "java";
        String java1 = new String("java");
        String java2 = new String("java");
        System.out.println(java == java1);//输出false 
        System.out.println(java1 == java2);//输出false
        // 注️：String用==比较的时候不仅比较的是对象的值还比较的是对象值的引用
        // equals

        int i = 128;
        int i1 = 128;
        System.out.println(i == i1);//输出true

        Integer integer = 128;
        Integer integer1 = 128;
        System.out.println(integer == integer1);//输出false

        Float f = 0.1f;
        Float f1 = 0.1f;
        System.out.println(f == f1);//输出false
    }
}

注️：java中基本类型的包装类的大部分都实现了常量池技术，这些类是Byte,Short,Integer,Long,Character,Boolean
另外两种浮点数类型的包装类Double Float则没有实现。
另外Byte,Short,Integer,Long,Character这5种整型的包装类也只是在对应值小于等于127时才可使用常量池，即对象不负责创建和管理大于127的这些类的对象

类加载器 分类

1、java虚拟机自带的加载器

• BootStrap 根加载器 （加载系统的包，JDK 核心库中的类 rt.jar）
• Ext 扩展类加载器 （加载一些扩展jar包中的类）
• Sys/App 系统（应用类）加载器 （我们自己编写的类）

2、用户自己定义的加载器

• ClassLoader，只需要继承这个抽象类即可，自定义自己的类加载器

Demo4代码：

package jvm;

public class Demo4 {
    public static void main(String[] args) {
        Object o = new Object(); // jdk 自带的
        Demo demo = new Demo();  // 实例化一个自己定义的对象

        // null 在这里并不代表没有，只是Java触及不到！
        System.out.println(o.getClass().getClassLoader()); // null
        System.out.println(demo.getClass().getClassLoader()); // AppClassLoader
        System.out.println(demo.getClass().getClassLoader().getParent()); // ExtClassLoader
        System.out.println(demo.getClass().getClassLoader().getParent().getParent()); // null
        
        // jvm 中有机制可以保护自己的安全；
        // 双亲委派机制 ： 一层一层的让父类去加载，如果顶层的加载器不能加载，然后再向下类推
        // ClassLoader         04
        // AppClassLoader      03
        // ExtClassLoader      02
        // BootStrap (最顶层)   01  java.lang.String  rt.jar

        // 双亲委派机制 可以保护java的核心类不会被自己定义的类所替代
    }
}
class Demo{

}

本地接口库

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

大家都知道java是从C过度过来的，C可以直接操作硬件
思考一个问题：线程是基于内存的，那么应该是操作硬件 让计算机cpu来划分时间片来“同时”执行多个任务，那么程序是怎么怎么达到底层的呢？java 能直接操作硬件吗？我们来看看线程是怎么启动的，看源码（面向源码编程）

 public synchronized void start() {
        /**
         * This method is not invoked for the main method thread or "system"
         * group threads created/set up by the VM. Any new functionality added
         * to this method in the future may have to also be added to the VM.
         *
         * A zero status value corresponds to state "NEW".
         */
        if (threadStatus != 0)
            throw new IllegalThreadStateException();

        /* Notify the group that this thread is about to be started
         * so that it can be added to the group's list of threads
         * and the group's unstarted count can be decremented. */
        group.add(this);

        boolean started = false;
        try {
            start0();  //启动 调用下面的native修饰的启动方法
            started = true;
        } finally {
            try {
                if (!started) {
                    group.threadStartFailed(this);
                }
            } catch (Throwable ignore) {
                /* do nothing. If start0 threw a Throwable then
                  it will be passed up the call stack */
            }
        }
    }

    private native void start0();

native : 只要是带了这个关键字的，说明 java的作用范围达不到，只能去调用底层 C 语言的库！

这部分知识作为java开发只需要了解即可，如果想去研究也可以看看嵌入式C的相关东西（C语言->编译器—>汇编语言—>驱动->硬件）。

运行时数据区

程序计数器

每个线程都有一个程序计数器，是线程私有的。

程序计数器就是一块十分小的内存空间；几乎可以不计

作用： 看做当前字节码执行的行号指示器

分支、循环、跳转、异常处理！都需要依赖于程序计数器来完成！

bipush 将 int、float、String、常量值推送值栈顶

istore 将一个数值从操作数栈存储到局部变量表

iadd 加

imul 乘

方法区

Method Area 方法区 是 Java虚拟机规范中定义的运行是数据区域之一，和堆（heap）一样可以在线程之间共享！

JDK1.7之前

永久代：用于存储一些虚拟机加载类信息，常量，字符串、静态变量等等，这些东西都会放到永久代中；

永久代大小空间是有限的：如果满了 OutOfMemoryError：PermGen

JDK1.8之后

彻底将永久代移除 HotSpot jvm ，Java Heap 中或者 Metaspcace（Native Heap）元空间；

元空间就是方法区在 HotSpot jvm 的实现；

方法区主要是存：类信息，常量，字符串、静态变量、符号引用、方法代码。

元空间和永久代，都是对JVM规范中方法区的实现。

元空间和永久代最大的区别：元空间并不在Java虚拟机中，使用的是本地内存！

设置元空间大小：-XX:MetasapceSize10m

堆和栈

堆和栈都是内存中相对独立的一块区域，jvm内存分为5个区域，分别是寄存器、本地方法区、方法区、栈内存、堆内存！

注️：每个线程启动的时候，都会创建一个PC（Program Counter，程序计数器）寄存器，我们习惯上称呼为程序计数器，并不是什么其他的东西！

栈和堆的区别

• 1.堆是不连续的，所以分配的内存是在运行期确认的，因此大小不固定；堆对于整个应用程序都是共享、可见的；堆内存存储的是实体；堆内存存放的实体会被垃圾回收机制不定时的回收
• 2.栈是连续的，所以分配的内存大小要在编译期就确认，大小是固定的；栈只对于线程是可见的，所以也是线程私有，他的生命周期和线程相同（所以说，栈里面是一定不会存在垃圾回收的问题）；栈内存存储一些基本类型的值，对象的引用，方法等；栈内存的更新速度要快于堆内存（仅次于寄存器），因为局部变量的生命周期很短；栈内存存放的变量生命周期一旦结束就会被释放。

面试题：java中的基本数据类型都是存储在栈中的吗？

面试基本上问到这里都是三连，说说八大基本数据类型？说说堆和栈？接下来就是这个有坑的问题

答：不是

一：在方法中声明的变量，即该变量是局部变量，每当程序调用方法时，系统都会为该方法建立一个方法栈，其所在方法中声明的变量就放在方法栈中，当方法结束系统会释放方法栈，其对应在该方法中声明的变量随着栈的销毁而结束，这就局部变量只能在方法中有效的原因

在方法中声明的变量可以是基本类型的变量，也可以是引用类型的变量。

（1）当声明是基本类型的对象时，其变量及变量的引用都在栈中。

（2）当声明的是引用类型(new出来的)时，所声明的变量（该变量实际上是在方法中存储的是内存地址值）是放在方法的栈中，该变量所指向的对象是放在堆内存中的。

二：在类中声明的变量是成员变量，也叫全局变量，放在堆中的（因为全局变量不会随着某个方法执行结束而销毁）。

同样在类中声明的变量即可是基本类型的变量 也可是引用类型的变量

（1）当为基本类型时，其变量名及其值放在堆内存中的

（2）当为引用类型时，其声明的变量仍然会存储一个内存地址值，该内存地址值指向所引用的对象。引用变量名和对应的对象仍然存储在相应的堆中

扩展–>请根据以下代码说说6个对象的在堆栈中是如何分配的？

String str1 = "abc";
String str2 = "abc";
String str3 = "abc";
String str4 = new String("abc");
String str5 = new String("333");
String str6 = new String("333");

结合下面的图来理解String 常量存放的位置：

题外话：JVM目前有 SUN公司 HotSpot、BEA公司 JRockit、IBM公司 J9VM
关于堆在垃圾回收器里面介绍！

执行引擎

类装载器装载负责装载编译后的字节码，并加载到运行时数据区（Runtime Data Area），然后执行引擎执行会执行这些字节码。
字节码必须通过类加载过程加载到JVM后才能够被执行，执行有三种模式：

• 1.解释执行
• 2.JIT（Just-In-Time）编译即执行
• 3.JIT与解释混合执行
  来看下执行引擎的简要执行流程：
  

关于执行引擎这种底层的东西了解即可，说白了就是执行编译后字节码的一套概念模型！执行引擎包含了众多可以操作字节码的执行指令，使程序能够按照一定的顺序执行！关于执行引擎（推荐知乎层层剥开JVM——字节码执行引擎,亦可以推荐孤尽老师《码出高效》一书中的第四章“走进JVM”来深入了解）

垃圾回收器

呼，长出了一口气！终于写到和堆相关的了
看堆之前我们先了解下JVM的内存布局：

物理上只有 新生、养老；元空间在本地内存中，不在JVM中！

GC 垃圾回收主要是在 新生区和养老区，又分为 普通的GC 和 Full GC，如果堆满了，就会爆出 OutOfMemory(OOM);

新生区

新生区 就是一个类诞生、成长、消亡的地方！

新生区细分： Eden、s（from to），所有的类Eden被 new 出来的，慢慢的当 Eden 满了，程序还需要创建对象的时候，就会触发一次轻量级GC；清理完一次垃圾之后，会将活下来的对象，会放入幸存者区（），……. 清理了 20次之后，出现了一些极其顽强的对象，有些对象突破了15次的垃圾回收！这时候就会将这个对象送入养老区！运行了几个月之后，养老区满了，就会触发一次 Full GC；假设项目1年后，整个空间彻彻底底的满了，突然有一天系统 OOM，排除OOM问题，或者重启；

Sun HotSpot 虚拟机中，内存管理（分代管理机制：不同的区域使用不同的算法！）

Eden from to

99% 的对象在 Eden 都是临时对象；

养老区

15次都幸存下来的对象进入养老区，养老区满了之后，触发 Full GC

默认是15次，可以修改！

永久区（Perm）

放一些 JDK 自身携带的 Class、Interface的元数据；

几乎不会被垃圾回收的；

OutOfMemoryError：PermGen 在项目启动的时候永久代不够用了？加载大量的第三方包！

JDK1.6之前： 有永久代、常量池在方法区；

JDK1.7：有永久代、但是开始尝试去永久代，常量池在堆中；

JDK1.8 之后：永久代没有了，取而代之的是元空间；常量池在元空间中；

闲聊：方法区和堆一样，是共享的区域，是JVM 规范中的一个逻辑的部分，但是记住它的别名 非堆

jvm内存调优

来看以下代码：

package jvm;

/**
 * 环境:jdk1.8
 * jvm:HotSpot
 *
 *  默认情况：
 *  maxMemory : 1808.0MB （虚拟机试图使用的最大的内存量  一般是物理内存的 1/4）
 *  totalMemory : 123.0MB （虚拟机试图默认的内存总量 一般是物理内存的 1/64）
 *
 *  自定义： -XX:+PrintGCDetails; // 输出详细的垃圾回收信息
 *          -Xmx: 最大分配内存； 1/4
 *          -Xms: 初始分配的内存大小； 1/64
 *          -Xmx1024m -Xms1024m -XX:+PrintGCDetails
 */
public class HeapDemo {
    public static void main(String[] args) {
        // 获取堆内存的初始大小和最大大小
        long maxMemory = Runtime.getRuntime().maxMemory();
        long totalMemory = Runtime.getRuntime().totalMemory();

        System.out.println("maxMemory="+maxMemory+"(字节)、"+(maxMemory/1024/(double)1024)+"MB");
        System.out.println("totalMemory="+totalMemory+"(字节)、"+(totalMemory/1024/(double)1024)+"MB");
    }
}

输出信息如下：

由计算得出(305664K+699392K)/1024 = 981.5MB
说明新生代和老年代内存相加为整个分配内存大小，也从侧面证明了元空间不存在于jvm中，它存在于本地空间中！

–认识了堆后，我们再来聊聊堆的内存调优，这是每个java开发都需要掌握的！
模拟oom,看看GC详情：

package jvm;

import java.util.Random;
/**
 * 设置内存大小：-Xmx8m -Xms8m -XX:+PrintGCDetails
 */
public class HeapDemo1 {
    public static void main(String[] args) {
        System.gc(); // 手动唤醒GC（），等待cpu的调用
        String str = "talk is cheap,show me your code";
        while (true){
            str += str
                    + new Random().nextInt(999999999)
                    + new Random().nextInt(999999999);
        }
        // 出现问题：java.lang.OutOfMemoryError: Java heap space
    }
}

输出如下：

"C:\Program Files\Java\jdk1.8.0_171\bin\java.exe" -Xmx8m -Xms8m -XX:+PrintGCDetails "-javaagent:D:\idea\IntelliJ IDEA 2019.3.3\lib\idea_rt.jar=63475:D:\idea\IntelliJ IDEA 2019.3.3\bin" -Dfile.encoding=UTF-8 -classpath "C:\Program Files\Java\jdk1.8.0_171\jre\lib\charsets.jar;C:\Program Files\Java\jdk1.8.0_171\jre\lib\deploy.jar;C:\Program Files\Java\jdk1.8.0_171\jre\lib\ext\access-bridge-64.jar;C:\Program Files\Java\jdk1.8.0_171\jre\lib\ext\cldrdata.jar;C:\Program Files\Java\jdk1.8.0_171\jre\lib\ext\dnsns.jar;C:\Program Files\Java\jdk1.8.0_171\jre\lib\ext\jaccess.jar;C:\Program Files\Java\jdk1.8.0_171\jre\lib\ext\jfxrt.jar;C:\Program Files\Java\jdk1.8.0_171\jre\lib\ext\localedata.jar;C:\Program Files\Java\jdk1.8.0_171\jre\lib\ext\nashorn.jar;C:\Program Files\Java\jdk1.8.0_171\jre\lib\ext\sunec.jar;C:\Program Files\Java\jdk1.8.0_171\jre\lib\ext\sunjce_provider.jar;C:\Program Files\Java\jdk1.8.0_171\jre\lib\ext\sunmscapi.jar;C:\Program Files\Java\jdk1.8.0_171\jre\lib\ext\sunpkcs11.jar;C:\Program Files\Java\jdk1.8.0_171\jre\lib\ext\zipfs.jar;C:\Program Files\Java\jdk1.8.0_171\jre\lib\javaws.jar;C:\Program Files\Java\jdk1.8.0_171\jre\lib\jce.jar;C:\Program Files\Java\jdk1.8.0_171\jre\lib\jfr.jar;C:\Program Files\Java\jdk1.8.0_171\jre\lib\jfxswt.jar;C:\Program Files\Java\jdk1.8.0_171\jre\lib\jsse.jar;C:\Program Files\Java\jdk1.8.0_171\jre\lib\management-agent.jar;C:\Program Files\Java\jdk1.8.0_171\jre\lib\plugin.jar;C:\Program Files\Java\jdk1.8.0_171\jre\lib\resources.jar;C:\Program Files\Java\jdk1.8.0_171\jre\lib\rt.jar;E:\sCloud\studyDemo\out\production\studyDemo" jvm.HeapDemo1
[GC (Allocation Failure) [PSYoungGen: 1536K->504K(2048K)] 1536K->632K(7680K), 0.0022005 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
[GC (System.gc()) [PSYoungGen: 877K->488K(2048K)] 1005K->712K(7680K), 0.0017541 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
[Full GC (System.gc()) [PSYoungGen: 488K->0K(2048K)] [ParOldGen: 224K->645K(5632K)] 712K->645K(7680K), [Metaspace: 3441K->3441K(1056768K)], 0.0181221 secs] [Times: user=0.03 sys=0.00, real=0.02 secs] 
[GC (Allocation Failure) [PSYoungGen: 1249K->325K(2048K)] 1894K->971K(7680K), 0.0010536 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
[GC (Allocation Failure) [PSYoungGen: 1531K->259K(2048K)] 2960K->1689K(7680K), 0.0009587 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
[GC (Allocation Failure) [PSYoungGen: 1532K->487K(2048K)] 2961K->2165K(7680K), 0.0117368 secs] [Times: user=0.02 sys=0.00, real=0.01 secs] 
[GC (Allocation Failure) [PSYoungGen: 1688K->128K(2048K)] 6500K->4940K(7680K), 0.1107265 secs] [Times: user=0.02 sys=0.00, real=0.11 secs] 
[GC (Allocation Failure) [PSYoungGen: 128K->128K(2048K)] 4940K->4940K(7680K), 0.0211234 secs] [Times: user=0.00 sys=0.00, real=0.02 secs] 
[Full GC (Allocation Failure) [PSYoungGen: 128K->0K(2048K)] [ParOldGen: 4812K->2550K(5632K)] 4940K->2550K(7680K), [Metaspace: 3939K->3939K(1056768K)], 0.0311921 secs] [Times: user=0.03 sys=0.00, real=0.03 secs] 
[GC (Allocation Failure) [PSYoungGen: 138K->32K(2048K)] 4256K->4149K(7680K), 0.0064069 secs] [Times: user=0.00 sys=0.00, real=0.01 secs] 
[GC (Allocation Failure) [PSYoungGen: 32K->32K(2048K)] 4149K->4149K(7680K), 0.0007456 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
[Full GC (Allocation Failure) [PSYoungGen: 32K->0K(2048K)] [ParOldGen: 4117K->3332K(5632K)] 4149K->3332K(7680K), [Metaspace: 3942K->3942K(1056768K)], 0.0250859 secs] [Times: user=0.01 sys=0.00, real=0.02 secs] 
[GC (Allocation Failure) [PSYoungGen: 0K->0K(2048K)] 3332K->3332K(7680K), 0.0014623 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
[Full GC (Allocation Failure) [PSYoungGen: 0K->0K(2048K)] [ParOldGen: 3332K->3277K(5632K)] 3332K->3277K(7680K), [Metaspace: 3942K->3942K(1056768K)], 0.0241555 secs] [Times: user=0.02 sys=0.00, real=0.02 secs] 
Heap
 PSYoungGen      total 2048K, used 42K [0x00000000ffd80000, 0x0000000100000000, 0x0000000100000000)
  eden space 1536K, 2% used [0x00000000ffd80000,0x00000000ffd8a978,0x00000000fff00000)
  from space 512K, 0% used [0x00000000fff80000,0x00000000fff80000,0x0000000100000000)
  to   space 512K, 0% used [0x00000000fff00000,0x00000000fff00000,0x00000000fff80000)
 ParOldGen       total 5632K, used 3277K [0x00000000ff800000, 0x00000000ffd80000, 0x00000000ffd80000)
  object space 5632K, 58% used [0x00000000ff800000,0x00000000ffb337e8,0x00000000ffd80000)
 Metaspace       used 3974K, capacity 4568K, committed 4864K, reserved 1056768K
  class space    used 437K, capacity 460K, 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 jvm.HeapDemo1.main(HeapDemo1.java:11)

Process finished with exit code 1
// 分析：GC 普通GC(轻GC)、Full GC 重GC
// 1536K 执行 GC之前的大小,504K  执行 GC之后的大小
// (2048K) young 的total大小 ,(5632K)old 的total 大小 (7680K)整个堆已被占用的大小
// 0.0241555 secs 清理的时间、user 总计GC所占用CPU的时间   
// sys OS调用等待的时间   real 应用暂停的时间

好了，理解这些参数后基本知道怎么调优了。
其实Idea 还有一款插件JProfiler 专门用来分析程序内存占用情况的，用JProfiler 可以dump 内存快照帮助我们快速定位问题。教程百度上有，此处不做说明！

注️：JVM在进行GC时，并非每次都是对三个区域进行扫描的！大部分的时候都是指的新生代！

• 普通GC：只针对新生代 【GC】
• 全局GC：主要是针对老年代，偶尔伴随新生代！ 【Full GC】

GC四大算法：

引用计数法

特点：每个对象都有一个引用计数器，每当对象被引用一次，计数器就+1，如果引用失效，则计数器-1，如果为0，则GC可以清理；

缺点：

• 计数器维护麻烦！
• 循环引用无法处理！

注️：JVM 一般不采用这种方式，现在一般使用可达性算法，GC Root…

复制算法

1、一般普通GC 之后，差不多Eden几乎都是空的了！

2、每次存活的对象，都会被从 from 区和 Eden区等复制到 to区，from 和 to 会发生一次交换；记住一个点就好，谁空谁是to，每当幸存一次，就会导致这个对象的年龄+1；如果这个年龄值大于15（默认值，后面我们会讲解调整），就会进入养老区；

优点：没有标记和清除的过程！效率高！没有内存碎片！

缺点：需要浪费双倍的空间

Eden 区,对象存活率极低！ 统计：99% 对象都会在使用一次之后，引用失效！推荐使用 复制算法

标记清除算法

老年代一般使用这个，但是会和我们后面的整理压缩一起使用！

优点：不需要额外的空间！

缺点：两次扫描，耗时较为严重，会产生内存碎片，不连续！

标记清除压缩

减少了上面标记清除的缺点：没有内存碎片！但是耗时可能也较为严重！

那我们什么时候可以考虑使用这个算法呢？

在我们这个要使用算法的空间中，假设这个空间中很少，不经常发生GC，那么可以考虑使用这个算法！

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

面试题：

最后再来看看几个面试题：

1.JVM 垃圾回收的时候如何确定垃圾，GC Roots？

• 引用计数法 （每引用一次就加一，为0或-1就会被GC清除）
• 可达性分析算法 (如果从 GC Root 这个对象开始，对于没有关联的对象GC认为不可达的，就会被清理)

2.什么是GC Root?

• 1、虚拟机栈中引用的对象！
• 2、类中静态属性引用的对象
• 3、方法区中的常量
• 4、本地方法栈中 Native 方法引用的对象！

3.jvm 常用参数有哪些，你都用过哪些？

• 1、标配参数：-version,-help,-showversion
• 2、X参数：-Xint # 解释执行，-Xcomp # 第一次使用就编译成本地的代码，-Xmixed # 混合模式（Java默认）
• 3、XX参数：+ 或者 – 某个属性值， + 代表开启某个功能，- 表示关闭了某个功能 例如:jps -l ,jinfo -flag PrintGCDetail 进程号 # 查看某个运行中的java 程序，-XX:+PrintGCDetails # 打印GC详情
• 4.XX 参数之key = value值；例如：元空间大小：-XX:MetaspaceSize=128m#设置元空间大小，-XX:MaxTenuringThreshold=15#设置新生代需要经历多少次GC晋升到老年代中的最大阈值(默认值是15，最大也是15)
• 1).-Xms 初始堆的大小，等价： -XX:InitialHeapSize
• 2).-Xmx 最大堆的大小 ，等价：-XX:MaxHeapSize

-XX:+PrintFlagsInitial 查看 java 环境初始默认值；这里面只要显示的值，我们都可以手动赋值，不建议修改，了解即可！

= 默认值

:= 就是被修改过的值

java -XX:+PrintCommandLineFlags -version 打印出用户手动选项的 XX 选项

4.你常用的项目，发布后配置过JVM 调优参数吗？

-Xms
-Xmx
-Xss  : 线程栈大小设置，默认 512k~1024k
-Xmn  设置年轻代的大小，一般不用动！
-XX:MetaspsaceSize  设置元空间的大小，这个在本地内存中！
-XX:+PrintGCDetails
-XX:SurvivorRatio
设置新生代中的 s0/s1 空间的比例；
`uintx SurvivorRatio  = 8`  Eden：s0：s1 = 8:1:1
`uintx SurvivorRatio  = 4`  Eden：s0：s1 = 4:1:1
-XX:NewRatio
设置年轻代与老年代的占比：
`NewRatio  = 2`   新生代1，老年代是2，默认新生代整个堆的 1/3;
`NewRatio  = 4`   新生代1，老年代+是4，默认新生代整个堆的 1/5;
-XX:MaxTenuringThreshold
进入老年区的存活阈值；
`MaxTenuringThreshold  = 15`

小结：至此JVM的知识，基本已总结完成，推荐书《码出高效》;买了很多书但是一直没看，个人博客新增了栏目“拆书” 有时间会把买的书啃完了写写心得体会，或者看到精彩的地方会分享出来，当然不至于技术一类。为能看到这儿的自己点个赞吧，加油！