java虚拟机缩写为-java填空题 收藏 0

史上最全JVM虚拟机详解(万字图文)

JVM虚拟机是大厂必备技能，特别是JVM内存模型，JVM垃圾收集器、回收算法，以及性能优化这块更是重中之重，本篇我就全面的来详解JVM@mikechen

JVM是Java Virtual Machine（Java虚拟机）的缩写。

虚拟机是一种抽象化的计算机，通过在实际的计算机上仿真模拟各种计算机功能来实现的。

Java虚拟机有自己完善的硬体架构，如处理器、堆栈、寄存器等，还具有相应的指令系统。

Java虚拟机屏蔽了与具体操作系统平台相关的信息，使得Java程序只需生成在Java虚拟机上运行的目标代码（字节码），就可以在多种平台上不加修改地运行，如下图所示：

简单来说JVM是用来解析和运行Java程序的。

由上图可以清楚的看到JVM的内存空间分为3大部分：

1. 堆内存
2. 方法区
3. 栈内存

其中栈内存可以再细分为java虚拟机栈和本地方法栈,堆内存可以划分为新生代和老年代,新生代中还可以再次划分为Eden区、From Survivor区和To Survivor区。

其中一部分是线程共享的，包括 Java 堆和方法区；另一部分是线程私有的，包括虚拟机栈和本地方法栈，以及程序计数器这一小部分内存。

java 堆（Java Heap）是Java 虚拟机所管理的内存中最大的一块。

堆是被所有线程共享的区域，在虚拟机启动时创建的。堆里面存放的都是对象的实例（new 出来的对象都存在堆中）。

此内存区域的唯一目的就是存放对象实例（new的对象），几乎所有的对象实例都在这里分配内存。

堆内存分为两个部分：年轻代和老年代。我们平常所说的垃圾回收，主要回收的就是堆区。

更细一点划分新生代又可划分为Eden区和2个Survivor区（From Survivor和To Survivor）。

下图中的Perm代表的是永久代，但是注意永久代并不属于堆内存中的一部分，同时jdk1.8之后永久代已经被移除。

新生代 ( Young ) 与老年代 ( Old ) 的比例的值为 1:2 ( 该值可以通过参数 –XX:NewRatio 来指定 )

默认的，Eden : from : to = 8 : 1 : 1 ( 可以通过参数 –XX:SurvivorRatio 来设定 )，即：Eden = 8/10 的新生代空间大小，from = to = 1/10 的新生代空间大小。

方法区也称”永久代“，它用于存储虚拟机加载的类信息、常量、静态变量、是各个线程共享的内存区域。

在JDK8之前的HotSpot JVM，存放这些”永久的”的区域叫做“永久代(permanent generation)”。永久代是一片连续的堆空间，在JVM启动之前通过在命令行设置参数-XX:MaxPermSize来设定永久代最大可分配的内存空间，默认大小是64M（64位JVM默认是85M）。

随着JDK8的到来，JVM不再有 永久代(PermGen)。但类的元数据信息（metadata）还在，只不过不再是存储在连续的堆空间上，而是移动到叫做“Metaspace”的本地内存（Native memory。

方法区或永生代相关设置

• -XX:PermSize=64MB 最小尺寸，初始分配
• -XX:MaxPermSize=256MB 最大允许分配尺寸，按需分配
• XX:+CMSClassUnloadingEnabled -XX:+CMSPermGenSweepingEnabled 设置垃圾不回收
• 默认大小
• -server选项下默认MaxPermSize为64m
• -client选项下默认MaxPermSize为32m

java虚拟机栈是线程私有，生命周期与线程相同。创建线程的时候就会创建一个java虚拟机栈。

虚拟机执行java程序的时候，每个方法都会创建一个栈帧，栈帧存放在java虚拟机栈中，通过压栈出栈的方式进行方法调用。

栈帧又分为：局部变量表、操作数栈、动态连接、方法出口等。

本地方法栈（Native Method Stacks）与虚拟机栈所发挥的作用是非常相似的，其区别不过是虚拟机栈为虚拟机执行Java方法（也就是字节码）服务，而本地方法栈则是为虚拟机使用到的Native方法服务。

