深入理解java虚拟机 下载_深入理解Java虚拟机

深入理解Java虚拟机电子版

深入理解Java虚拟机电子版，全书共分为五大部分，统介绍了Java的技术体系、发展历程、虚拟机家族，以及动手编译JDK，了解这部分内容能对学习JVM提供良好的指引，里面还有更多的精彩内容，感兴趣的就快来下载吧

内容简介

《深入理解Java虚拟机:JVM高级特性与最佳实践》内容简介：作为一位Java程序员，你是否也曾经想深入理解Java虚拟机，但是却被它的复杂和深奥拒之门外？没关系，本书极尽化繁为简之妙，

能带领你在轻松中领略Java虚拟机的奥秘。本书是近年来国内出版的唯一一本与Java虚拟机相关的专著，也是唯一一本同时从核心理论和实际运用这两个角度去探讨Java虚拟机的著作，

不仅理论分析得透彻，而且书中包含的典型案例和最佳实践也极具现实指导意义。

全书共分为五大部分。第一部分从宏观的角度介绍了整个Java技术体系的过去、现在和未来，以及如何独立地编译一个OpenJDK7，这对理解后面的内容很有帮助。第二部分讲解了JVM的自动内存管理，

包括虚拟机内存区域的划分原理以及各种内存溢出异常产生的原因；常见的垃圾收集算法以及垃圾收集器的特点和工作原理；常见的虚拟机的监控与调试工具的原理和使用方法。

第三部分分析了虚拟机的执行子系统，包括Class的文件结构以及如何存储和访问Class中的数据；虚拟机的类创建机制以及类加载器的工作原理和它对虚拟机的意义；

虚拟机字节码的执行引擎以及它在实行代码时涉及的内存结构。第四部分讲解了程序的编译与代码的优化，阐述了泛型、自动装箱拆箱、条件编译等语法糖的原理；

讲解了虚拟机的热点探测方法、HotSpot的即时编译器、编译触发条件，以及如何从虚拟机外部观察和分析JIT编译的数据和结果。第五部分探讨了Java实现高效并发的原理，

包括JVM内存模型的结构和操作；原子性、可见性和有序性在Java内存模型中的体现；先行发生原则的规则和使用；线程在Java语言中的实现原理；虚拟机实现高效并发所做的一系列锁优化措施。

各章节的内容介绍

第一部分(第1章)走近Java

系统介绍了Java的技术体系、发展历程、虚拟机家族，以及动手编译JDK，了解这部分内容能对学习JVM提供良好的指引。

第二部分(第2~5章)自动内存管理

详细讲解了Java的内存区域与内存溢出、垃圾收集器与内存分配策略、虚拟机性能监控与故障排除等与自动内存管理相关的内容，以及10余个经典的性能优化案例和优化方法；

第三部分(第6~9章)虚拟机执行子系统

深入分析了虚拟机执行子系统，包括类文件结构、虚拟机类加载机制、虚拟机字节码执行引擎，以及多个类加载及其执行子系统的实战案例；

第四部分(第10~11章)程序编译与代码优化

详细讲解了程序的前、后端编译与优化，包括前端的易用性优化措施，如泛型、主动装箱拆箱、条件编译等的内容的深入分析；以及后端的性能优化措施，如虚拟机的热点探测方法、HotSpot 的即时编译器、提前编译器，以及各种常见的编译期优化技术；

第五部分(第12~13章)高效并发

主要讲解了Java实现高并发的原理，包括Java的内存模型、线程与协程，以及线程安全和锁优化。

全书以实战为导向，通过大量与实际生产环境相结合的案例分析和展示了解决各种Java技术难题的方案和技巧。

深入理解Java虚拟机电子版图片预览

《深入理解Java虚拟机》读书总结

前面每读完一章就整理了一篇笔记，感觉比较乱。这次读完之后总结了一下，对整个Java虚拟机有了系统性的理解。

首先，java程序可以“一次编写，到处运行”就是因为有Java虚拟机这个东西作为容器。Java虚拟机作为一个中间层，向上接受由我们编写的代码生成的字节码，

向下给机器提供可以被直接执行的目标代码，这就有了Java的“平台无关性”的基础。通过这个定义我们知道，一切可以编译出字节码的语言都可以获得这种“平台无关性”，

