温故知新-java虚拟机

---

• Posted by 微博@Yangsc_o
• 原创文章，版权声明：自由转载-非商用-非衍生-保持署名 | Creative Commons BY-NC-ND 3.0

---

java虚拟机是什么？

java虚拟机(java virtual machine，JVM)，一种可以运行java字节码的虚拟机。
做为一种编程语言的虚拟机，实际上不仅是专用于Java语言，只要生成的编译文件匹配JVM对加载编译文件格式要求，任何语言均可以由JVM编译运行，好比kotlin、scala等。
jvm有不少，除了Hotspot，还有JRockit、J9等
复制代码

• 能够理解为，java运行在虚拟机上，能够屏蔽硬件差别；js运行在浏览器中，浏览器屏蔽了硬件差别；

jvm的体系结构

JVM由三个主要的子系统构成: 类加载子系统、运行时数据区（内存结构）、执行引擎
复制代码

• 这张图须要仔细看一下，包含了类加载子系统、运行时数据区（内存结构）、执行引擎三个子系统包含的内容；

第一个类加载子系统

类的生命周期

• 过程：加载-> 连接-> 初始化-> 使用 ->卸载

加载器分类

• 启动类加载器(Bootstrap ClassLoader) 负责加载JRE的核心类库，如JRE目标下的rt.jar，charsets.jar等
• 扩展类加载器(Extension ClassLoader) 负责加载JRE扩展目录ext中jar类包
• 系统类加载器(Application ClassLoader) 负责加载ClassPath路径下的类包
• 用户自定义加载器(User ClassLoader) 负责加载用户自定义路径下的类包

类加载机制

• 全盘负责委托机制

当一个ClassLoader加载一个类的时候，除非显示的使用另外一个ClassLoader，该类所依赖和引用的类也由这个
ClassLoader载入
复制代码

• 双亲委派机制

指先委托父类加载器寻找目标类，在找不到的状况下载本身的路径中查找并载入目标类
双亲委派模式的优点
沙箱安全机制：好比本身写的String.class类不会被加载，这样能够防止核心库被随意篡改
避免类的重复加载：当父ClassLoader已经加载了该类的时候，就不须要子ClassLoader再加载一次
复制代码

第二个运行时数据区（内存结构）

从图中能够看到，主要分为方法区、堆、栈、程序计数器、本地方法栈；

1. 方法区

类的全部字段和方法字节码，以及一些特殊方法如构造函数，接口代码在这里定义。简单来讲，全部定义的方法的
信息都保存在该区域，静态变量+常量+类信息（构造方法/接口定义）+运行时常量池都存在方法区中；
虽然Java虚拟机规范把方法区描述为堆的一个逻辑部分，可是它却有一个别名叫作Non-Heap（非堆），目的应该是为了和Java的堆区分开；
复制代码

2. 堆

   

虚拟机启动时自动分配建立，用于存放对象的实例，几乎全部对象都在堆上分配内存，当对象没法在该空间申请到内存是将抛出OutOfMemoryError异常。同时也是垃圾收集器管理的主要区域。

• 堆主要分为三个区域：新生代、老年代、原空间；
  • 新生代（Young Generation）
    • 在这里会发生类出生、成长、消亡的区域；
    • 新生代又分为两个部分：伊甸区（Eden space）和幸存者区（Survivor space），全部的类都是在伊甸区被new出来的。
    • 幸存区又分为From和To区。 当Eden区的空间用完是，程序又须要建立对象，JVM的垃圾回收器将Eden区进行垃圾回收（Minor GC），将Eden区中的再也不被其它对象应用的对象进行销毁。而后将Eden区中剩余的对象移到From Survivor区。若From Survivor区也满了，再对该区进行垃圾回收，而后移动到To Survivor区。
  • 老年代（Old Generation） 新生代通过屡次GC仍然存货的对象移动到老年区。若老年代也满了，这时候将发生Major GC（也能够叫Full GC），进行老年区的内存清理。若老年区执行了Full GC以后发现依然没法进行对象的保存，就会抛出OOM（OutOfMemoryError）异常
  • 元空间（Meta Space） 在JDK1.8以后，元空间替代了永久代，它是对JVM规范中方法区的实现，区别在于元数据区不在虚拟机当中，而是用的本地内存，永久代在虚拟机当中，永久代逻辑结构上也属于堆，可是物理上不属于。

