jvm基础知识

hotspot jvm的架构图：

更详细的架构图：

以下分别介绍：
类加载子系统
运行时数据区
执行引擎中的编译器
执行引擎中的垃圾回收
本地方法

类加载子系统

下图所示是 加载Dog.class过程中调用各类加载器的过程和各类加载器class文件的路径

运行时数据区

运行时数据区包括：程序计数器，本地方法栈，虚拟机栈，堆，方法区
其中程序计数器/本地方法/虚拟机栈是线程独享的空间，堆和方法区是多线程共享空间

堆区详细信息如下

关于java中对象的存储：
在堆中的存储：


在栈中存储的是对象的引用，栈和堆中的对象定位方法如下

执行引擎中的编译器

JVM运行
JIT即时编译
1、动态编译（dynamic compilation）指的是“在运行时进行编译”；与之相对的是事前编译（ahead-of-time compilation，简称AOT），也叫静态编译（static compilation）。
2、JIT编译（just-in-time compilation）狭义来说是当某段代码即将第一次被执行时进行编译，因而叫“即时编译”。JIT编译是动态编译的一种特例。JIT编译一词后来被泛化，时常与动态编译等价；但要注意广义与狭义的JIT编译所指的区别。
3、自适应动态编译（adaptive dynamic compilation）也是一种动态编译，但它通常执行的时机比JIT编译迟，先让程序“以某种式”先运行起来，收集一些信息之后再做动态编译。这样的编译可以更加优化。

为什么HotSpot虚拟机要使用解释器与编译器并存的架构？

尽管并不是所有的Java虚拟机都采用解释器与编译器并存的架构，但许多主流的商用虚拟机（如HotSpot），都同时包含解释器和编译器。解释器与编译器两者各有优势：

当程序需要迅速启动和执行的时候，解释器可以首先发挥作用，省去编译的时间，立即执行。在程序运行后，随着时间的推移，编译器逐渐发挥作用，把越来越多的代码编译成本地代码之后，可以获取更高的执行效率。

当程序运行环境中内存资源限制较大（如部分嵌入式系统中），可以使用解释器执行节约内存，反之可以使用编译执行来提升效率。此外，如果编译后出现“罕见陷阱”，可以通过逆优化退回到解释执行。

为何HotSpot虚拟机要实现两个不同的即时编译器？

HotSpot虚拟机中内置了两个即时编译器：Client Complier和Server Complier，简称为C1、C2编译器，分别用在客户端和服务端。目前主流的HotSpot虚拟机中默认是采用解释器与其中一个编译器直接配合的方式工作。程序使用哪个编译器，取决于虚拟机运行的模式。HotSpot虚拟机会根据自身版本与宿主机器的硬件性能自动选择运行模式，用户也可以使用“-client”或“-server”参数去强制指定虚拟机运行在Client模式或Server模式。

**用Client Complier获取更高的编译速度，用Server Complier 来获取更好的编译质量。**为什么提供多个即时编译器与为什么提供多个垃圾收集器类似，都是为了适应不同的应用场景。

哪些程序代码会被编译为本地代码？如何编译为本地代码？

运行过程中会被即时编译器编译的**“热点代码”**有两类：
1、被多次调用的方法。
2、被多次执行的循环体。
两种情况，编译器都是以整个方法作为编译对象。 这种编译方法因为编译发生在方法执行过程之中，因此形象的称之为栈上替换（On Stack Replacement，OSR），即方法栈帧还在栈上，方法就被替换了。

HotSpot虚拟机中使用的是哪钟热点检测方式呢？

方法调用计数器
当编译工作完成之后，这个方法的调用入口地址就会系统自动改写成新的，下一次调用该方法时就会使用已编译的版本。

回边计数器
它的作用就是统计一个方法中循环体代码执行的次数，在字节码中遇到控制流向后跳转的指令称为“回边”。

执行引擎中的垃圾回收器

试别垃圾的算法：
引用计数法
在对象头处维护一个counter，每增加一次对该对象的引用计数器自加，如果对该对象的引用失联，则计数器自减。当counter为0时，表明该对象已经被废弃，不处于存活状态。
可达性分析
通过一系列为GC Roots的对象作为起始点，从这些节点开始向下搜索，搜索所走过的路径称为引用链，当一个对象到GC Roots没有任何引用链相连时，则证明该对象是不可用的。

