HotSpot

目录

1. HotSpot历史

2.HotSpot基础知识

3.动态编译

4.为什么不静态编译那？

HotSpot的算法实现

1.枚举根节点

2.安全点

3.安全区域

---

文章转载自：https://blog.csdn.net/sch20095100/article/details/46591757

                      https://blog.csdn.net/dyr_1203/article/details/83311431?ops_request_misc=%257B%2522request%255Fid%2522%253A%2522158472576919724839217310%2522%252C%2522scm%2522%253A%252220140713.130056874..%2522%257D&request_id=158472576919724839217310&biz_id=0&utm_source=distribute.pc_search_result.none-task

1. HotSpot历史

    SUN的JDK版本从1.3.1开始运用HotSpot虚拟机， 2006年底开源，主要使用C++实现，JNI接口部分用C实现。
    HotSpot是较新的Java虚拟机，用来代替JIT(Just in Time)，可以大大提高Java运行的性能。 
    Java原先是把源代码编译为字节码在虚拟机执行，这样执行速度较慢。而HotSpot将常用的部分代码编译为本地(原生，native)代码，这样显着提高了性能。 
    HotSpot JVM 参数可以分为规则参数(standard options)和非规则参数(non-standard options)。 
    规则参数相对稳定，在JDK未来的版本里不会有太大的改动。 
    非规则参数则有因升级JDK而改动的可能。

    规则和非规则参数这里不做介绍了，网上资料很多。

2.HotSpot基础知识

    HotSpot包括一个解释器和两个编译器（client 和 server，二选一的），解释与编译混合执行模式，默认启动解释执行。

    编译器：java源代码被编译器编译成class文件（字节码），java字节码在运行时可以被动态编译（JIT）成本地代码(前提是解释与编译混合执行模式且虚拟机不是刚启动时)。

    解释器： 解释器用来解释class文件（字节码），java是解释语言（书上这么说的）。

    server启动慢，占用内存多，执行效率高，适用于服务器端应用；

    client启动快，占用内存小，执行效率没有server快，默认情况下不进行动态编译，适用于桌面应用程序。

    由-XX:+RewriteFrequentPairs参数控制  client模式默认关闭，server模式默认开启

    在jre安装目录下的lib/i386/jvm.cfg 文件下。

   java -version

   Java HotSpot(TM) Client VM (build 14.3-b01, mixed mode, sharing)

   mixed mode 解释与编译 混合的执行模式 默认使用这种模式

   java -Xint -version

   Java HotSpot(TM) Client VM (build 14.3-b01, interpreted mode, sharing)

   interpreted  纯解释模式 禁用JIT编译

   java -Xcomp -version

   Java HotSpot(TM) Client VM (build 14.3-b01, compiled mode, sharing)

   compiled  纯编译模式（如果方法无法编译，则回退到解释模式执行无法编译的方法）

3.动态编译

      动态编译(compile during run-time)，英文称Dynamic compilation；Just In Time也是这个意思。

      HotSpot对bytecode的编译不是在程序运行前编译的，而是在程序运行过程中编译的。
      HotSpot里运行着一个监视器（Profile Monitor），用来监视程序的运行状况。

      java字节码（class文件）是以解释的方式被加载到虚拟机中(默认启动时解释执行)。 程序运行过程中，那一部分运用频率大，那些对程序的性能影响重要。对程序运行效率影响大的代码，称为热点（hotspot），HotSpot会把这些热点动态地编译成机器码（native code），同时对机器码进行优化，从而提高运行效率。对那些较少运行的代码，HotSpot就不会把他们编译。

      HotSpot对字节码有三层处理：不编译(字节码加载到虚拟机中时的状态。也就是当虚拟机执行的时候再编译)，编译(把字节码编译成本地代码。虚拟机执行的时候已经编译好了，不要再编译了)，编译并优化（不但把字节码编译成本地代码，而且还进行了优化）。

       至于那些程序那些不编译，那些编译，那些优化，则是由监视器（Profile Monitor）决定。