程序计数器就是记录当前线程执行程序的位置，改变计数器的值来确定执行的下一条指令，比如循环、分支、方法跳转、异常处理，线程恢复都是依赖程序计数器来完成。

Java虚拟机多线程是通过线程轮流切换并分配处理器执行时间的方式实现的。为了线程切换能恢复到正确的位置，每条线程都需要一个独立的程序计数器，所以它是线程私有的。

直接内存并不是虚拟机内存的一部分，也不是Java虚拟机规范中定义的内存区域。jdk1.4中新加入的NIO，引入了通道与缓冲区的IO方式，它可以调用Native方法直接分配堆外内存，这个堆外内存就是本机内存，不会影响到堆内存的大小。

1.标记-清除:

标记-清除算法将垃圾回收分为两个阶段：标记阶段和清除阶段。

在标记阶段首先通过根节点(GC Roots)，标记所有从根节点开始的对象，未被标记的对象就是未被引用的垃圾对象。然后，在清除阶段，清除所有未被标记的对象。适用场合：

• 存活对象较多的情况下比较高效
• 适用于年老代（即旧生代）

缺点：

• 容易产生内存碎片，再来一个比较大的对象时（典型情况：该对象的大小大于空闲表中的每一块儿大小但是小于其中两块儿的和），会提前触发垃圾回收
• 扫描了整个空间两次（第一次：标记存活对象；第二次：清除没有标记的对象）

2.复制算法

从根集合节点进行扫描，标记出所有的存活对象，并将这些存活的对象复制到一块儿新的内存（图中下边的那一块儿内存）上去，之后将原来的那一块儿内存（图中上边的那一块儿内存）全部回收掉现在的商业虚拟机都采用这种收集算法来回收新生代。

适用场合：

• 存活对象较少的情况下比较高效
• 扫描了整个空间一次（标记存活对象并复制移动）
• 适用于年轻代（即新生代）：基本上98%的对象是”朝生夕死”的，存活下来的会很少

缺点：

• 需要一块儿空的内存空间
• 需要复制移动对象

3. 标记-整理

复制算法的高效性是建立在存活对象少、垃圾对象多的前提下的。

这种情况在新生代经常发生，但是在老年代更常见的情况是大部分对象都是存活对象。如果依然使用复制算法，由于存活的对象较多，复制的成本也将很高。标记-压缩算法是一种老年代的回收算法，它在标记-清除算法的基础上做了一些优化。

首先也需要从根节点开始对所有可达对象做一次标记，但之后，它并不简单地清理未标记的对象，而是将所有的存活对象压缩到内存的一端。之后，清理边界外所有的空间。

这种方法既避免了碎片的产生，又不需要两块相同的内存空间，因此，其性价比比较高。

4.分代收集

分代收集算法就是目前虚拟机使用的回收算法，它解决了标记整理不适用于老年代的问题，将内存分为各个年代。一般情况下将堆区划分为老年代（Tenured Generation）和新生代（Young Generation），在堆区之外还有一个代就是永久代（Permanet Generation）。

在不同年代使用不同的算法，从而使用最合适的算法，新生代存活率低，可以使用复制算法。而老年代对象存活率高，没有额外空间对它进行分配担保，所以只能使用标记清除或者标记整理算法。

1.串行Serial收集器

串行收集器是最简单的，它设计为在单核的环境下工作（32位或者windows），你几乎不会使用到它。它在工作的时候会暂停整个应用的运行，因此在所有服务器环境下都不可能被使用。

使用方法：-XX:+UseSerialGC

2.并行Parallel收集器

这是JVM默认的收集器，跟它名字显示的一样，它最大的优点是使用多个线程来扫描和压缩堆。缺点是在minor和full GC的时候都会暂停应用的运行。并行收集器最适合用在可以容忍程序停滞的环境使用，它占用较低的CPU因而能提高应用的吞吐（throughput）。

使用方法：-XX:+UseParallelGC

3.CMS收集器

CMS是Concurrent-Mark-Sweep的缩写，并发的标记与清除。