3. 栈(Stack) Java线程执行方法的内存模型，一个线程对应一个栈，每一个方法在执行的同时都会建立一个栈帧（用于存储局部变量表，操做数栈，动态连接，方法出口等信息）不存在垃圾回收问题，只要线程一结束该栈就释放，生命周期和线程一致

4. 本地方法栈(Native Method Stack) 和栈做用很类似，区别不过是Java栈为JVM执行Java方法服务，而本地方法栈为JVM执行native方法服务。登记native方法，在Execution Engine执行时加载本地方法库

5. 程序计数器(Program Counter Register) 就是一个指针，指向方法区中的方法字节码（用来存储指向吓一跳指令的地址，也即将要执行的指令代码），由执行引擎读取下一条指令，是一个很是小的内存空间，几乎能够忽略不计

GC算法和收集器

如何判断对象能够被回收？

• 堆中几乎放着全部的对象实例，对堆垃圾回收前的第一步就是要判断哪些对象已经死亡（即不能再被任何途径使用的对象）

• 引用计数法；

  • 给对象添加一个引用计数器，每当有一个地方引用，计数器就加1。当引用失效，计数器就减1。任什么时候候计数器为0的对象就是不可能再被使用的。
  • 实现简单，效率高，可是目前主流的虚拟机中没有选择这个算法来管理内存，最主要的缘由是它很难解决对象以前相互循环引用的问题。所谓对象之间的相互引用问题，经过下面代码所示：除了对象a和b相互引用着对方以外，这两个对象之间再无任何引用。可是它们由于互相引用对方，致使它们的引用计数器都不为0，因而引用计数器法没法通知GC回收器回收它们。

• 可达性分析算法

  • 算法的基本思想就是经过一系列的称为”GC Roots“的对象做为起点，从这些节点开始向下搜索，节点所走过的路径称为引用链，当一个对象到GC Roots没有任何引用链相连的话，则证实此对象时不可用的。
  • GC Roots根节点：类加载器、Thread、虚拟机栈的本地变量表、static成员、常量引用、本地方法栈的变量等等

如何判断一个常量是废弃常量?

运行时常量池主要回收的是废弃的常量。那么，咱们怎么判断一个常量时废弃常量呢？

• 假如在常量池中存在字符串"abc"，若是当前没有任何String对象引用该字符串常量的话，就说明常量”abc“就是废弃常量，若是这时发生内存回收的话并且有必要的话，”abc“会被系统清理出常量池。

如何判断一个类是无用的类?

• 须要知足如下三个条件：

  • 该类全部的实例都已经被回收，也就是 Java 堆中不存在该类的任何实例。
  • 加载该类的 ClassLoader 已经被回收。
  • 该类对应的 java.lang.Class 对象没有在任何地方被引用，没法在任何地方经过反射访问该类的方法。

• 虚拟机能够对知足上述3个条件的无用类进行回收，这里仅仅是”能够“，而并非和对象同样不适用了就必然会被回收;

垃圾回收算法

• 垃圾回收算法有不少，每一种都有不一样的优劣、在不通的堆区域，会采用不一样的垃圾回收算法；

  

• 标记-清除算法 它是最基础的收集算法，这个算法分为两个阶段，“标记”和”清除“。首先标记出全部须要回收的对象，在标记完成后统一回收全部被标记的对象。它有两个不足的地方：
  • 效率问题，标记和清除两个过程的效率都不高；
  • 空间问题，标记清除后会产生大量不连续的碎片；

    

复制算法

