JVM总结-CSDN博客

本文链接：https://blog.csdn.net/qq_40656540/article/details/115541841

JVM的架构模型
第一章 JVM和Java体系架构 https://blog.csdn.net/sj15814963053/article/details/109767096
第二章 - 类加载器子系统 https://blog.csdn.net/sj15814963053/article/details/109851454
第三章 - 运行时数据区概述及线程 https://blog.csdn.net/sj15814963053/article/details/109862266
第四章 - 程序计数器 https://blog.csdn.net/sj15814963053/article/details/109864077
第五章 - 虚拟机栈 https://blog.csdn.net/sj15814963053/article/details/109922984
第六章 - 本地方法接口 https://blog.csdn.net/sj15814963053/article/details/110246378
第七章 - 本地方法栈 https://blog.csdn.net/sj15814963053/article/details/110246443
第八章 - 堆 https://blog.csdn.net/sj15814963053/article/details/110246331
第九章 - 方法区 https://blog.csdn.net/sj15814963053/article/details/110371508
第十章 - 对象的实例化内存布局与访问定位 https://blog.csdn.net/sj15814963053/article/details/110389688?spm=1001.2014.3001.5502
第十一章 - 直接内存
https://blog.csdn.net/sj15814963053/article/details/110393383?spm=1001.2014.3001.5502

笔记：https://gitee.com/moxi159753/LearningNotes/tree/master/JVM

JVM01_概述、跨平台原理、分类、三大商业虚拟机
JVM02_类的加载、链接、初始化、类加载器分类、双亲委派机制、沙箱安全机制
JVM03_程序计数器、本地方法
JVM04_虚拟机栈概述、局部变量表、操作数栈、动态链接、方法的返回地址
JVM05_堆的概述、内存结构、复制算法、Minor|Major|Full GC、TLAB、参数总结
JVM06_方法区的概述、内部结构、演变、常量池、运行时常量池、垃圾回收
JVM07_ 对象的实例化、内存布局、访问定位、直接内存
JVM08_字符串常量池基本特性、内存分配、拼接操作、intern、StringTable垃圾回收
JVM09_执行引擎概述、机器码|指令|汇编语言、解释器、Jlt编译器及分类、AOT编译器
JVM10_引用计数法、GCROOT、finalization机制、复制、标记清除、标记压缩算法、分代收集、增量收集、分区算法
JVM11_System.gc、内存溢出、内存泄漏、STW、安全点、安全区域、强软弱虚引用
JVM12_垃圾收集概述、Serial、SerialOld、ParNew、Parallel、ParallelOld、CMS、G1、详解-XX:+PrintGCDetails
JVM13_字节码文件的跨平台、前端编译器、什么是字节码指令
JVM14_Class文件结构细节、魔数、Class文件版本、常量池、访问标识(或标志)、类索引|父类索引|接口索引集合、字段|方法|属性表集合
JVM15_类的生命周期、类的加载、链接、初始化、使用、卸载、主动使用、被动使用
JVM16_类的概述、分类、ClassLoader源码分析、自定义类的加载器、双亲委派机制、沙箱安全机制
————————————————
版权声明：本文为CSDN博主「TZ845195485」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/TZ845195485/article/details/93238857

JVM指令文档，及其他
 阿里使用堆外空间，可以实现JVM间的数据共享（进程间的通信）

动态链接的理解
 如何查看java中native方法的实现？
如何找JDK中native代码的位置？
java中native方法

内存异常OOM，代码层面异常

方法区放的是对象信息，如何会出现OOM

/**
 * jdk6/7中：
 * -XX:PermSize=10m -XX:MaxPermSize=10m
 *
 * jdk8中：
 * -XX:MetaspaceSize=10m -XX:MaxMetaspaceSize=10m
 */