这个算法使用多个线程并发地（concurrent）扫描堆，标记不使用的对象，然后清除它们回收内存。在两种情况下会使应用暂停（Stop the World, STW）：

1. 当初次开始标记根对象时initial mark。

2. 当在并行收集时应用又改变了堆的状态时，需要它从头再确认一次标记了正确的对象final remark。

这个收集器最大的问题是在年轻代与老年代收集时会出现的一种竞争情况（race condition），称为提升失败promotion failure。对象从年轻代复制到老年代称为提升promotion，但有时侯老年代需要清理出足够空间来放这些对象，这需要一定的时间，它收集的速度可能赶不上不断产生的要提升的年轻代对象的速度，这时就需要做STW的收集。STW正是CMS想避免的问题。为了避免这个问题，需要增加老年代的空间大小或者增加更多的线程来做老年代的收集以赶上从年轻代复制对象的速度。

除了上文所说的内容之外，CMS最大的问题就是内存空间碎片化的问题。CMS只有在触发FullGC的情况下才会对堆空间进行compact。如果线上应用长时间运行，碎片化会非常严重，会很容易造成promotion failed。为了解决这个问题线上很多应用通过定期重启或者手工触发FullGC来触发碎片整理。

对比并行收集器它的一个坏处是需要占用比较多的CPU。对于大多数长期运行的服务器应用来说，这通常是值得的，因为它不会导致应用长时间的停滞。但是它不是JVM的默认的收集器。

4.G1收集器

如果你的堆内存大于4G的话，那么G1会是要考虑使用的收集器。它是为了更好支持大于4G堆内存引入的。

G1之前的JVM内存模型

• 新生代：伊甸园区(eden space) + 2个幸存区
• 老年代
• 持久代(perm space)：JDK1.8之前
• 元空间(metaspace)：JDK1.8之后取代持久代

G1收集器的内存模型

1)G1堆内存结构堆内存会被切分成为很多个固定大小区域（Region），每个是连续范围的虚拟内存。堆内存中一个区域(Region)的大小可以通过-XX:G1HeapRegionSize参数指定，大小区间最小1M、最大32M，总之是2的幂次方。

默认把堆内存按照2048份均分。

2)G1堆内存分配每个Region被标记了E、S、O和H，这些区域在逻辑上被映射为Eden，Survivor和老年代。存活的对象从一个区域转移（即复制或移动）到另一个区域。区域被设计为并行收集垃圾，可能会暂停所有应用线程。如上图所示，区域可以分配到Eden，survivor和老年代。此外，还有第四种类型，被称为巨型区域（Humongous Region）。Humongous区域是为了那些存储超过50%标准region大小的对象而设计的，它用来专门存放巨型对象。如果一个H区装不下一个巨型对象，那么G1会寻找连续的H分区来存储。为了能找到连续的H区，有时候不得不启动Full GC。

G1回收流程

在执行垃圾收集时，G1以类似于CMS收集器的方式运行。

G1收集器的阶段分以下几个步骤：

1）G1执行的第一阶段：初始标记(Initial Marking )这个阶段是STW(Stop the World )的，所有应用线程会被暂停，标记出从GC Root开始直接可达的对象。

2）G1执行的第二阶段：并发标记从GC Roots开始对堆中对象进行可达性分析，找出存活对象，耗时较长。当并发标记完成后，开始最终标记(Final Marking )阶段

3）最终标记（标记那些在并发标记阶段发生变化的对象，将被回收）

4）筛选回收（首先对各个Regin的回收价值和成本进行排序，根据用户所期待的GC停顿时间指定回收计划，回收一部分Region）

最后，G1中提供了两种模式垃圾回收模式，Young GC和Mixed GC，两种都是Stop The World(STW)的。

1)堆栈配置相关

例子：

-Xmx 3550m：最大堆大小为3550m。

-Xms 3550m：设置初始堆大小为3550m。

-Xmn 2g：设置年轻代大小为2g。

-Xss 128k：每个线程的堆栈大小为128k。

-XX:MaxPermSize：设置持久代大小为16m