为了解决效率问题，复制算法出现了。它能够把内存分为大小相同的两块，每次只使用其中的一块。当这一块的内存，使用完后，就将还存活的对象复制到另外一块区，而后再把使用的空间一次清理掉。这样就使每次的内存回收都是对内存区间的一半进行回收

标记-整理算法

根据老年代的特色提出的一种标记算法，标记过程和“标记-清除”算法同样，可是后续步骤不是直接对可回收对象进行回收，而是让全部存活的对象向一段移动，而后直接清理掉边界之外的内存

分代收集算法

如今的商用虚拟机的垃圾收集器基本都采用"分代收集"算法，这种算法就是根据对象存活周期的不一样将内存分为几块。通常将java堆分为新生代和老年代，这样咱们就能够根据各个年代的特色选择合适的垃圾收集算法。

• eg：在新生代中，每次收集都有大量对象死去，因此能够选择复制算法，只要付出少许对象的复制成本就能够完成每次垃圾收集。而老年代的对象存活概率时比较高的，并且没有额外的空间对它进行分配担保,就必须选择“标记-清除”或者“标记-整理”算法进行垃圾收集

垃圾收集器

Serial收集器

Serial（串行）收集器收集器是最基本、历史最悠久的垃圾收集器了。一个单线程收集器，它的 “单线程” 的意义不只仅意味着它只会使用一条垃圾收集线程去完成垃圾收集工做，更重要的是它在进行垃圾收集工做的时候必须暂停其余全部的工做线程（ “Stop The World” ），直到它收集结束。

ParNew收集器

• ParNew收集器其实就是Serial收集器的多线程版本，除了使用多线程进行垃圾收集外，其他行为（控制参数、收集算法、回收策略等等）和Serial收集器彻底同样。
• 新生代采用复制算法，老年代采用标记-整理算法。

Parallel Scavenge收集器

• Parallel Scavenge 收集器相似于ParNew 收集器。
• Parallel Scavenge收集器关注点是吞吐量（高效率的利用CPU）。
  • CMS等垃圾收集器的关注点更多的是用户线程的停顿时间（提升用户体验）。所谓吞吐量就是CPU中用于运行用户代码的时间与CPU总消耗时间的比值。 Parallel Scavenge收集器提供了不少参数供用户找到最合适的停顿时间或最大吞吐量，若是对于收集器运做不太了解的话，手工优化存在的话能够选择把内存管理优化交给虚拟机去完成也是一个不错的选择。
• 新生代采用复制算法，老年代采用标记-整理算法。

Serial Old收集器

Serial收集器的老年代版本，它一样是一个单线程收集器。它主要有两大用途：一种用途是在JDK1.5以及之前的版本中与Parallel Scavenge收集器搭配使用，另外一种用途是做为CMS收集器的后备方案

Parallel Old收集器

Parallel Scavenge收集器的老年代版本。使用多线程和“标记-整理”算法。在注重吞吐量以及CPU资源的场合，均可以优先考虑 Parallel Scavenge收集器和Parallel Old收集器。

CMS收集器

• CMS（Concurrent Mark Sweep）收集器是一种以获取最短回收停顿时间为目标的收集器。它而很是符合在注重用户体验的应用上使用。

• CMS（Concurrent Mark Sweep）收集器是HotSpot虚拟机第一款真正意义上的并发收集器，它第一次实现了让垃圾收集线程与用户线程（基本上）同时工做。

• 从名字中的Mark Sweep这两个词能够看出，CMS收集器是一种 “标记-清除”算法实现的，它的运做过程相比于前面几种垃圾收集器来讲更加复杂一些。整个过程分为四个步骤：

  • 初始标记（CMS initial mark）： 暂停全部的其余线程，并记录下直接与root相连的对象，速度很快；
  • 并发标记（CMS concurrent mark）： 同时开启GC和用户线程，用一个闭包结构去记录可达对象。但在这个阶段结束，这个闭包结构并不能保证包含当前全部的可达对象。由于用户线程可能会不断的更新引用域，因此GC线程没法保证可达性分析的实时性。因此这个算法里会跟踪记录这些发生引用更新的地方。
  • 从新标记（CMS remark）： 从新标记阶段就是为了修正并发标记期间由于用户程序继续运行而致使标记产生变更的那一部分对象的标记记录，这个阶段的停顿时间通常会比初始标记阶段的时间稍长，远远比并发标记阶段时间短
  • 并发清除（CMS concurrent sweep）： 开启用户线程，同时GC线程开始对为标记的区域作清扫