也就是说像一些类Java语言比如Groovy Scala等，因为用他们也可以生成字节码，所以也可以用Java虚拟机来执行，也就具有了平台无关性。所以Java虚拟机并不只是为Java这一种语言服务的，

他在一开始被创造出来的时候就被明确要具有这种拓展性。Android虚拟机其实也就是Java虚拟机的一种衍生，通过学习Java虚拟机对Android开发也是有帮助的。Java虚拟机对Java的支持可以从以下几个方面来讲：内存管理机制，类加载机制和优化。

内存管理

先说内存管理。内存管理，就是Java虚拟机在运行时管理如何为程序划分内存区域，如何分配内存，内存用完如何回收。

内存区域

先讲一下内存区域的划分。Java虚拟机把内存分为很多数据区域，不同的区域用途和生存周期不同。我们常常直接接触到的是运行时数据区，可以细分为：方法区、堆、虚拟机栈、

本地方法栈、程序计数器。这几个区域中，方法区和堆是所有线程共享的，所有线程都可以访问，而虚拟机栈、本地方法栈、程序计数器是线程隔离的，每个线程有自己独立的区域，线程之间是不共享的。

程序计数器：相当于一个程序执行过程中的行号指示器，类似于操作系统中的ip，指向当前执行的虚拟机字节码地址。如果执行的是Java方法，计数器就记录者正在执行的虚拟机字节码指令的地址。如果是native 方法，计数器为空

虚拟机栈：虚拟机栈就是java方法的内存模型，每一个线程在执行时会有自己的一个虚拟机栈，在运行过程中把所调用方法封装为一个栈帧，然后将栈帧存放在栈里面。栈帧包含了一个方法执行时的相关信息，包括方法用到的局部变量，操作数，动态链接等。

本地方法栈：类似于虚拟机栈，只不过他存放的是Native方法。

堆：堆是相对来说占内存最大的一块，用来存放所有线程创建的类的对象实例。方法调用中如果创建了对象，会把这个对象实例存放在堆，然后将对于这个对象的引用存放在栈中，这样就可以方法对象了。对于内存的回收，也就是对堆内存的回收了。

方法区：存放虚拟机加载的类的信息和一些常量、静态变量等，这些内容一般是不可变的。

OOM和StackOverFlow

OOM和StackOverFlow就是在运行时数据区出现的。前面说了，虚拟机栈会把每次调用的方法作封装为一个栈帧存起来。这些栈帧肯定是要占内存的，而栈的内存也是有限的。

如果栈帧很多一直没有释放，这时候又来了一个栈帧，这个栈帧已经没有空间可以容纳了，有两种情况。如果这种虚拟机栈不支持动态扩展，那么将会抛出StackOverFlow异常。如果支持动态扩展，

那么这个栈会请求再扩展部分空间。当然内存不是无穷的，如果频繁的扩展内存，以至于无法再继续扩展了，这时候会抛出OutOfMemory异常。

除此之外，堆得空间也是有限的。由于创建的对象都是要在堆中分配内存，那么如果堆中空间不足，没有足够的内存空间用来给新的对象分配内存，这时候也会抛出OutOfMemory异常。

内存分配与回收

创建一个对象，就在堆中给这个内存分配一块内存。当对象不再被使用，所占的内存就被回收，用来给其他对象。要回收内存，就要知道哪些对象会被回收，什么时候会被回收，回收的具体算法是怎么一个操作。

对象的创建——分代

一个对象的创建过程很简单，比如我new一个对象，虚拟机发现这条指令后，会先看看new 后面跟着的那个参数能否在常量池中定位到一个类的符号引用，并且检查那个类是否已经被加载过。

如果没有，则进行一次类的加载工作(具体细节后面会讲)。加载完成后，虚拟机会为新的对象在堆中分配一块内存，具体分配多少，在类加载完之后其实就已经定了。分配完内存，

之后会将这个对象的实例字段初始化为零值。最后，会对对象进行一些设置，比如设置哈希码，分代年龄信息，这个对象属于哪个类之类的。

这一系列工作做完，这个对象才算是被创建成功了，之后才会去调用相关代码，按照我们的意愿真正做一次初始化。

创建好一个对象，还需要一个引用来持有他，这样我们才能使用。引用是放在虚拟机栈 栈帧的本地变量表中的。引用有两种形式，一种是直接持有对象地址，一种是持有一个句柄，句柄保存在堆中，