-XX:NewRatio=4: 设置年轻代（包括Eden和两个Survivor区）与年老代的比值（除去持久代）。

-XX:SurvivorRatio=4：设置年轻代中Eden区与Survivor区的大小比值。设置为4，则两个Survivor区与一个Eden区的比值为2:4，一个Survivor区占整个年轻代的1/6

-XX:MaxTenuringThreshold=0：设置垃圾最大年龄。如果设置为0的话，则年轻代对象不经过Survivor区，直接进入年老代。

2)垃圾收集器相关

-XX:+UseParallelGC-XX:ParallelGCThreads=20-XX:+UseConcMarkSweepGC-XX:CMSFullGCsBeforeCompaction=5-XX:+UseCMSCompactAtFullCollection：-XX:+UseParallelGC：选择垃圾收集器为并行收集器。

-XX:ParallelGCThreads=20：配置并行收集器的线程数

-XX:+UseConcMarkSweepGC：设置年老代为并发收集。

-XX:CMSFullGCsBeforeCompaction：由于并发收集器不对内存空间进行压缩、整理，所以运行一段时间以后会产生“碎片”，使得运行效率降低。此值设置运行多少次GC以后对内存空间进行压缩、整理。

-XX:+UseCMSCompactAtFullCollection：打开对年老代的压缩。可能会影响性能，但是可以消除碎片

3)辅助信息相关

-XX:+PrintGC：开启打印 gc 信息；

-XX:+PrintGCDetails：打印 gc 详细信息。

1. Jconsole : jdk自带，功能简单，但是可以在系统有一定负荷的情况下使用。对垃圾回收算法有很详细的跟踪。
2. JProfiler：商业软件，功能强大。
3. VisualVM：JDK自带，功能强大，与JProfiler类似。
4. MAT：MAT(Memory Analyzer Tool)，一个基于Eclipse的内存分析工具。

JDK本身提供了很丰富的性能监控工具，除了集成式的visualVM和jConsole外，还有jstat,jstack,jps,jmap,jhat小工具，这些都是性能调优的常用工具。

1.监控GC的状态

使用各种JVM工具，查看当前日志，分析当前JVM参数设置，并且分析当前堆内存快照和gc日志，根据实际的各区域内存划分和GC执行时间，觉得是否进行优化。

举一个例子：系统崩溃前的一些现象：

• 每次垃圾回收的时间越来越长，由之前的10ms延长到50ms左右，FullGC的时间也有之前的0.5s延长到4、5s
• FullGC的次数越来越多，最频繁时隔不到1分钟就进行一次FullGC
• 年老代的内存越来越大并且每次FullGC后年老代没有内存被释放

之后系统会无法响应新的请求，逐渐到达OutOfMemoryError的临界值，这个时候就需要分析JVM内存快照dump。

2.生成堆的dump文件

通过JMX的MBean生成当前的Heap信息，大小为一个3G（整个堆的大小）的hprof文件，如果没有启动JMX可以通过Java的jmap命令来生成该文件。

3.分析dump文件

打开这个3G的堆信息文件，显然一般的Window系统没有这么大的内存，必须借助高配置的Linux，几种工具打开该文件：

• Visual VM
• IBM HeapAnalyzer
• JDK 自带的Hprof工具
• Mat(Eclipse专门的静态内存分析工具)推荐使用

备注：文件太大，建议使用Eclipse专门的静态内存分析工具Mat打开分析。

4.分析结果，判断是否需要优化

如果各项参数设置合理，系统没有超时日志出现，GC频率不高，GC耗时不高，那么没有必要进行GC优化，如果GC时间超过1-3秒，或者频繁GC，则必须优化。

注：如果满足下面的指标，则一般不需要进行GC：

• Minor GC执行时间不到50ms；
• Minor GC执行不频繁，约10秒一次；
• Full GC执行时间不到1s；
• Full GC执行频率不算频繁，不低于10分钟1次；

5.调整GC类型和内存分配

如果内存分配过大或过小，或者采用的GC收集器比较慢，则应该优先调整这些参数，并且先找1台或几台机器进行beta，然后比较优化过的机器和没有优化的机器的性能对比，并有针对性的做出最后选择。

