Skip to content

README.md

Latest commit

 

History

History
91 lines (74 loc) · 15.2 KB

README.md

File metadata and controls

91 lines (74 loc) · 15.2 KB

JVM


JDK（Java Development Kit）和 JRE（Java Runtime Environment）是 Java 平台的两个关键组成部分，它们之间有以下区别：

  1. JDK（Java Development Kit）：
    • JDK 是 Java 开发工具包，它包括了 Java 开发人员在创建、编译和调试 Java 应用程序时所需的工具和库。
    • JDK 包括 Java 编译器（javac）、Java 虚拟机（JVM）、调试器、开发工具（如 javap 和 javadoc）、标准类库（Java 标准库如 java.utils.*）等。
    • JDK 还把 JRE 包括了，所以下载安装了 JDK 就不用再下载安装 JRE 了。
  2. JRE（Java Runtime Environment）：
    • JRE 是 Java 运行时环境，它是用于运行 Java 应用程序的部署环境。
    • JRE 包括 Java 虚拟机（JVM）和 Java 标准类库，但不包括 Java 编译器和其他开发工具。
    • 当用户只需要运行已经编译好的 Java 应用程序（比如 jar 文件）时，只需要安装 JRE，而不需要 JDK。JRE 提供了 Java 程序的执行环境。

JVM 物理结构

Java 编译

Java 代码编译是由 Java 源码编译器来完成，流程如图：

Java 字节码的执行是由 JVM 执行引擎来完成，流程如图：

Java 代码编译和执行的整个过程包含了以下三个重要的机制：

  • Java 源码编译机制 - 最后生成的 class 文件
  • 类加载机制 - JVM 的类加载是通过 ClassLoader 及其子类来完成的
  • 类执行机制 - JVM 是基于栈的体系结构来执行 class 字节码的。线程创建后，都会产生程序计数器（PC）和栈（Stack），程序计数器存放下一条要执行的指令在方法内的偏移量，栈中存放一个个栈帧，每个栈帧对应着每个方法的每次调用，而栈帧又是有局部变量区和操作数栈两部分组成，局部变量区用于存放方法中的局部变量和参数，操作数栈中用于存放方法执行过程中产生的中间结果。

当编译一个 .java 文件时，.java 文件的每个类都会有一个输出文件。每个输出的文件名和 .java 文件中每个类的类名相同，只是后缀名是 .class。因此，在编译少量的 .java 文件后，会得到大量的 .class 文件。如果使用过编译型语言，那么可能习惯编译后产生一个中间文件（通常称为“obj”文件），然后与使用链接器（创建可执行文件）或类库生成器（创建类库）产生的其他同类文件打包到一起的情况。这不是 Java 工作的方式。在 Java 中，可运行程序是一组 .class 文件，它们可以打包压缩成一个 Java 文档文件（JAR，使用 jar 文档生成器）。Java 解释器负责查找、加载和解释这些文件。
类库是一组类文件。

类初始化和加载
在许多传统语言中，程序在启动时一次性全部加载。接着初始化，然后程序开始运行。必须仔细控制这些语言的初始化过程，以确保 statics 初始化的顺序不会造成麻烦。在 C++ 中，如果一个 static 期望使用另一个 static，而另一个 static 还没有初始化，就会出现问题。
Java 中不存在这样的问题，因为它采用了一种不同的方式加载。因为 Java 中万物皆对象，所以加载活动就容易得多。记住每个类的编译代码都存在于它自己独立的文件中。该文件只有在使用程序代码时才会被加载。一般可以说“类的代码在首次使用时加载“。这通常是指创建类的第一个对象，或者是访问了类的 static 属性或方法。构造器也是一个 static 方法尽管它的 static 关键字是隐式的。因此，准确地说，一个类当它任意一个 static 成员被访问时，就会被加载。
首次使用时就是 static 初始化发生时。所有的 static 对象和 static 代码块在加载时按照文本的顺序（在类中定义的顺序）依次初始化。static 变量只被初始化一次。

在Java中，类装载器把一个类装入 JVM 中，要经过以下步骤：

  1. 加载：查找和导入 Class 文件；
  2. 连接：把类的二进制数据合并到 JRE 中；
    a. 验证：检查载入 Class 文件数据的正确性；
    b. 准备：给类的静态变量分配存储空间；
    c. 解析：将符号引用转成直接引用；
  3. 初始化：对类的静态变量，静态代码块执行初始化操作
  4. 使用：使用类
  5. 卸载：卸载