包含着对象的地址，是间接访问。直接访问速度快，间接访问在对象频繁移动时比较有优势。

哪些对象会被回收？——可达性分析算法

选择回收哪些对象，虚拟机有很多算法，常见的有引用计数法和可达性分析算法。引用计数法的思路就是为每一个对象设一个值，用来计算被引用的次数。只要有一个对于对象的引用存在，就让这个数字加一。

这样如果一个对象没有任何引用，那么引用计数为零，这个对象就会被标记为“可回收”。但是这样有一个很严重的bug，那就是如果我有两个对象，已经不再使用，但是他们互相引用，那么他们的引用计数就永远不会为零，那么就不会被回收。

现在大部分虚拟机都采用了“可达性分析算法”，这一算法显然要比引用计数法不知道高到哪里去了。他的思想是，将一些特定的对象作为GC Roots，然后从这个节点向下寻找对其他对象的引用。

如果一个对象到GC Roots没有引用链，那么就可以被回收了。在Java虚拟机中，被规定作为GC Roots的对象有：

虚拟机栈中引用的对象

方法区中 静态属性引用的对象

方法区中 常量引用的对象

JNI引用的对象

所以我们日常开发过程中遇到的内存泄漏，很大一部分原因就是本该被回收的对象无意之中被GC Roots引用到了，比如写的static这样的静态字段引用的对象，这样他就不会被回收了

回收的算法？——多种混合

知道哪些对象要被回收，接下来就是具体如何回收的问题了。垃圾回收算法有很多，常见的有标记-清除法，标记-整理法，复制算法，分代收集等。现在的虚拟机基本上都是采用以分代收集为基础，

搭配其他算法一起合作完成的。这些算法就不一一介绍了，有兴趣大家可以查一查。

具体：根据对象的生存周期对内存划分为新生代 老生代，在新生代中因为每次都会有大量对象被回收，比较频繁，因此采用了复制算法。而老生代相对来说回收的对象少，没那么频繁，而且对象普遍比较大，因此采用了标记-清楚或标记-整理算法。

回收的过程？——双重标记

具体的回收过程是，当在GC时发现一个对象可被回收，就会先对他做一次标记，这是第一次标记。之后会筛选一下，如果一个对象的finalized()方法是否有必要被执行。如果有，那么就会被放置到一个队列中，

之后虚拟机会单独的处理这一队列中的对象，依次调用他们的finalized()方法，这里是对象复活的唯一机会。之后又会统一进行一次标记，如果这次标记标记成功，那么对象就会被认定为死亡，会立刻被回收。

GC的时机？——动态年龄判定

虚拟机针对对内存回收，又把堆分为了两个区，新生代和老年代。新生代又分为一个Eden区和两个Survivor区。每次分配内存，如果对象比较大的话直接进入老年代。否则，先进入Eden区和一个Survivor区，

同时会为每一个对象设一个年龄值。之后会周期性的在某个安全点检查一下，对于新生代的对象，将可回收的对象回收掉，将剩余的对象复制到另一个Survivor区，这一过程中会对年龄值加一。这一过程叫做Minor GC，

是属于新生代的GC。当某些对象年龄值比较大时，会将他们移动到老年代去。当然在这之前会先查看一下老年代剩余空间是否满足移动。如果不能满足，就会对老年代进行一次GC，这一过程叫做Full GC。而这个检查对象是否可GC得时机，也就是GC的时机，

一般是确定的被称作“安全点”。在这一时机进行检查，是不会影响程序正常运行的。

灵活的控制——四大引用

GC的流程大致就是这样。我们知道Java中引用有四种，分别是强、软、弱、虚。这四种引用的区别就在于GC的过程中：

强引用：直接通过类名new一个对象，这样直接创建的对对象的引用叫做强引用。被强引用的对象，一般是不会被回收掉的。

软引用：被软引用持有的对象，只有在“不回收就要内存溢出”的时候，才会回收

弱引用：被弱引用持有的对象，在每次GC都会被回收

虚引用：无任何时机作用，只是一个标记，为了能使对象被回收时做一些系统通知什么的

类加载机制