6.不断的分析和调整

通过不断的试验和试错，分析并找到最合适的参数，如果找到了最合适的参数，则将这些参数应用到所有服务器。

Java JDK是什么？JDK安装目录介绍

JDK是SUN提供的一套Java开发环境，全称JavaDevelopmentKit，简称JDK，它是整个Java的核心，其中包括Java编译器、Java运行工具、Java文档生成工具、Java打包工具等。

在JDK安装完毕后，会在硬盘上生成一个目录，该目录被称为JDK的安装目录，如图1所示。

图1 JDK目录结构

为了更好地学习JDK，初学者需要对JDK安装目录下的子目录及文件的作用有所了解，接下来分别对JDK安装目录下的子目录进行介绍。

● bin目录：该目录用于存放一些可执行程序，如javac.exe（Java编译器）、java.exe（Java运行工具）、jar.exe（打包工具）和javadoc.exe（文档生成工具）等。

● db目录：db目录是一个小型的数据库。从JDK 6开始，Java中引入了一个新的成员Java DB，这是一个纯Java实现、开源的数据库管理系统。这个数据库不仅很轻便，而且支持JDBC 4.0所有的规范，在学习JDBC时，不再需要额外地安装一个数据库软件，选择直接使用Java DB即可。

● include目录：由于JDK是通过C和C++实现的，因此在启动时需要引入一些C语言的头文件，该目录就是用于存放这些头文件的。

● jre目录：此目录是Java运行时环境的根目录，它包含Java虚拟机，运行时的类包、Java应用启动器以及一个bin目录，但不包含开发环境中的开发工具。

● lib目录：lib是library的缩写，意为Java类库或库文件，是开发工具使用的归档包文件。

● javafx-src.zip：该压缩文件内存放的是Java FX（Java图形用户界面工具）所有核心类库的源代码。

● src.zip：src.zip为src文件夹的压缩文件，src中放置的是JDK核心类的源代码，通过该文件可以查看Java基础类的源代码。

● README等说明性文档。

在上面的目录中，bin目录是一个非常重要的目录，在其目录中存放着很多可执行程序，其中最重要的就是javac.exe和java.exe，这两个文件的主要作用如下：

● javac.exe是Java编译器工具，它可以将编写好的Java文件编译成Java字节码文件（可执行的Java程序）。Java源文件的扩展名为.java，如“HelloWorld.java”，编译后生成对应的Java字节码文件，文件的扩展名为.class，如“HelloWorld.class”。

● java.exe是Java运行工具，它会启动一个Java虚拟机（JVM）进程，Java虚拟机相当于一个虚拟的操作系统，它专门负责运行由Java编译器生成的字节码文件（.class文件）。

硬核讲解：“Android 虚拟机”的前世今生

我进入 Androird 行业也有一段时间，目前负责项目开发方面的工作，难免会用到虚拟机实现代码运行，最近我也一直在思考，虚拟机是以哪种方式实现的，底层逻辑又是怎样的？于是在网上查阅了相关的资料，结合自身的见解，将之整合在了一起，接下来我们就来了解一下虚拟机的相关知识

● 众所周知，Android 最开始面世时，使用的开发语言是 Java,而 Java 是运行在 Java 虚拟机上的，即 JVM；那么为什么 Google 要单独设计一套新的 Dalvik 虚拟机来执行 Android 程序呢？

● 可能是为了解决移动端设备上软件运行效率问题，可能是 JVM 虚拟机无法满足当时移动端的使用场景，也可能是为了规避与 Oracle 公司的版权纠纷问题，最终 Google 专门为 Android 平台设计了一套虚拟机来运行 Android 程序，它就是 Dalvik Virtual Machine(Dalvik 虚拟机)

● 随着 Android 发展至今，虽然目前开发 Android 程序的语言已经越来越多样性，如 Java,Kotlin,Dart,Flutter 等等，但无论使用哪种语言开发 Android，最终都需要运行在虚拟机上,本篇文章将站在 Android 虚拟机的视角来分析 Android 程序的运行原理