清除垃圾的算法：
标记清除算法

复制算法

标记整理算法

分代回收算法

垃圾收集器
在JVM中，GC是由垃圾回收器来执行，所以，在实际应用场景中，我们需要选择合适的垃圾收集器，下面我们介绍一下垃圾收集器。

并发/并行的解释
并发：GC线程和其他线程一起运行
并行：多个GC线程运行

1. 串行收集器（Serial GC）

   Serial GC是最古老也是最基本的收集器，但是现在依然广泛使用，JAVA SE5和JAVA SE6中客户端虚拟机采用的默认配置。比较适合于只有一个处理器的系统。在串行处理器中minor和major GC过程都是用一个线程进行回收的。它的最大特点是在进行垃圾回收时，需要对所有正在执行的线程暂停（stop the world），对于有些应用是难以接受的，但是如果应用的实时性要求不是那么高，只要停顿的时间控制在N毫秒之内，大多数应用还是可以接受的，而且事实上，它并没有让我们失望，几十毫秒的停顿，对于我们客户机是完全可以接受的，该收集器适用于单CPU、新生代空间较小且对暂停时间要求不是特别高的应用上，是client级别的默认GC方式。

2. ParNew GC

   基本和Serial GC一样，但本质区别是加入了多线程机制，提高了效率，这样它就可以被用于服务端上（server），同时它可以与CMS GC配合，所以，更加有理由将他用于server端。

3. Parallel Scavenge GC

   在整个扫描和复制过程采用多线程的方式进行，适用于多CPU、对暂停时间要求较短的应用，是server级别的默认GC方式。

4. CMS (Concurrent Mark Sweep)收集器

   该收集器的目标是解决Serial GC停顿的问题，以达到最短回收时间。常见的B/S架构的应用就适合这种收集器，因为其高并发、高响应的特点，CMS是基于标记-清楚算法实现的。

CMS收集器的优点：并发收集、低停顿，但远没有达到完美；
CMS收集器的缺点：
a.CMS收集器对CPU资源非常敏感，在并发阶段虽然不会导致用户停顿，但是会占用CPU资源而导致应用程序变慢，总吞吐量下降。
b.CMS收集器无法处理浮动垃圾，可能出现“Concurrnet Mode Failure”，失败而导致另一次的Full GC。
c.CMS收集器是基于标记-清除算法的实现，因此也会产生碎片。

5. G1收集器

   相比CMS收集器有不少改进，首先，基于标记-压缩算法，不会产生内存碎片，其次可以比较精确的控制停顿。
   

6. Serial Old收集器

   Serial Old是Serial收集器的老年代版本，它同样使用一个单线程执行收集，使用“标记-整理”算法。主要使用在Client模式下的虚拟机。

7. Parallel Old收集器

   Parallel Old是Parallel Scavenge收集器的老年代版本，使用多线程和“标记-整理”算法。

8. RTSJ垃圾收集器

   RTSJ垃圾收集器，用于Java实时编程。

新生代和老年代使用的垃圾回收器组合

常用的垃圾回收器的调优参数

本地方法接口（JNI）

**一个Native Method 就是一个java调用非java代码的接口。**该方法的实现由非java语言实现，比如C 。定义一个native method时，并不提供实现体，因为由非java实现。
本地接口的作用是融合不同的编程语言为java所用。

为什么使用本地方法？

1/与java环境外交互
有时java应用需要与java外面的环境交互，这是本地方法存在的主要原因。java需要与一些底层系统比如操作系统或某些硬件交换信息，本地方法正是这样一种交流机制，它为我们提供了一个非常简洁的接口，而且我们无需区了解java应用外的复杂细节

2/与操作系统交互
jvm并非一个真实的操作系统，需要依赖具体的操作系统去实现，通过本地方法，可以利用java实现了jre的与底层系统的交互。

参考：
https://blog.csdn.net/weixin_42385705/article/details/106300406
https://blog.csdn.net/sunxianghuang/article/details/52094859
https://blog.csdn.net/aijiudu/article/details/72991993