Java实现平台无关性的基石，就是字节码。在Java虚拟机中，有一个class文件这个概念。一般情况下，每一个类都会产生一个class文件，其内容就是字节码。虚拟机执行字节码，

其实就是加载了类的class文件。Android中有两种虚拟机，Dalvik虚拟机和ART虚拟机。他们属于Java虚拟机的衍生，区别在于两个：

Java虚拟机是基于栈架构的，DVM和ART是基于寄存器架构的

Java虚拟机执行的是字节码，而DVM ART都不一样。DVM会将class文件重新封装为dex文件，执行dex字节码。ART会在DVM的基础上进一步转化为本地机器码再执行。

类加载，就是说加载每一个class，而和class相对应的也就是class文件了，所以有必要大致了解一下class文件结构。

Class文件结构

任何一个class文件都对应着唯一一个类或者接口的定义信息。但是类或者接口又不必一定非要在class文件中(比如动态的通过类加载器加载)。class文件是一组二进制流，

其中包含额类的虽有相关信息，非常紧凑的排列在一起，很严格的规定了第几位到第几位是什么，主要包含了魔数，常量池等数据信息。

这不部分内容看起来还是很无聊的，主要关注其中一部门就好啦。比如一开头的4个字节是魔数，魔数的唯一作用是确定这个文件是否可以被虚拟机接受。

还比如，其中有一段被称为常量池入口，这个很重要了。常量池是class文件结构与其他项目关联最多的数据类型，相当于一个资源池。通过这个常量池入口，可以获得常量池信息。常量池具体而言，存放着两种类型：字面量和符号引用。

字面量：就是字面量，比如文本字符串这样的。

符号引用：包括三种常亮：类和接口的全限定名、字段的名称和描述符、方法的名称和描述符。

他们的作用就是在虚拟机运行时，通过常量池入口，在常量池中找到对应的符号引用，从而找到引用的类或者方法等。

类加载机制

类的生命周期氛围7个阶段：

加载 验证 准备 解析 初始化 使用 卸载

其中，验证 准备 解析 三个步骤又可以合并为 链接

所以类加载的过程就是 加载 链接 初始化了

加载的时机——按需加载

虚拟机并没有规定类的加载过程什么时候开始，只是明确了类加载的生命周期是固定的。但是比较特别的是“初始化”。我们需要用到一个类的时候，就一定要“初始化”，

而其他在他之前的步骤，自然也就必须要调用了。因此可以这样概括为：加载、验证、准备、解析，这个过程是不确定的，由不同虚拟机自己控制，可能不知道哪个时候就进行了。

但是当我们需要用到一个类时，就必须要立刻从加载开始执行到初始化结束，之后才能使用。

那么什么时候需要这个类呢，以下几种常见情况：

new一个对象，或者调用一个类的静态字段或者静态方法

反射调用一个类

子类加载前要先加载父类

虚拟机刚启动时执行主类

这些情况，都是属于对类的主动引用。

加载的过程——五步走

前面说过了，类的加载过程是类的生命周期前五个步骤：

加载：

通过一个类的全限定名来获取定义此类的二进制字节流

将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构

在内存中生成一个代表这个类的class对象，作为方法区这个类的各种数据访问入口

因为加载这个过程没有限制具体的来源，所以衍生出了很多新东西，比如Jar包的读取，从网络中加载类等。

这是对于简单类而言的。对于数组，不会通过类加载器加载，而是由虚拟机直接创建，之后才会递归的加载数组中的引用类。

验证：验证是链接过程的第一步，目的是确保Class文件的字节流中包含的信息符合当前虚拟机的要求，且不会危害虚拟机本身的安全。验证主要有四类：

文件格式验证：字节流是否符合Class文件格式规范

元数据验证：语义分析，符合语言规范

字节码验证：分析数据流，确定语义是合法的，符合逻辑的。

符号引用验证：验证符号引用合法性

准备：正式为类量分配内存并设置初值。类变量要分配在方法去中，设置初值的是类变量而不是实例变量。

解析：将常量池内的符号引用替换为直接引用。前面说过，符号引用只是以简单的通过名称等信息指出引用的方法或类，。那么在这里才会真正的将符号引用转换为直接引用，

即对于方法区类的引用。直接引用类似于指针，所以这一过程可以理解为从名称到地址的转化。