Google 于 2007 年底正式发布了 Android SDK, Dalvik 虚拟机也正式进入我们的视野，而 Dalvik 命名的由来是取至其作者 丹·伯恩斯坦（Dan Bornstein） 曾居住过一个名叫 Dalvik 的小渔村

Dalvik 虚拟机作为 Android 平台的核心组件，拥有如下几个特点：

● 体积小，占用内存空间小

● 专有的 DEX 可执行文件格式，体积更小，执行效率更快

● 常量池采用 32 位索引值，寻址类方法名、字段名、常量更快

● 基于寄存器架构，并拥有一套完整的的指令系统

● 提供了对象生命周期管理、堆栈管理、线程管理、安全和异常管理以及垃圾回收等重要功能

所有的 Android 程序都运行在 Android 系统进程里，每个进程对应着一个 Dalvik 虚拟机实例

JVM 是 Java Virtual Machine（Java虚拟机）的缩写，是 JRE 的一部分；它是一个虚构出来的计算机，是通过在实际的计算机上仿真模拟各种计算机功能来实现的。JVM 有自己完善的硬件架构，如处理器、堆栈、寄存器等，还具有相应的指令系统；Java 虚拟机 JVM 是属于 JRE 的，而现在我们安装 JDK 时也附带安装了 JRE (当然也可以单独安装JRE)

JVM 拥有如下几个特点：

● JVM屏蔽了与具体操作系统平台相关的信息，使得Java程序只需生成在Java虚拟机上运行的目标代码（字节码），就可以在多种平台上不加修改地运行

● Java虚拟机实例负责运行一个Java程序，当启动一个Java程序时，一个虚拟机实例就诞生了。当程序结束，这个虚拟机实例也就消亡。在 Java虚拟机规范中，一个虚拟机实例的行为是分别按照子系统、内存区、数据类型和指令来描述的，这些组成部分一起展示了抽象的虚拟机的内部体系结构

● 作为一种编程语言的虚拟机，实际上不只是专用于Java语言，只要生成的编译文件匹配JVM对载入编译文件格式要求，任何语言都可以由JVM编译运行

Java虚拟机与Java语言并没有必然的联系，他只与特定的二进制文件格式—Class文件格式所关联，Class文件中包含了Java虚拟机指令集(或者称为字节码，Bytecodes)和符号表,还有一些其他辅助信息

从 Dalvik 虚拟机的特点我们可以看出 Dalvik VM 和 JVM 还是有许多的不同点的，两者并不兼容，他们显著的不同点主要有以下几个方面：

● Java 虚拟机运行的是 Java 字节码，Dalvik 虚拟机运行的是 Dalvik 字节码; 传统的 Java 程序经过编译，生成 Java 字节码保存在 .class 文件中，Java 虚拟机通过解码 .class 文件中的内容来运行程序

● 而 Dalvik 虚拟机运行的是 Dalvik 字节码，所有的 Dalvik 字节码由 Java 字节码转换而来，并被打包到一个 DEX(Dalvik Executable) 的执行的文件中，Dalvik 虚拟机通过解释 DEX 文件来执行这些字节码

本质上，Dalvik也是一个Java虚拟机；但它特别之处在于没有使用JVM规范；大多数Java虚拟机都是基于栈的结构，而Dalvik虚拟机则是基于寄存器。基于栈的指令很紧凑

例如，Java虚拟机使用的指令只占一个字节，因而称为字节码；基于寄存器的指令由于需要指定源地址和目标地址，因此需要占用更多的指令空间

Dalvik虚拟机的某些指令需要占用两个字节，基于栈和基于寄存器的指令集各有优劣；一般而言，执行同样的功能，前者需要更多的指令（主要是load和store指令），而后者需要更多的指令空间；需要更多指令意味着要多占用CPU时间，而需要更多指令空间意味着数据缓冲（d-cache）更易失效

Android架构师之路还很漫长，与君共勉

PS:有问题欢迎指正,欢迎大家点赞评论，可以在评论区留下你的建议和感受

本文作者及来源:Renderbus瑞云渲染农场https://www.renderbus.com