• CMS主要优势：并发收集、低停顿。可是它有下面三个明显的缺点：

  • 对CPU资源敏感；
  • 没法处理浮动垃圾；
  • 它使用的回收算法-“标记-清除”算法会致使收集结束时会有大量空间碎片产生。

G1收集器

G1 (Garbage-First)是一款面向服务器的垃圾收集器,主要针对配备多颗处理器及大容量内存的机器. 以极高几率知足，GC停顿时间要求的同时,还具有高吞吐量性能特征； 被视为JDK1.7中HotSpot虚拟机的一个重要进化特征。它具有一下特色：

• 并行与并发：G1能充分利用CPU、多核环境下的硬件优点，使用多个CPU（CPU或者CPU核心）来缩短StopThe-World停顿时间。部分其余收集器本来须要停顿Java线程执行的GC动做，G1收集器仍然能够经过并发的方式让java程序继续执行

• 分代收集：虽然G1能够不须要其余收集器配合就能独立管理整个GC堆，可是仍是保留了分代的概念。 空间整合：与CMS的“标记–清理”算法不一样，G1从总体来看是基于“标记整理”算法实现的收集器；从局部上来看是基于“复制”算法实现的

• 可预测的停顿：这是G1相对于CMS的另外一个大优点，下降停顿时间是G1 和 CMS 共同的关注点，但G1 除了追求低停顿外，还能创建可预测的停顿时间模型，能让使用者明确指定在一个长度为M毫秒的时间片断内

• G1收集器的运做大体分为如下几个步骤：

  • 初始标记
  • 并发标记
  • 最终标记
  • 筛选回收

• G1收集器在后台维护了一个优先列表，每次根据容许的收集时间，优先选择回收价值最大的Region(这也就是它的名字Garbage-First的由来)。这种使用Region划份内存空间以及有优先级的区域回收方式，保证了GF收集器在有限时间内能够尽量高的收集效率（把内存化整为零）

Z Garbage Collector

即ZGC，是一个可伸缩的、低延迟的垃圾收集器，主要为了知足以下目标进行设计： 停顿时间不会超过10ms 停顿时间不会随着堆的增大而增大（无论多大的堆都能保持在10ms如下） 可支持几百M，甚至几T的堆大小（最大支持4T） 停顿时间在10ms如下，10ms实际上是一个很保守的数据，在SPECjbb 2015基准测试，128G的大堆下最大停顿时间才1.68ms，远低于10ms;

The Z Garbage Collector, also known as ZGC, is a scalable low latency garbage collector designed to meet the following goals:

Pause times do not exceed 10ms
Pause times do not increase with the heap or live-set size
Handle heaps ranging from a few hundred megabytes to multi terabytes in size
复制代码

• ZGC扩展阅读1
• ZGC扩展阅读2

怎么选择垃圾收集器？

1. 优先调整堆的大小让服务器本身来选择
2. 若是内存小于100m，使用串行收集器
3. 若是是单核，而且没有停顿时间的要求，串行或JVM本身选择
4. 若是容许停顿时间超过1秒，选择并行或者JVM本身选
5. 若是响应时间最重要，而且不能超过1秒，使用并发收集器

• 官方推荐G1，性能高，若是使用JDK11及以上，也能够考虑一下ZGC

调优

JVM调优主要就是调整下面两个指标