加载、验证、准备、初始化和卸载这五个阶段的顺序是确定的，类的加载过程必须按照这个顺序来按部就班地开始，而解析阶段则不一定，它在某些情况下可以在初始化阶段后再开始。
类的加载指的是将类的 .class 文件中的二进制数据读入到内存中，将其放在运行时数据区的方法区内，然后在堆区创建一个 java.lang.Class 对象，用来封装类在方法区内的数据结构。类的加载的最终产品是位于堆区中的 Class 对象，Class 对象封装了类在方法区内的数据结构，并且向 Java 程序员提供了访问方法区内的数据结构的接口。
类加载器并不需要等到某个类被“首次主动使用”时再加载它，JVM 规范允许类加载器在预料某个类将要被使用时就预先加载它，如果在预先加载的过程中遇到了 .class 文件缺失或存在错误，类加载器必须在程序首次主动使用该类时才报告错误（LinkageError 错误）如果这个类一直没有被程序主动使用，那么类加载器就不会报告错误。

JIT 优化

Java 虚拟机中有许多附加技术用来提升速度。尤其是与加载器操作有关的，被称为"即时"（Just-In-Time, JIT）编译器的技术。这种技术可以把程序全部或部分翻译成本地机器码，所以不需要 JVM 来进行翻译，因此运行得更快。当需要装载某个类（通常是创建该类的第一个对象）时，编译器会先找到其 .class 文件，然后将该类的字节码装入内存。可以让即时编译器编译所有代码，但这种做法有两个缺点：一是这种加载动作贯穿整个程序生命周期内，累加起来需要花更多时间；二是会增加可执行代码的长度（字节码要比即时编译器展开后的本地机器码小很多），这会导致页面调度，从而一定降低程序速度。另一种做法称为"惰性评估"，意味着即时编译器只有在必要的时候才编译代码。这样，从未被执行的代码也许就压根不会被 JIT 编译。新版 JDK 中的 Java HotSpot 技术就采用了类似的做法，代码每被执行一次就优化一些，所以执行的次数越多，它的速度就越快。

垃圾回收

一些编程语言要求程序员手动管理内存，负责分配和释放内存。比如 C 和 C++（C 代码示例），程序员必须使用 malloc、free、new 和 delete 等命令来分配和释放内存。如果程序员忘记释放不再使用的内存，就会导致内存泄漏，最终可能耗尽系统内存（后续分配时报错）。相反，如果程序员错误地释放了仍在使用的内存，就会导致悬挂指针，可能引发程序崩溃或不可预测的行为。

Java 采用自动垃圾回收机制，程序员不需要手动管理内存。
垃圾回收机制（Garbage Collection / GC）一般是在 Java 堆中进行，因为堆中几乎存放了 Java 中所有的对象实例。
垃圾对象的判定 - Java 堆中存放着几乎所有的对象实例，垃圾收集器对堆中的对象进行回收前，要先确定这些对象是否还有用，Java 通过根搜索算法判定对象是否为垃圾对象。
判定垃圾对象之后，便可以通过垃圾收集算法进行垃圾回收了。