4.为什么不静态编译那？

    为什么字节码在装载到虚拟机之前就编译成本地代码那？ 

    动态编译器也在许多方面比静态编译器优越。静态编译器通常很难准确预知程序运行过程中究竟什么部分最需要优化。

    函数调用都是很浪费系统时间的，因为有许多进栈出栈操作。因此有一种优化办法，就是把原来的函数调用，通过编译器的编译，改成非函数调用，把函数代码直接嵌到调用出，变成顺序执行。

    面向对象的语言支持多态，静态编译无效确定程序调用哪个方法，因为多态是在程序运行中确定调用哪个方法。

HotSpot的算法实现

1.枚举根节点

从可达性分析中从GC Roots节点找引用为例，可作为GC Roots的节点主要是全局性的引用与执行上下文中，如果要逐个检查引用，必然消耗时间。

另外可达性分析对执行时间的敏感还体现在GC停顿上，因为这项分析工作必须在一个能确保一致性的快照中进行——这里的“一致性”的意思是指整个分析期间整个系统执行系统看起来就行被冻结在某个时间点，不可以出现分析过程中对象引用关系还在不断变化的情况，该点不满足的话分析结果的准确性就无法得到保证。这点是导致GC进行时必须暂停所有Java执行线程的其中一个重要原因。
由于目前主流的Java虚拟机都是准确式GC，做一档执行系统停顿下来之后，并不需要一个不漏的检查执行上下文和全局的引用位置，虚拟机应当有办法得知哪些地方存放的是对象的引用。在HotSpot的实现中，是使用一组OopMap的数据结构来达到这个目的的。

2.安全点

在OopMap的协助下，HotSpot可以快速且准确的完成GC Roots的枚举，但可能导致引用关系变化的指令非常多，如果为每一条指令都生成OopMap，那将会需要大量的额外空间，这样GC的空间成本会变的很高。
实际上，HotSpot也的确没有为每条指令生成OopMap，只是在特定的位置记录了这些信息，这些位置被称为安全点（SafePoint）。SafePoint的选定既不能太少，以致让GC等待时间太久，也不能设置的太频繁以至于增大运行时负荷。所以安全点的设置是以让程序“是否具有让程序长时间执行的特征”为标准选定的。“长时间执行”最明显的特征就是指令序列的复用，例如方法调用、循环跳转、异常跳转等，所以具有这些功能的指令才会产生SafePoint。
对于SafePoint，另一个问题是如何在GC发生时让所有线程都跑到安全点在停顿下来。这里有两种方案：抢先式中断和主动式中断。抢先式中断不需要线程代码主动配合，当GC发生时，首先把所有线程中断，如果发现线程中断的地方不在安全点上，就恢复线程，让他跑到安全点上。现在几乎没有虚拟机实现采用抢先式中断来暂停线程来响应GC。
而主动式中断的思想是当GC需要中断线程的时候，不直接对线程操作，仅仅简单的设置一个标志，各个线程执行时主动去轮询这个标志，发现中断标志为真时就自己中断挂起，轮询标志的地方和安全点是重合的另外再加上创建对象需要分配的内存的地方。

3.安全区域

使用安全点似乎已经完美解决了如何进入GC的问题，但实际情况却并不一定，安全点机制保证了程序执行时，在不太长的时间内就会进入到可进入的GC的安全点。但是程序如果不执行呢？所谓的程序不执行就是没有分配cpu时间，典型的例子就是线程处于sleep状态或者blocked状态，这时候线程无法响应jvm中断请求，走到安全的地方中断挂起，jvm显然不太可能等待线程重新分配cpu时间，对于这种情况，我们使用安全区域来解决。
安全区域是指在一段代码片段之中，你用关系不会发生变化。在这个区域的任何地方开始GC都是安全的，我们可以把安全区域看做是扩展了的安全点。
当线程执行到安全区域中的代码时，首先标识自己已经进入了安全区，那样当在这段时间里，JVM要发起GC时，就不用管标识自己为安全区域状态的线程了。当线程要离开安全区域时，他要检查系统是否完成了根节点枚举，如果完成了，那线程就继续执行，否则他就必须等待，直到收到可以安全离开安全区域的信号为止。

本文内容主要是本人学习周志明老师的《深入理解Java虚拟机》一书的学习笔记，仅作学习巩固整理知识点使用，不作他用，在此感谢周老师。