初始化：前面是加载和链接的过程，这里就是类加载过程的最后一步了。所谓的初始化阶段，就是真正执行在类中写的代码了。比如实例变量的初始化和构造器等。初始化阶段也可以理解为调用类的构造器的过程。

加载的工具——类加载器

前面说过，第一步“加载”过程，要通过一个类的全限定名来获取这个类的二进制字节流。这个过程，是要借助于一股虚拟机外部的工具来进行的，这一工具就是类加载器。每一个类，都有一个针对他的类加载器。两个类是否相同，不但要比较他本身，还要比较他们的类加载器。

类加载器可以分为三类：

启动类加载器：由C++编写，属于虚拟机的一部分，是属于很基础的加载器，回加载Java目录下lib中的类。

扩展类加载器：可以由开发者使用

应用类加载器：也叫做系统类加载器，加载用户类路径上自己指定的类，我们平时使用也基本是使用这个。

而具体的加载逻辑，被称为“双亲委派模型”，即首先有一个根部的加载器“启动类加载器”，其下有一个儿子叫“扩展类加载器”，其下是“应用程序类加载器”，最后是“自定义类加载器”。具体流程：

一个类收到了加载的请求，首先会把请求委托给父类加载，每一个加载器都是如此。这样最终会把请求交给根节点的“启动类加载器”。之后如果父加载器可以加载，就会直接加载。否则，会将请求再传下来。

虚拟机优化

Java的编译期，是一个极不确定的过程。因为Java的编译期很多，有前端编译期，有后端编译器，还有静态提前编译器。前端编译期负责将.java转化为简单的.class，

后端编译器负责将字节码转换为机器码，如JIT。静态提前编译器会将.java直接翻译为本地机器码，如AOT。因此，编译期并不能很精准的分类，因此只能大概分为“早期”和“晚期”。

早期优化

早期阶段，可以概括的看做前端编译器将.java转化为.class的过程。这一阶段的优化又可以称作编译期优化

这一阶段其实和其他语言的编译期优化类似，无非就是词法、语法分析，语义分析，然后做一些语言层面的优化。比如，语法糖、注解的处理，还有字符串拼接。Java语法糖不多，但是挺实用的，诸如类型擦除啊，自动拆箱、装箱啊。注解是在编译时进行优化，具体在运行时才会体现出作用。还有一个例子，我们都知道String StringBuilder StringBuffer区别。都说每次用"+"链接两个字符串的时候都会new一个String，这样会很耗内存。其实这个说法并不全对。如果仅仅是一个个拼接，哪怕是换行，编译器如果识别到，都会为我们优化，即将他们作为一个String对象。只有个别情况，比如在循环结构中频繁的链接字符串，才会出现刚才说的那个问题。

运行期优化

运行期优化，比较熟知的比如JIT和AOT。虚拟机之所以这样分开，是为了增加虚拟机扩展性，也就是说普通的前端编译期只接受Java。而后端编译器则可以接受像Groovy等语言。同时JIT和AOT对编译的性能优化很大，因此也就被选作Android中Java虚拟机所使用的编译器了。

先说JIT，他是将字节码转换为了机器码，这是DVM采用的编译器。他的特点可以打个比方，比如让你背一首诗，而且还要当着我的面背出来，还要重复背好几次，那么你肯定需要背好久，才能一次念出来。通过JIT，我可以让你照着书，看一个字背一句。这样背起来就很轻松了。但是JIT也不一定真的就远比普通的解释器执行慢。在JVM中，JIT是针对热点代码的，对于这些代码才会进行JIT编译。因此JIT就编译本身转化过程而言也是比较慢的，快是快在执行上。还是那个例子，如果只让你大概总结一下意思，就背几句诗，那么你翻书还不如直接背的快。而对于热点诗句，你能看一眼念一句，那么这个速度是相当快的。

再说AOT。AOT是直接将.java转换为本地机器码。拿上面那个例子来说，我给你的这篇古诗，其实你以前就背过一部分，所以现在再背一小部分就可以了，所以速度快，但是代价是，需要提前准备，因此占据脑容量大。

在Android中，以前的DVM采用了JIT，而现在的ART采用了AOT。具体区别在于DVM编译时，安装过程比较快，占空间小，但是执行比较慢。而AOT则是安装过程慢，占空间大，但是执行快。