public class OOMTest extends ClassLoader {
    public static void main(String[] args) {
        int j = 0;
        try {
            OOMTest test = new OOMTest();
            for (int i = 0; i < 10000; i++) {
                //创建ClassWriter对象，用于生成类的二进制字节码
                ClassWriter classWriter = new ClassWriter(0);
                //指明版本号，修饰符，类名，包名，父类，接口
                classWriter.visit(Opcodes.V1_8, Opcodes.ACC_PUBLIC, "Class" + i, null, "java/lang/Object", null);
                //返回byte[]
                byte[] code = classWriter.toByteArray();
                //类的加载
                test.defineClass("Class" + i, code, 0, code.length); //Class对象
                j++;
            }
        } finally {
            System.out.println(j);
        }
    }
}

java是跨平台的语言
JVM是跨语言的平台，可以支持多种语言，groovy,scala,js,java;各个语言只需要提供自己的编译器
java不是最强大的语言，JVM是最强大的虚拟机
信息产业里面的三大技术难题：cpu，操作系统，编译器
书：自己动手写JAVA虚拟机
市面上三大虚拟机：hotspot, jRockit, (IBM)J9
openJDK只维护半年，oracleJDK维护三年（需付费）
大体上，虚拟机可以分为系统虚拟机和程序虚拟机。
javap -v xxx.class 查看指令
class文件的开头， CAFE BABE

Idea插件 jclasslib查看二进制文件

一个JVM实例，就是一个RUNTIME实例，一个RUNTIME对象，就相当于一个运行时数据区

Parallel回收器：吞吐量优先

和ParNew收集器不同，ParallelScavenge吞吐量优先的垃圾收集器。
自适应调节策略也是Paralle Scavenge与ParNew一个重要区别。
Parallel old收集器采用了标记-压缩算法，但同样也是基于并行回收和"stop-the-World"机制。

在程序吞吐量优先的应用场景中，IParalle1收集器和Parallel old收集器的组合，在server模式下的内存回收性能很不错。在Java8中，默认是此垃圾收集器。

-XX:ParallelGcrhreads设置年轻代并行收集器的线程数。一般地，最好与CPU数量相等，以避免过多的线程数影响垃圾收集性能。

-XX:MaxGCPauseMillis 设置垃圾收集器最大停顿时间（即STw的时间）。单位是毫秒。

-XX:GCTimeRatio垃圾收集时间占总时间的比例（=1/（N+1））。用于衡量吞吐量的大小。
-XX:+UseAdaptivesizepplicy 设置Parallel scavenge收集器具有自适应调节策略

在这种模式下，年轻代的大小、Eden和Survivor的比例、晋升老年代的对象年龄等参数会被自动调整，已达到在堆大小、吞吐量和停顿时间之间的平衡点。

CMS回收器：低延迟

它第一次实现了让垃圾收集线程与用户线程同时工作。
CMS的垃圾收集算法采用标记-清除算法，并且也会"stop-the-world"
CMS整个过程比之前的收集器要复杂，整个过程分为4个主要阶段，即初始标记阶段、并发标记阶段、重新标记阶段和并发清除阶段。

另外，由于在垃圾收集阶段用户线程没有中断，所以在CMS回收过程中，还应该确保应用程序用户线程有足够的内存可用。因此，CMS收集器不能像其他收集器那样等到老年代几乎完全被填满了再进行收集，而是当堆内存使用率达到某一阈值时，便开始进行回收，以确保应用程序在CMS工作过程中依然有足够的空间支持应用程序运行。要是CMS运行期间预留的内存无法满足程序需要，就会出现一次“Concurrent Mode Failure” 失败，这时虚拟机将启动后备预案：临时启用Serial old收集器来重新进行老年代的垃圾收集，这样停顿时间就很长了。
-XX:CMSInitiatingoccupanyFraction 设置堆内存使用率的阈值，一旦达到该阈值，便开始进行回收。
-XX：+UseCMSCompactAtFullCollection用于指定在执行完FullGC后对内存空间进行压缩整理，以此避免内存碎片的产生。不过由于内存压缩整理过程无法并发执行，所带来的问题就是停顿时间变得更长了。