• 停顿时间：垃圾收集器作垃圾回收中断应用执行的时间。-XX:MaxGCPauseMillis
• 吞吐量：垃圾收集的时间和总时间的占比：1/(1+n),吞吐量为1-1/(1+n)。-XX:GCTimeRatio=n

GC经常使用参数

堆栈设置

-Xss:每一个线程的栈大小 -Xms:初始堆大小，默认物理内存的1/64 -Xmx:最大堆大小，默认物理内存的1/4 -Xmn:新生代大小 -XX:NewSize:设置新生代初始大小-XX:NewRatio:默认2表示新生代占年老代的1/2，占整个堆内存的1/3。 -XX:SurvivorRatio:默认8表示一个survivor区占用1/8的Eden内存，即1/10的新生代内存。 -XX:MetaspaceSize:设置元空间大小 -XX:MaxMetaspaceSize:设置元空间最大容许大小，默认不受限制，JVM Metaspace会进行动态扩展

垃圾回收统计信息

-XX:+PrintGC -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -Xloggc:filename

收集器设置

-XX:+UseSerialGC:设置串行收集器 -XX:+UseParallelGC:设置并行收集器 -XX:+UseParallelOldGC:老年代使用并行回收收集器 -XX:+UseParNewGC:在新生代使用并行收集器 -XX:+UseParalledlOldGC:设置并行老年代收集器 -XX:+UseConcMarkSweepGC:设置CMS并发收集器 -XX:+UseG1GC:设置G1收集器 -XX:ParallelGCThreads:设置用于垃圾回收的线程数

并行收集器设置

-XX:ParallelGCThreads:设置并行收集器收集时使用的CPU数。并行收集线程数。 -XX:MaxGCPauseMillis:设置并行收集最大暂停时间 -XX:GCTimeRatio:设置垃圾回收时间占程序运行时间的百分比。公式为1/(1+n)

CMS收集器设置

-XX:+UseConcMarkSweepGC:设置CMS并发收集器 -XX:+CMSIncrementalMode:设置为增量模式。适用于单CPU状况。 -XX:ParallelGCThreads:设置并发收集器新生代收集方式为并行收集时，使用的CPU数。并行收集线程数。 -XX:CMSFullGCsBeforeCompaction:设定进行多少次CMS垃圾回收后，进行一次内存压缩 -XX:+CMSClassUnloadingEnabled:容许对类元数据进行回收 -XX:UseCMSInitiatingOccupancyOnly:表示只在到达阀值的时候，才进行CMS回收 -XX:+CMSIncrementalMode:设置为增量模式。适用于单CPU状况 -XX:ParallelCMSThreads:设定CMS的线程数量 -XX:CMSInitiatingOccupancyFraction:设置CMS收集器在老年代空间被使用多少后触发 -XX:+UseCMSCompactAtFullCollection:设置CMS收集器在完成垃圾收集后是否要进行一次内存碎片的整理

G1收集器设置

-XX:+UseG1GC:使用G1收集器 -XX:ParallelGCThreads:指定GC工做的线程数量 -XX:G1HeapRegionSize:指定分区大小(1MB~32MB，且必须是2的幂)，默认将整堆划分为2048个分区 -XX:GCTimeRatio:吞吐量大小，0-100的整数(默认9)，值为n则系统将花费不超过1/(1+n)的时间用于垃圾收集 -XX:MaxGCPauseMillis:目标暂停时间(默认200ms) -XX:G1NewSizePercent:新生代内存初始空间(默认整堆5%) -XX:G1MaxNewSizePercent:新生代内存最大空间 -XX:TargetSurvivorRatio:Survivor填充容量(默认50%) -XX:MaxTenuringThreshold:最大任期阈值(默认15) -XX:InitiatingHeapOccupancyPercen:老年代占用空间超过整堆比IHOP阈值(默认45%),超过则执行混合收集 -XX:G1HeapWastePercent:堆废物百分比(默认5%) -XX:G1MixedGCCountTarget:参数混合周期的最大总次数(默认8

---

你的鼓励是我创做的最大动力