要想理解 Java 中的垃圾回收，先了解其他系统中的垃圾回收机制将会很有帮助。一种简单但速度很慢的垃圾回收机制叫做引用计数。每个对象中含有一个引用计数器，每当有引用指向该对象时，引用计数加 1。当引用离开作用域或被置为 null 时，引用计数减 1。因此，管理引用计数是一个开销不大但是在程序的整个生命周期频繁发生的负担。垃圾回收器会遍历含有全部对象的列表，当发现某个对象的引用计数为 0 时，就释放其占用的空间（但是，引用计数模式经常会在计数为 0 时立即释放对象）。这个机制存在一个缺点：如果对象之间存在循环引用，那么它们的引用计数都不为 0，就会出现应该被回收但无法被回收的情况。对垃圾回收器而言，定位这样的循环引用所需的工作量极大。引用计数常用来说明垃圾回收的工作方式，但因为很难解决对象之间的相互循环引用问题所以似乎没有任何一种 Java 虚拟机选择这种算法来进行垃圾回收。
在更快的策略中，垃圾回收器并非基于引用计数。它们依据的是：对于任意"活"的对象，一定能最终追溯到其存活在栈或静态存储区中的引用。这个引用链条可能会穿过数个对象层次，由此，如果从栈或静态存储区出发，遍历所有的引用，将会发现所有"活"的对象。对于发现的每个引用，必须追踪它所引用的对象，然后是该对象包含的所有引用，如此反复进行，直到访问完"根源于栈或静态存储区的引用"所形成的整个网络。所访问过的对象一定是"活"的。注意，这解决了对象间循环引用的问题，这些对象不会被发现，因此也就被自动回收了。
在这种方式下，Java 虚拟机采用了一种自适应的垃圾回收技术。至于如何处理找到的存活对象，取决于不同的 Java 虚拟机实现。其中有一种做法叫做停止-复制（stop-and-copy）。顾名思义，这需要先暂停程序的运行（不属于后台回收模式），然后将所有存活的对象从当前堆复制到另一个堆，没有复制的就是需要被垃圾回收的。另外，当对象被复制到新堆时，它们是一个挨着一个紧凑排列，然后就可以按照前面描述的那样简单、直接地分配新空间了。
当对象从一处复制到另一处，所有指向它的引用都必须修正。位于栈或静态存储区的引用可以直接被修正，但可能还有其他指向这些对象的引用，它们在遍历的过程中才能被找到（可以想象成一个表格，将旧地址映射到新地址）。
这种所谓的"复制回收器"效率低下主要因为两个原因。其一：得有两个堆，然后在这两个分离的堆之间来回折腾，得维护比实际需要多一倍的空间。某些 Java 虚拟机对此问题的处理方式是，按需从堆中分配几块较大的内存，复制动作发生在这些大块内存之间。
其二在于复制本身。一旦程序进入稳定状态之后，可能只会产生少量垃圾，甚至没有垃圾。尽管如此，复制回收器仍然会将所有内存从一处复制到另一处，这很浪费。为了避免这种状况，一些 Java 虚拟机会进行检查：要是没有新垃圾产生，就会转换到另一种模式（即"自适应"）。这种模式称为标记-清扫（mark-and-sweep），Sun 公司早期版本的 Java 虚拟机一直使用这种技术。对一般用途而言，"标记-清扫"方式速度相当慢，但是当知道程序只会产生少量垃圾甚至不产生垃圾时，它的速度就很快了。
"标记-清扫"所依据的思路仍然是从栈和静态存储区出发，遍历所有的引用，找出所有存活的对象。但是，每当找到一个存活对象，就给对象设一个标记，并不回收它。只有当标记过程完成后，清理动作才开始。在清理过程中，没有标记的对象将被释放，不会发生任何复制动作。"标记-清扫"后剩下的堆空间是不连续的，垃圾回收器要是希望得到连续空间的话，就需要重新整理剩下的对象。
"停止-复制"指的是这种垃圾回收动作不是在后台进行的；相反，垃圾回收动作发生的同时，程序将会暂停。在 Oracle 公司的文档中会发现，许多参考文献将垃圾回收视为低优先级的后台进程，但是早期版本的 Java 虚拟机并不是这么实现垃圾回收器的。当可用内存较低时，垃圾回收器会暂停程序。同样，"标记-清扫"工作也必须在程序暂停的情况下才能进行。
如前文所述，这里讨论的 Java 虚拟机中，内存分配以较大的"块"为单位。如果对象较大，它会占用单独的块。严格来说，"停止-复制"要求在释放旧对象之前，必须先将所有存活对象从旧堆复制到新堆，这导致了大量的内存复制行为。有了块，垃圾回收器就可以把对象复制到废弃的块。每个块都有年代数来记录自己是否存活。通常，如果块在某处被引用，其年代数加 1，垃圾回收器会对上次回收动作之后新分配的块进行整理。这对处理大量短命的临时对象很有帮助。垃圾回收器会定期进行完整的清理动作——大型对象仍然不会复制（只是年代数会增加），含有小型对象的那些块则被复制并整理。Java 虚拟机会监视，如果所有对象都很稳定，垃圾回收的效率降低的话，就切换到"标记-清扫"方式。同样，Java 虚拟机会跟踪"标记-清扫"的效果，如果堆空间出现很多碎片，就会切换回"停止-复制"方式。这就是"自适应"的由来，可以给它个啰嗦的称呼："自适应的、分代的、停止-复制、标记-清扫"式的垃圾回收器。

创建对象的过程

创建对象的过程，假设有个名为 Dog 的类：

  1. 即使没有显式地使用 static 关键字，构造器实际上也是静态方法。所以，当首次创建 Dog 类型的对象或是首次访问 Dog 类的静态方法或属性时，Java 解释器必须在类路径中查找，以定位 Dog.class。
  2. 当加载完 Dog.class 后（这将创建一个 Class 对象），有关静态初始化的所有动作都会执行。因此，静态初始化只会在首次加载 Class 对象时初始化一次。
  3. 当用 new Dog() 创建对象时，首先会在堆上为 Dog 对象分配足够的存储空间。
  4. 分配的存储空间首先会被清零，即会将 Dog 对象中的所有基本类型数据设置为默认值（数字会被置为 0，布尔型和字符型也相同），引用被置为 null。
  5. 执行所有出现在字段定义处的初始化动作。
  6. 执行构造器。与"复用"相关，这可能会牵涉到很多动作，尤其当涉及继承的时候。

以上参考