-XX:CMSFullGCsBeforecompaction 设置在执行多少次FullGC后对内存空间进行压缩整理。
-XX:ParallelcMSThreads 设置cMs的线程数量。

-XX:CMSInitiatingoccupanyFraction 设置堆内存使用率的阈值，一旦达到该阈值，便开始进行回收。JDK6及以上版本默认值为92%

如果内存增长缓慢，则可以设置一个稍大的值，大的阀值可以有效降低CMS的触发频率，减少老年代回收的次数可以较为明显地改善应用程序性能。反之，如果应用程序内存使用率增长很快，则应该降低这个阈值，以避免频繁触发老年代串行收集器。因此通过该选项便可以有效降低Ful1Gc的执行次数。

G1回收器：区域化分代式

因为G1是一个并行回收器，它把堆内存分割为很多不相关的区域（Region）（物理上不连续的）。使用不同的Region来表示Eden、幸存者0区，幸存者1区，老年代等。

G1 GC有计划地避免在整个Java堆中进行全区域的垃圾收集。G1跟踪各个Region里面的垃圾堆积的价值大小（回收所获得的空间大小以及回收所需时间的经验值），在后台维护一个优先列表，每次根据允许的收集时间，优先回收价值最大的Region。

由于这种方式的侧重点在于回收垃圾最大量的区间（Region），所以我们给G1一个名字：垃圾优先（Garbage First）。

G1（Garbage-First）是一款面向服务端应用的垃圾收集器，主要针对配备多核CPU及大容量内存的机器，以极高概率满足GC停顿时间的同时，还兼具高吞吐量的性能特征。

在JDK1.7版本正式启用，移除了Experimenta1的标识，是JDK9以后的默认垃圾回收器。

G1垃圾收集器的优点
与其他GC收集器相比，G1使用了全新的分区算法，其特点如下所示：

并行与并发

并行性：G1在回收期间，可以有多个GC线程同时工作，有效利用多核计算能力。此时用户线程STW
并发性：G1拥有与应用程序交替执行的能力，部分工作可以和应用程序同时执行，因此，一般来说，不会在整个回收阶段发生完全阻塞应用程序的情况
分代收集

将堆空间分为若干个区域（Region），这些区域中包含了逻辑上的年轻代和老年代。
从堆的结构上看，它不要求整个Eden区、年轻代或者老年代都是连续的，也不再坚持固定大小和固定数量。

从分代上看，G1依然属于分代型垃圾回收器，它会区分年轻代和老年代，年轻代依然有Eden区和Survivor区。

和之前的各类回收器不同，它同时兼顾年轻代和老年代。对比其他回收器，其他回收器或者工作在年轻代，或者工作在老年代；
空间整合
可预测的停顿时间模型，这是G1相对于CMS的另一大优势，G1除了追求低停顿外，还能建立可预测的停顿时间模型，能让使用者明确指定在一个长度为M毫秒的时间片段内，消耗在垃圾收集上的时间不得超过N毫秒。

G1无论是为了垃圾收集产生的内存占用（Footprint）还是程序运行时的额外执行负载（overload）都要比CMS要高。
从经验上来说，**在小内存应用上CMS的表现大概率会优于G1，而G1在大内存应用上则发挥其优势。**平衡点在6-8GB之间。

优先调整堆的大小让JVM自适应完成。
而G1GC可以采用应用线程承担GC工作，即当JVM的GC线程处理速度慢时，系统会调用应用程序线程帮助加速垃圾回收过程。

Remembered Set（记忆集）
解决一个对象被不同区域引用的问题
无论G1还是其他分代收集器，JVM都是使用Remembered Set来避免全局扫描：
官方文档
 TIOBE 排行榜