Java代码有很多种不同的运行方式。比如说可以在开发工具中运行，可以双击执行jar文件运行，也可以在命令行中运行，甚至可以在网页。这些执行方式都离不开JRE，Java运行时环境。JRE仅包含运行Java程序的必需组件，包括Java虚拟机以及Java核心类库等。我们Java程序员经常接触到的JDK（Java开发工具包）同样包含了JRE，并且还附带了一系列开发、诊断工具。然而，运行C++代码则无需额外的运行时。往往把这些代码直接编译成CPU所能理解的代码格式，即机器码。比如下图的中间列，就是用C语言写的Helloworld程序的编译结果。C程序编译而成的机器码就是一个个的字节，它们是给机器读的。那为让开发人员也能理解，用反汇编器将其转换成汇编代码（如下图的最右列所示）。; 最左列是偏移；中间列是给机器读的机器码；最右列是给人读的汇编代码0x00:  55                    push   rbp0x01:  48 89 e5              mov    rbp,rsp0x04:  48 83 ec 10           sub    rsp,0x100x08:  48 8d 3d 3b 00 00 00  lea    rdi,[rip+0x3b]                                     ; 加载"Hello, World!\n"0x0f:  c7 45 fc 00 00 00 00  mov    DWORD PTR [rbp-0x4],0x00x16:  b0 00                 mov    al,0x00x18:  e8 0d 00 00 00        call   0x12                                    ; 调用printf方法0x1d:  31 c9                 xor    ecx,ecx0x1f:  89 45 f8              mov    DWORD PTR [rbp-0x8],eax0x22:  89 c8                 mov    eax,ecx0x24:  48 83 c4 10           add    rsp,0x100x28:  5d                    pop    rbp0x29:  c3                    ret为什么Java要在虚拟机里运行？Java作为一门高级程序语言，它的语法非常复杂，抽象程度也很高。因此，直接在硬件上运行这种复杂的程序并不现实。所以呢，在运行Java程序之前，需要对其进行一番转换。转换怎么操作设计一个面向Java语言特性的虚拟机，并通过编译器将Java程序转换成该虚拟机所能识别的指令序列，即Java字节码。之所以这么取名，是因为Java字节码指令的操作码（opcode）被固定为一个字节。下图的中间列，正是用Java写的Helloworld程序编译而成的字节码。可以看到，它与C版本的编译结果一样，都是由一个个字节组成的。同样可以将其反汇编为人类可读的代码格式（如下图的最右列所示）。Java版本的编译结果相对精简一些，Java虚拟机相对于物理机而言，抽象程度更高。# 最左列是偏移；中间列是给虚拟机读的机器码；最右列是给人读的代码0x00:  b2 00 02         getstatic java.lang.System.out0x03:  12 03            ldc "Hello, World!"0x05:  b6 00 04         invokevirtual java.io.PrintStream.println0x08:  b1               returnJava虚拟机常见的是在各个现有平台（如Windows_x64、Linux_aarch64）上提供软件实现。一旦一个程序被转换成Java字节码，便可在不同平台上的虚拟机实现里运行，即“一次编写，到处运行”。虚拟机的另外一个好处是它带来托管环境（Managed Runtime），代替我们处理一些代码中冗长而且容易出错的部分。自动内存管理与垃圾回收，这部分内容甚至催生了一波垃圾回收调优。托管环境还提供了诸如数组越界、动态类型、安全权限等等的动态检测。Java虚拟机具体是怎样运行Java字节码的？以标准JDK中的HotSpot虚拟机为例，从虚拟机以及底层硬件两个角度，给你讲一讲Java虚拟机具体是怎么运行Java字节码的。虚拟机视角，执行Java代码首先要将它编译而成的class文件加载到Java虚拟机。加载后的Java类会被存放于方法区（Method Area）。实际运行时，虚拟机会执行方法区内的代码。这和段式内存管理中的代码段类似。而且，Java虚拟机同样也在内存中划分出堆和栈来存储运行时数据。但Java虚拟机会将栈细分为面向Java方法的Java方法栈，面向本地方法（用C++写的native方法）的本地方法栈，以及存放各个线程执行位置的PC寄存器。运行过程中，每当调用进入一个Java方法，Java虚拟机会在当前线程的Java方法栈中生成一个栈帧，存放局部变量以及字节码的操作数。这个栈帧的大小是提前计算好的，而且Java虚拟机不要求栈帧在内存空间里连续分布。当退出当前执行的方法时，不管是正常返回、异常返回，Java虚拟机均会弹出当前线程的当前栈帧，并舍弃。硬件视角，Java字节码无法直接执行。因此，Java虚拟机需要将字节码翻译成机器码。HotSpot翻译过程有两种形式：解释执行，逐条将字节码翻译成机器码并执行无需等待编译即时编译（Just-In-Time compilation，JIT），将一个方法中包含的所有字节码编译成机器码后再执行实际运行速度更快HotSpot默认采用混合模式，综合了解释执行和即时编译两者的优点：先解释执行字节码，而后将其中反复执行的热点代码，以方法为单位进行即时编译。Java虚拟机的运行效率HotSpot采用了多种技术来提升启动性能以及峰值性能，即时编译便是其中最重要的技术之一。即时编译建立在程序符合二八定律，百分之二十的代码占据了百分之八十的计算资源。对占据大部分的不常用的代码，无需耗费时间将其编译成机器码，而是采取解释执行的方式运行对于仅占据小部分的热点代码，我们则可以将其编译成机器码，以达到理想运行速度。理论即时编译后的Java程序的执行效率，是可能超过C++。因为与静态编译相比，即时编译拥有程序的运行时信息，并且能够根据这个信息做出相应的优化。虚方法是用来实现多态性。对一个虚方法调用，尽管有很多目标方法，但实际运行过程中，可能只调用其中一个。这信息可被即时编译器所利用，规避虚方法调用的开销，达到比静态编译的C++程序更高的性能。为满足不同用户场景的需要，HotSpot内置了多个即时编译器：C1、C2和Graal。Graal是Java 10正式引入的实验性即时编译器。之所以引入多个即时编译器，为在编译时间和生成代码的执行效率之间进行取舍。C1又叫做Client编译器，面向对启动性能有要求的客户端GUI程序，采用的优化手段相对简单，因此编译时间较短。C2又叫做Server编译器，面向对峰值性能有要求的服务器端程序，采用的优化手段相对复杂，因此编译时间较长，但同时生成代码的执行效率较高。从Java 7开始，HotSpot默认采用分层编译的方式：热点方法首先会被C1编译，而后热点方法中的热点会进一步被C2编译。为了不干扰应用的正常运行，HotSpot的即时编译是放在额外的编译线程中进行的。HotSpot会根据CPU的数量设置编译线程的数目，并且按1:2的比例配置给C1及C2编译器。在计算资源充足的情况下，字节码的解释执行和即时编译可同时进行。编译完成后的机器码会在下次调用该方法时启用，以替换原本的解释执行。总结在虚拟机中运行，是因为它提供了可移植性。一旦Java代码被编译为Java字节码，便可以在不同平台上的Java虚拟机实现上运行。此外，虚拟机还提供了一个代码托管的环境，代替我们处理部分冗长而且容易出错的事务，例如内存管理。Java虚拟机将运行时内存区域划分为五个部分，分别为方法区、堆、PC寄存器、Java方法栈和本地方法栈。Java程序编译而成的class文件，需要先加载至方法区中，方能在Java虚拟机中运行。为了提高运行效率，标准JDK中的HotSpot虚拟机采用的是一种混合执行的策略。它会解释执行Java字节码，然后会将其中反复执行的热点代码，以方法为单位进行即时编译，翻译成机器码后直接运行在底层硬件之上。HotSpot装载了多个不同的即时编译器，以便在编译时间和生成代码的执行效率之间做取舍。

这篇总结主要是基于我之前JVM系列文章而形成的的。主要是把重要的知识点用自己的话说了一遍，可能会有一些错误，还望见谅和指点。谢谢#更多详细内容可以查看我的专栏文章：深入理解JVM虚拟机https://blog.csdn.net/column/details/21960.htmlJVM介绍和源码首先JVM是一个虚拟机，当你安装了jre，它就包含了jvm环境。JVM有自己的内存结构，字节码执行引擎，因此class字节码才能在jvm上运行，除了Java以外，Scala，groovy等语言也可以编译成字节码而后在jvm中运行。JVM是用c开发的。JVM内存模型内存模型老生常谈了，主要就是线程共享的堆区，方法区，本地方法栈。还有线程私有的虚拟机栈和程序计数器。堆区存放所有对象，每个对象有一个地址，Java类jvm初始化时加载到方法区，而后会在堆区中生成一个Class对象，来负责这个类所有实例的实例化。栈区存放的是栈帧结构，栈帧是一段内存空间，包括参数列表，返回地址，局部变量表等，局部变量表由一堆slot组成，slot的大小固定，根据变量的数据类型决定需要用到几个slot。方法区存放类的元数据，将原来的字面量转换成引用，当然，方法区也提供常量池，常量池存放-128到127的数字类型的包装类。字符串常量池则会存放使用intern的字符串变量。JVM OOM和内存泄漏这里指的是oom和内存泄漏这类错误。oom一般分为三种，堆区内存溢出，栈区内存溢出以及方法区内存溢出。堆内存溢出主要原因是创建了太多对象，比如一个集合类死循环添加一个数，此时设置jvm参数使堆内存最大值为10m，一会就会报oom异常。栈内存溢出主要与栈空间和线程有关，因为栈是线程私有的，如果创建太多线程，内存值超过栈空间上限，也会报oom。方法区内存溢出主要是由于动态加载类的数量太多，或者是不断创建一个动态代理，用不了多久方法区内存也会溢出，会报oom，这里在1.7之前会报permgem oom，1.8则会报meta space oom，这是因为1.8中删除了堆中的永久代，转而使用元数据区。内存泄漏一般是因为对象被引用无法回收，比如一个集合中存着很多对象，可能你在外部代码把对象的引用置空了，但是由于对象还被集合给引用着，所以无法被回收，导致内存泄漏。测试也很简单，就在集合里添加对象，添加完以后把引用置空，循环操作，一会就会出现oom异常，原因是内存泄漏太多了，导致没有空间分配新的对象。常见调试工具命令行工具有jstack jstat jmap 等，jstack可以跟踪线程的调用堆栈，以便追踪错误原因。jstat可以检查jvm的内存使用情况，gc情况以及线程状态等。jmap用于把堆栈快照转储到文件系统，然后可以用其他工具去排查。visualvm是一款很不错的gui调试工具，可以远程登录主机以便访问其jvm的状态并进行监控。class文件结构class文件结构比较复杂，首先jvm定义了一个class文件的规则，并且让jvm按照这个规则去验证与读取。开头是一串魔数，然后接下来会有各种不同长度的数据，通过class的规则去读取这些数据，jvm就可以识别其内容，最后将其加载到方法区。JVM的类加载机制jvm的类加载顺序是bootstrap类加载器，extclassloader加载器，最后是appclassloader用户加载器，分别加载的是jdk/bin ，jdk/ext以及用户定义的类目录下的类（一般通过ide指定），一般核心类都由bootstrap和ext加载器来加载，appclassloader用于加载自己写的类。双亲委派模型，加载一个类时，首先获取当前类加载器，先找到最高层的类加载器bootstrap让他尝试加载，他如果加载不了再让ext加载器去加载，如果他也加载不了再让appclassloader去加载。这样的话，确保一个类型只会被加载一次，并且以高层类加载器为准，防止某些类与核心类重复，产生错误。defineclass findclass和loadclass类加载classloader中有两个方法loadclass和findclass，loadclass遵从双亲委派模型，先调用父类加载的loadclass，如果父类和自己都无法加载该类，则会去调用findclass方法，而findclass默认实现为空，如果要自定义类加载方式，则可以重写findclass方法。常见使用defineclass的情况是从网络或者文件读取字节码，然后通过defineclass将其定义成一个类，并且返回一个Class对象，说明此时类已经加载到方法区了。当然1.8以前实现方法区的是永久代，1.8以后则是元空间了。JVM虚拟机字节码执行引擎jvm通过字节码执行引擎来执行class代码，他是一个栈式执行引擎。这部分内容比较高深，在这里就不献丑了。编译期优化和运行期优化编译期优化主要有几种1 泛型的擦除，使得泛型在编译时变成了实际类型，也叫伪泛型。2 自动拆箱装箱，foreach循环自动变成迭代器实现的for循环。3 条件编译，比如if(true)直接可得。运行期优化主要有几种1 JIT即时编译Java既是编译语言也是解释语言，因为需要编译代码生成字节码，而后通过解释器解释执行。但是，有些代码由于经常被使用而成为热点代码，每次都编译太过费时费力，干脆直接把他编译成本地代码，这种方式叫做JIT即时编译处理，所以这部分代码可以直接在本地运行而不需要通过jvm的执行引擎。2 公共表达式擦除，就是一个式子在后面如果没有被修改，在后面调用时就会被直接替换成数值。3 数组边界擦除，方法内联，比较偏，意义不大。4 逃逸分析，用于分析一个对象的作用范围，如果只局限在方法中被访问，则说明不会逃逸出方法，这样的话他就是线程安全的，不需要进行并发加锁。1JVM的垃圾回收1 GC算法：停止复制，存活对象少时适用，缺点是需要两倍空间。标记清除，存活对象多时适用，但是容易产生随便。标记整理，存活对象少时适用，需要移动对象较多。2 GC分区，一般GC发生在堆区，堆区可分为年轻代，老年代，以前有永久代，现在没有了。年轻代分为eden和survior，新对象分配在eden，当年轻代满时触发minor gc，存活对象移至survivor区，然后两个区互换，等待下一场gc，当对象存活的阈值达到设定值时进入老年代，大对象也会直接进入老年代。老年代空间较大，当老年代空间不足以存放年轻代过来的对象时，开始进行full gc。同时整理年轻代和老年代。一般年轻代使用停止复制，老年代使用标记清除。3 垃圾收集器serial串行parallel并行它们都有年轻代与老年代的不同实现。然后是scanvage收集器，注重吞吐量，可以自己设置，不过不注重延迟。cms垃圾收集器，注重延迟的缩短和控制，并且收集线程和系统线程可以并发。cms收集步骤主要是，初次标记gc root，然后停顿进行并发标记，而后处理改变后的标记，最后停顿进行并发清除。g1收集器和cms的收集方式类似，但是g1将堆内存划分成了大小相同的小块区域，并且将垃圾集中到一个区域，存活对象集中到另一个区域，然后进行收集，防止产生碎片，同时使分配方式更灵活，它还支持根据对象变化预测停顿时间，从而更好地帮用户解决延迟等问题。

这篇总结主要是基于我之前JVM系列文章而形成的的。主要是把重要的知识点用自己的话说了一遍，可能会有一些错误，还望见谅和指点。谢谢#更多详细内容可以查看我的专栏文章：深入理解JVM虚拟机https://blog.csdn.net/column/details/21960.htmlJVM介绍和源码首先JVM是一个虚拟机，当你安装了jre，它就包含了jvm环境。JVM有自己的内存结构，字节码执行引擎，因此class字节码才能在jvm上运行，除了Java以外，Scala，groovy等语言也可以编译成字节码而后在jvm中运行。JVM是用c开发的。JVM内存模型内存模型老生常谈了，主要就是线程共享的堆区，方法区，本地方法栈。还有线程私有的虚拟机栈和程序计数器。堆区存放所有对象，每个对象有一个地址，Java类jvm初始化时加载到方法区，而后会在堆区中生成一个Class对象，来负责这个类所有实例的实例化。栈区存放的是栈帧结构，栈帧是一段内存空间，包括参数列表，返回地址，局部变量表等，局部变量表由一堆slot组成，slot的大小固定，根据变量的数据类型决定需要用到几个slot。方法区存放类的元数据，将原来的字面量转换成引用，当然，方法区也提供常量池，常量池存放-128到127的数字类型的包装类。字符串常量池则会存放使用intern的字符串变量。JVM OOM和内存泄漏这里指的是oom和内存泄漏这类错误。oom一般分为三种，堆区内存溢出，栈区内存溢出以及方法区内存溢出。堆内存溢出主要原因是创建了太多对象，比如一个集合类死循环添加一个数，此时设置jvm参数使堆内存最大值为10m，一会就会报oom异常。栈内存溢出主要与栈空间和线程有关，因为栈是线程私有的，如果创建太多线程，内存值超过栈空间上限，也会报oom。方法区内存溢出主要是由于动态加载类的数量太多，或者是不断创建一个动态代理，用不了多久方法区内存也会溢出，会报oom，这里在1.7之前会报permgem oom，1.8则会报meta space oom，这是因为1.8中删除了堆中的永久代，转而使用元数据区。内存泄漏一般是因为对象被引用无法回收，比如一个集合中存着很多对象，可能你在外部代码把对象的引用置空了，但是由于对象还被集合给引用着，所以无法被回收，导致内存泄漏。测试也很简单，就在集合里添加对象，添加完以后把引用置空，循环操作，一会就会出现oom异常，原因是内存泄漏太多了，导致没有空间分配新的对象。常见调试工具命令行工具有jstack jstat jmap 等，jstack可以跟踪线程的调用堆栈，以便追踪错误原因。jstat可以检查jvm的内存使用情况，gc情况以及线程状态等。jmap用于把堆栈快照转储到文件系统，然后可以用其他工具去排查。visualvm是一款很不错的gui调试工具，可以远程登录主机以便访问其jvm的状态并进行监控。class文件结构class文件结构比较复杂，首先jvm定义了一个class文件的规则，并且让jvm按照这个规则去验证与读取。开头是一串魔数，然后接下来会有各种不同长度的数据，通过class的规则去读取这些数据，jvm就可以识别其内容，最后将其加载到方法区。JVM的类加载机制jvm的类加载顺序是bootstrap类加载器，extclassloader加载器，最后是appclassloader用户加载器，分别加载的是jdk/bin ，jdk/ext以及用户定义的类目录下的类（一般通过ide指定），一般核心类都由bootstrap和ext加载器来加载，appclassloader用于加载自己写的类。双亲委派模型，加载一个类时，首先获取当前类加载器，先找到最高层的类加载器bootstrap让他尝试加载，他如果加载不了再让ext加载器去加载，如果他也加载不了再让appclassloader去加载。这样的话，确保一个类型只会被加载一次，并且以高层类加载器为准，防止某些类与核心类重复，产生错误。defineclass findclass和loadclass类加载classloader中有两个方法loadclass和findclass，loadclass遵从双亲委派模型，先调用父类加载的loadclass，如果父类和自己都无法加载该类，则会去调用findclass方法，而findclass默认实现为空，如果要自定义类加载方式，则可以重写findclass方法。常见使用defineclass的情况是从网络或者文件读取字节码，然后通过defineclass将其定义成一个类，并且返回一个Class对象，说明此时类已经加载到方法区了。当然1.8以前实现方法区的是永久代，1.8以后则是元空间了。JVM虚拟机字节码执行引擎jvm通过字节码执行引擎来执行class代码，他是一个栈式执行引擎。这部分内容比较高深，在这里就不献丑了。编译期优化和运行期优化编译期优化主要有几种1 泛型的擦除，使得泛型在编译时变成了实际类型，也叫伪泛型。2 自动拆箱装箱，foreach循环自动变成迭代器实现的for循环。3 条件编译，比如if(true)直接可得。运行期优化主要有几种1 JIT即时编译Java既是编译语言也是解释语言，因为需要编译代码生成字节码，而后通过解释器解释执行。但是，有些代码由于经常被使用而成为热点代码，每次都编译太过费时费力，干脆直接把他编译成本地代码，这种方式叫做JIT即时编译处理，所以这部分代码可以直接在本地运行而不需要通过jvm的执行引擎。2 公共表达式擦除，就是一个式子在后面如果没有被修改，在后面调用时就会被直接替换成数值。3 数组边界擦除，方法内联，比较偏，意义不大。4 逃逸分析，用于分析一个对象的作用范围，如果只局限在方法中被访问，则说明不会逃逸出方法，这样的话他就是线程安全的，不需要进行并发加锁。1JVM的垃圾回收1 GC算法：停止复制，存活对象少时适用，缺点是需要两倍空间。标记清除，存活对象多时适用，但是容易产生随便。标记整理，存活对象少时适用，需要移动对象较多。2 GC分区，一般GC发生在堆区，堆区可分为年轻代，老年代，以前有永久代，现在没有了。年轻代分为eden和survior，新对象分配在eden，当年轻代满时触发minor gc，存活对象移至survivor区，然后两个区互换，等待下一场gc，当对象存活的阈值达到设定值时进入老年代，大对象也会直接进入老年代。老年代空间较大，当老年代空间不足以存放年轻代过来的对象时，开始进行full gc。同时整理年轻代和老年代。一般年轻代使用停止复制，老年代使用标记清除。3 垃圾收集器serial串行parallel并行它们都有年轻代与老年代的不同实现。然后是scanvage收集器，注重吞吐量，可以自己设置，不过不注重延迟。cms垃圾收集器，注重延迟的缩短和控制，并且收集线程和系统线程可以并发。cms收集步骤主要是，初次标记gc root，然后停顿进行并发标记，而后处理改变后的标记，最后停顿进行并发清除。g1收集器和cms的收集方式类似，但是g1将堆内存划分成了大小相同的小块区域，并且将垃圾集中到一个区域，存活对象集中到另一个区域，然后进行收集，防止产生碎片，同时使分配方式更灵活，它还支持根据对象变化预测停顿时间，从而更好地帮用户解决延迟等问题。

这篇总结主要是基于我之前JVM系列文章而形成的的。主要是把重要的知识点用自己的话说了一遍，可能会有一些错误，还望见谅和指点。谢谢#更多详细内容可以查看我的专栏文章：深入理解JVM虚拟机https://blog.csdn.net/column/details/21960.htmlJVM介绍和源码首先JVM是一个虚拟机，当你安装了jre，它就包含了jvm环境。JVM有自己的内存结构，字节码执行引擎，因此class字节码才能在jvm上运行，除了Java以外，Scala，groovy等语言也可以编译成字节码而后在jvm中运行。JVM是用c开发的。JVM内存模型内存模型老生常谈了，主要就是线程共享的堆区，方法区，本地方法栈。还有线程私有的虚拟机栈和程序计数器。堆区存放所有对象，每个对象有一个地址，Java类jvm初始化时加载到方法区，而后会在堆区中生成一个Class对象，来负责这个类所有实例的实例化。栈区存放的是栈帧结构，栈帧是一段内存空间，包括参数列表，返回地址，局部变量表等，局部变量表由一堆slot组成，slot的大小固定，根据变量的数据类型决定需要用到几个slot。方法区存放类的元数据，将原来的字面量转换成引用，当然，方法区也提供常量池，常量池存放-128到127的数字类型的包装类。字符串常量池则会存放使用intern的字符串变量。JVM OOM和内存泄漏这里指的是oom和内存泄漏这类错误。oom一般分为三种，堆区内存溢出，栈区内存溢出以及方法区内存溢出。堆内存溢出主要原因是创建了太多对象，比如一个集合类死循环添加一个数，此时设置jvm参数使堆内存最大值为10m，一会就会报oom异常。栈内存溢出主要与栈空间和线程有关，因为栈是线程私有的，如果创建太多线程，内存值超过栈空间上限，也会报oom。方法区内存溢出主要是由于动态加载类的数量太多，或者是不断创建一个动态代理，用不了多久方法区内存也会溢出，会报oom，这里在1.7之前会报permgem oom，1.8则会报meta space oom，这是因为1.8中删除了堆中的永久代，转而使用元数据区。内存泄漏一般是因为对象被引用无法回收，比如一个集合中存着很多对象，可能你在外部代码把对象的引用置空了，但是由于对象还被集合给引用着，所以无法被回收，导致内存泄漏。测试也很简单，就在集合里添加对象，添加完以后把引用置空，循环操作，一会就会出现oom异常，原因是内存泄漏太多了，导致没有空间分配新的对象。常见调试工具命令行工具有jstack jstat jmap 等，jstack可以跟踪线程的调用堆栈，以便追踪错误原因。jstat可以检查jvm的内存使用情况，gc情况以及线程状态等。jmap用于把堆栈快照转储到文件系统，然后可以用其他工具去排查。visualvm是一款很不错的gui调试工具，可以远程登录主机以便访问其jvm的状态并进行监控。class文件结构class文件结构比较复杂，首先jvm定义了一个class文件的规则，并且让jvm按照这个规则去验证与读取。开头是一串魔数，然后接下来会有各种不同长度的数据，通过class的规则去读取这些数据，jvm就可以识别其内容，最后将其加载到方法区。JVM的类加载机制jvm的类加载顺序是bootstrap类加载器，extclassloader加载器，最后是appclassloader用户加载器，分别加载的是jdk/bin ，jdk/ext以及用户定义的类目录下的类（一般通过ide指定），一般核心类都由bootstrap和ext加载器来加载，appclassloader用于加载自己写的类。双亲委派模型，加载一个类时，首先获取当前类加载器，先找到最高层的类加载器bootstrap让他尝试加载，他如果加载不了再让ext加载器去加载，如果他也加载不了再让appclassloader去加载。这样的话，确保一个类型只会被加载一次，并且以高层类加载器为准，防止某些类与核心类重复，产生错误。defineclass findclass和loadclass类加载classloader中有两个方法loadclass和findclass，loadclass遵从双亲委派模型，先调用父类加载的loadclass，如果父类和自己都无法加载该类，则会去调用findclass方法，而findclass默认实现为空，如果要自定义类加载方式，则可以重写findclass方法。常见使用defineclass的情况是从网络或者文件读取字节码，然后通过defineclass将其定义成一个类，并且返回一个Class对象，说明此时类已经加载到方法区了。当然1.8以前实现方法区的是永久代，1.8以后则是元空间了。JVM虚拟机字节码执行引擎jvm通过字节码执行引擎来执行class代码，他是一个栈式执行引擎。这部分内容比较高深，在这里就不献丑了。编译期优化和运行期优化编译期优化主要有几种1 泛型的擦除，使得泛型在编译时变成了实际类型，也叫伪泛型。2 自动拆箱装箱，foreach循环自动变成迭代器实现的for循环。3 条件编译，比如if(true)直接可得。运行期优化主要有几种1 JIT即时编译Java既是编译语言也是解释语言，因为需要编译代码生成字节码，而后通过解释器解释执行。但是，有些代码由于经常被使用而成为热点代码，每次都编译太过费时费力，干脆直接把他编译成本地代码，这种方式叫做JIT即时编译处理，所以这部分代码可以直接在本地运行而不需要通过jvm的执行引擎。2 公共表达式擦除，就是一个式子在后面如果没有被修改，在后面调用时就会被直接替换成数值。3 数组边界擦除，方法内联，比较偏，意义不大。4 逃逸分析，用于分析一个对象的作用范围，如果只局限在方法中被访问，则说明不会逃逸出方法，这样的话他就是线程安全的，不需要进行并发加锁。1JVM的垃圾回收1 GC算法：停止复制，存活对象少时适用，缺点是需要两倍空间。标记清除，存活对象多时适用，但是容易产生随便。标记整理，存活对象少时适用，需要移动对象较多。2 GC分区，一般GC发生在堆区，堆区可分为年轻代，老年代，以前有永久代，现在没有了。年轻代分为eden和survior，新对象分配在eden，当年轻代满时触发minor gc，存活对象移至survivor区，然后两个区互换，等待下一场gc，当对象存活的阈值达到设定值时进入老年代，大对象也会直接进入老年代。老年代空间较大，当老年代空间不足以存放年轻代过来的对象时，开始进行full gc。同时整理年轻代和老年代。一般年轻代使用停止复制，老年代使用标记清除。3 垃圾收集器serial串行parallel并行它们都有年轻代与老年代的不同实现。然后是scanvage收集器，注重吞吐量，可以自己设置，不过不注重延迟。cms垃圾收集器，注重延迟的缩短和控制，并且收集线程和系统线程可以并发。cms收集步骤主要是，初次标记gc root，然后停顿进行并发标记，而后处理改变后的标记，最后停顿进行并发清除。g1收集器和cms的收集方式类似，但是g1将堆内存划分成了大小相同的小块区域，并且将垃圾集中到一个区域，存活对象集中到另一个区域，然后进行收集，防止产生碎片，同时使分配方式更灵活，它还支持根据对象变化预测停顿时间，从而更好地帮用户解决延迟等问题。

这篇总结主要是基于我之前JVM系列文章而形成的的。主要是把重要的知识点用自己的话说了一遍，可能会有一些错误，还望见谅和指点。谢谢#更多详细内容可以查看我的专栏文章：深入理解JVM虚拟机https://blog.csdn.net/column/details/21960.htmlJVM介绍和源码首先JVM是一个虚拟机，当你安装了jre，它就包含了jvm环境。JVM有自己的内存结构，字节码执行引擎，因此class字节码才能在jvm上运行，除了Java以外，Scala，groovy等语言也可以编译成字节码而后在jvm中运行。JVM是用c开发的。JVM内存模型内存模型老生常谈了，主要就是线程共享的堆区，方法区，本地方法栈。还有线程私有的虚拟机栈和程序计数器。堆区存放所有对象，每个对象有一个地址，Java类jvm初始化时加载到方法区，而后会在堆区中生成一个Class对象，来负责这个类所有实例的实例化。栈区存放的是栈帧结构，栈帧是一段内存空间，包括参数列表，返回地址，局部变量表等，局部变量表由一堆slot组成，slot的大小固定，根据变量的数据类型决定需要用到几个slot。方法区存放类的元数据，将原来的字面量转换成引用，当然，方法区也提供常量池，常量池存放-128到127的数字类型的包装类。字符串常量池则会存放使用intern的字符串变量。JVM OOM和内存泄漏这里指的是oom和内存泄漏这类错误。oom一般分为三种，堆区内存溢出，栈区内存溢出以及方法区内存溢出。堆内存溢出主要原因是创建了太多对象，比如一个集合类死循环添加一个数，此时设置jvm参数使堆内存最大值为10m，一会就会报oom异常。栈内存溢出主要与栈空间和线程有关，因为栈是线程私有的，如果创建太多线程，内存值超过栈空间上限，也会报oom。方法区内存溢出主要是由于动态加载类的数量太多，或者是不断创建一个动态代理，用不了多久方法区内存也会溢出，会报oom，这里在1.7之前会报permgem oom，1.8则会报meta space oom，这是因为1.8中删除了堆中的永久代，转而使用元数据区。内存泄漏一般是因为对象被引用无法回收，比如一个集合中存着很多对象，可能你在外部代码把对象的引用置空了，但是由于对象还被集合给引用着，所以无法被回收，导致内存泄漏。测试也很简单，就在集合里添加对象，添加完以后把引用置空，循环操作，一会就会出现oom异常，原因是内存泄漏太多了，导致没有空间分配新的对象。常见调试工具命令行工具有jstack jstat jmap 等，jstack可以跟踪线程的调用堆栈，以便追踪错误原因。jstat可以检查jvm的内存使用情况，gc情况以及线程状态等。jmap用于把堆栈快照转储到文件系统，然后可以用其他工具去排查。visualvm是一款很不错的gui调试工具，可以远程登录主机以便访问其jvm的状态并进行监控。class文件结构class文件结构比较复杂，首先jvm定义了一个class文件的规则，并且让jvm按照这个规则去验证与读取。开头是一串魔数，然后接下来会有各种不同长度的数据，通过class的规则去读取这些数据，jvm就可以识别其内容，最后将其加载到方法区。JVM的类加载机制jvm的类加载顺序是bootstrap类加载器，extclassloader加载器，最后是appclassloader用户加载器，分别加载的是jdk/bin ，jdk/ext以及用户定义的类目录下的类（一般通过ide指定），一般核心类都由bootstrap和ext加载器来加载，appclassloader用于加载自己写的类。双亲委派模型，加载一个类时，首先获取当前类加载器，先找到最高层的类加载器bootstrap让他尝试加载，他如果加载不了再让ext加载器去加载，如果他也加载不了再让appclassloader去加载。这样的话，确保一个类型只会被加载一次，并且以高层类加载器为准，防止某些类与核心类重复，产生错误。defineclass findclass和loadclass类加载classloader中有两个方法loadclass和findclass，loadclass遵从双亲委派模型，先调用父类加载的loadclass，如果父类和自己都无法加载该类，则会去调用findclass方法，而findclass默认实现为空，如果要自定义类加载方式，则可以重写findclass方法。常见使用defineclass的情况是从网络或者文件读取字节码，然后通过defineclass将其定义成一个类，并且返回一个Class对象，说明此时类已经加载到方法区了。当然1.8以前实现方法区的是永久代，1.8以后则是元空间了。JVM虚拟机字节码执行引擎jvm通过字节码执行引擎来执行class代码，他是一个栈式执行引擎。这部分内容比较高深，在这里就不献丑了。编译期优化和运行期优化编译期优化主要有几种1 泛型的擦除，使得泛型在编译时变成了实际类型，也叫伪泛型。2 自动拆箱装箱，foreach循环自动变成迭代器实现的for循环。3 条件编译，比如if(true)直接可得。运行期优化主要有几种1 JIT即时编译Java既是编译语言也是解释语言，因为需要编译代码生成字节码，而后通过解释器解释执行。但是，有些代码由于经常被使用而成为热点代码，每次都编译太过费时费力，干脆直接把他编译成本地代码，这种方式叫做JIT即时编译处理，所以这部分代码可以直接在本地运行而不需要通过jvm的执行引擎。2 公共表达式擦除，就是一个式子在后面如果没有被修改，在后面调用时就会被直接替换成数值。3 数组边界擦除，方法内联，比较偏，意义不大。4 逃逸分析，用于分析一个对象的作用范围，如果只局限在方法中被访问，则说明不会逃逸出方法，这样的话他就是线程安全的，不需要进行并发加锁。1JVM的垃圾回收1 GC算法：停止复制，存活对象少时适用，缺点是需要两倍空间。标记清除，存活对象多时适用，但是容易产生随便。标记整理，存活对象少时适用，需要移动对象较多。2 GC分区，一般GC发生在堆区，堆区可分为年轻代，老年代，以前有永久代，现在没有了。年轻代分为eden和survior，新对象分配在eden，当年轻代满时触发minor gc，存活对象移至survivor区，然后两个区互换，等待下一场gc，当对象存活的阈值达到设定值时进入老年代，大对象也会直接进入老年代。老年代空间较大，当老年代空间不足以存放年轻代过来的对象时，开始进行full gc。同时整理年轻代和老年代。一般年轻代使用停止复制，老年代使用标记清除。3 垃圾收集器serial串行parallel并行它们都有年轻代与老年代的不同实现。然后是scanvage收集器，注重吞吐量，可以自己设置，不过不注重延迟。cms垃圾收集器，注重延迟的缩短和控制，并且收集线程和系统线程可以并发。cms收集步骤主要是，初次标记gc root，然后停顿进行并发标记，而后处理改变后的标记，最后停顿进行并发清除。g1收集器和cms的收集方式类似，但是g1将堆内存划分成了大小相同的小块区域，并且将垃圾集中到一个区域，存活对象集中到另一个区域，然后进行收集，防止产生碎片，同时使分配方式更灵活，它还支持根据对象变化预测停顿时间，从而更好地帮用户解决延迟等问题。

SPECjvm2008生成结果报X11错误解决方案1      问题现象Specjvm2008跑完后，生成结果时报错Results are stored in:/SPECjvm2008/build/release/SPECjvm2008/results/SPECjvm2008.002/SPECjvm2008.002.rawGenerating reports in:/SPECjvm2008/build/release/SPECjvm2008/results/SPECjvm2008.002Error while creating report: Can't connect to X11 window server using 'localhost:11.0' as the value of the DISPLAY variable.java.awt.AWTError: Can't connect to X11 window server using 'localhost:11.0' as the value of the DISPLAY variable.        at sun.awt.X11GraphicsEnvironment.initDisplay(Native Method)        at sun.awt.X11GraphicsEnvironment.access$200(X11GraphicsEnvironment.java:65)        at sun.awt.X11GraphicsEnvironment$1.run(X11GraphicsEnvironment.java:115)        at java.security.AccessController.doPrivileged(Native Method)        at sun.awt.X11GraphicsEnvironment.<clinit>(X11GraphicsEnvironment.java:74)        at java.lang.Class.forName0(Native Method)        at java.lang.Class.forName(Class.java:264)        at java.awt.GraphicsEnvironment.createGE(GraphicsEnvironment.java:103)        at java.awt.GraphicsEnvironment.getLocalGraphicsEnvironment(GraphicsEnvironment.java:82)        at sun.awt.X11.XToolkit.<clinit>(XToolkit.java:131)        at java.lang.Class.forName0(Native Method)        at java.lang.Class.forName(Class.java:264)        at java.awt.Toolkit$2.run(Toolkit.java:860)        at java.awt.Toolkit$2.run(Toolkit.java:855)        at java.security.AccessController.doPrivileged(Native Method)        at java.awt.Toolkit.getDefaultToolkit(Toolkit.java:854)        at sun.swing.SwingUtilities2.getSystemMnemonicKeyMask(SwingUtilities2.java:2032)        at javax.swing.plaf.basic.BasicLookAndFeel.initComponentDefaults(BasicLookAndFeel.java:1158)        at javax.swing.plaf.metal.MetalLookAndFeel.initComponentDefaults(MetalLookAndFeel.java:431)        at javax.swing.plaf.basic.BasicLookAndFeel.getDefaults(BasicLookAndFeel.java:148)        at javax.swing.plaf.metal.MetalLookAndFeel.getDefaults(MetalLookAndFeel.java:1577)        at javax.swing.UIManager.setLookAndFeel(UIManager.java:539)        at javax.swing.UIManager.setLookAndFeel(UIManager.java:579)        at javax.swing.UIManager.initializeDefaultLAF(UIManager.java:1349)        at javax.swing.UIManager.initialize(UIManager.java:1459)        at javax.swing.UIManager.maybeInitialize(UIManager.java:1426)        at javax.swing.UIManager.getDefaults(UIManager.java:659)        at javax.swing.UIManager.getColor(UIManager.java:701) 2      解决方案2.1      如何再次生成结果specjvm2008是正常跑完的，只是在生成结果时报错，可以尝试用跑完生成的raw文件再次生成结果。1）、进入结果目录/SPECjvm2008/build/release/SPECjvm2008/results/SPECjvm2008.002，可以看到已经生成了SPECjvm2008.002.raw，使用如下命令，等待一段时间后重新生成结果。 [root@localhost SPECjvm2008.001]# java -jar /SPECjvm2008/SPECjvm2008.jar -r --prepare SPECjvm2008.001.rawCreating file /SPECjvm2008/results/SPECjvm2008.001/./results/SPECjvm2008.001/SPECjvm2008.001.raw [root@localhost SPECjvm2008.001]# java -jar /SPECjvm2008/SPECjvm2008.jar -r --specprocess /SPECjvm2008/results/SPECjvm2008.001/./results/SPECjvm2008.001/SPECjvm2008.001.raw.zipExtracting file: /SPECjvm2008/results/SPECjvm2008.001/./results/SPECjvm2008.001/SPECjvm2008.001.rawCreating file /SPECjvm2008/results/SPECjvm2008.001/./results/SPECjvm2008.001/SPECjvm2008.001.base/SPECjvm2008.base.rawGenerating reports in:/SPECjvm2008/results/SPECjvm2008.001/results/SPECjvm2008.001/SPECjvm2008.001.base  Creating report /SPECjvm2008/results/SPECjvm2008.001/./results/SPECjvm2008.001/SPECjvm2008.001.html 2.2      如何解决这个问题在跑SPECjvm2008之前，执行unset XPATH即可。

这篇总结主要是基于我之前JVM系列文章而形成的的。主要是把重要的知识点用自己的话说了一遍，可能会有一些错误，还望见谅和指点。谢谢#更多详细内容可以查看我的专栏文章：深入理解JVM虚拟机https://blog.csdn.net/column/details/21960.htmlJVM介绍和源码首先JVM是一个虚拟机，当你安装了jre，它就包含了jvm环境。JVM有自己的内存结构，字节码执行引擎，因此class字节码才能在jvm上运行，除了Java以外，Scala，groovy等语言也可以编译成字节码而后在jvm中运行。JVM是用c开发的。JVM内存模型内存模型老生常谈了，主要就是线程共享的堆区，方法区，本地方法栈。还有线程私有的虚拟机栈和程序计数器。堆区存放所有对象，每个对象有一个地址，Java类jvm初始化时加载到方法区，而后会在堆区中生成一个Class对象，来负责这个类所有实例的实例化。栈区存放的是栈帧结构，栈帧是一段内存空间，包括参数列表，返回地址，局部变量表等，局部变量表由一堆slot组成，slot的大小固定，根据变量的数据类型决定需要用到几个slot。方法区存放类的元数据，将原来的字面量转换成引用，当然，方法区也提供常量池，常量池存放-128到127的数字类型的包装类。字符串常量池则会存放使用intern的字符串变量。JVM OOM和内存泄漏这里指的是oom和内存泄漏这类错误。oom一般分为三种，堆区内存溢出，栈区内存溢出以及方法区内存溢出。堆内存溢出主要原因是创建了太多对象，比如一个集合类死循环添加一个数，此时设置jvm参数使堆内存最大值为10m，一会就会报oom异常。栈内存溢出主要与栈空间和线程有关，因为栈是线程私有的，如果创建太多线程，内存值超过栈空间上限，也会报oom。方法区内存溢出主要是由于动态加载类的数量太多，或者是不断创建一个动态代理，用不了多久方法区内存也会溢出，会报oom，这里在1.7之前会报permgem oom，1.8则会报meta space oom，这是因为1.8中删除了堆中的永久代，转而使用元数据区。内存泄漏一般是因为对象被引用无法回收，比如一个集合中存着很多对象，可能你在外部代码把对象的引用置空了，但是由于对象还被集合给引用着，所以无法被回收，导致内存泄漏。测试也很简单，就在集合里添加对象，添加完以后把引用置空，循环操作，一会就会出现oom异常，原因是内存泄漏太多了，导致没有空间分配新的对象。常见调试工具命令行工具有jstack jstat jmap 等，jstack可以跟踪线程的调用堆栈，以便追踪错误原因。jstat可以检查jvm的内存使用情况，gc情况以及线程状态等。jmap用于把堆栈快照转储到文件系统，然后可以用其他工具去排查。visualvm是一款很不错的gui调试工具，可以远程登录主机以便访问其jvm的状态并进行监控。class文件结构class文件结构比较复杂，首先jvm定义了一个class文件的规则，并且让jvm按照这个规则去验证与读取。开头是一串魔数，然后接下来会有各种不同长度的数据，通过class的规则去读取这些数据，jvm就可以识别其内容，最后将其加载到方法区。JVM的类加载机制jvm的类加载顺序是bootstrap类加载器，extclassloader加载器，最后是appclassloader用户加载器，分别加载的是jdk/bin ，jdk/ext以及用户定义的类目录下的类（一般通过ide指定），一般核心类都由bootstrap和ext加载器来加载，appclassloader用于加载自己写的类。双亲委派模型，加载一个类时，首先获取当前类加载器，先找到最高层的类加载器bootstrap让他尝试加载，他如果加载不了再让ext加载器去加载，如果他也加载不了再让appclassloader去加载。这样的话，确保一个类型只会被加载一次，并且以高层类加载器为准，防止某些类与核心类重复，产生错误。defineclass findclass和loadclass类加载classloader中有两个方法loadclass和findclass，loadclass遵从双亲委派模型，先调用父类加载的loadclass，如果父类和自己都无法加载该类，则会去调用findclass方法，而findclass默认实现为空，如果要自定义类加载方式，则可以重写findclass方法。常见使用defineclass的情况是从网络或者文件读取字节码，然后通过defineclass将其定义成一个类，并且返回一个Class对象，说明此时类已经加载到方法区了。当然1.8以前实现方法区的是永久代，1.8以后则是元空间了。JVM虚拟机字节码执行引擎jvm通过字节码执行引擎来执行class代码，他是一个栈式执行引擎。这部分内容比较高深，在这里就不献丑了。编译期优化和运行期优化编译期优化主要有几种1 泛型的擦除，使得泛型在编译时变成了实际类型，也叫伪泛型。2 自动拆箱装箱，foreach循环自动变成迭代器实现的for循环。3 条件编译，比如if(true)直接可得。运行期优化主要有几种1 JIT即时编译Java既是编译语言也是解释语言，因为需要编译代码生成字节码，而后通过解释器解释执行。但是，有些代码由于经常被使用而成为热点代码，每次都编译太过费时费力，干脆直接把他编译成本地代码，这种方式叫做JIT即时编译处理，所以这部分代码可以直接在本地运行而不需要通过jvm的执行引擎。2 公共表达式擦除，就是一个式子在后面如果没有被修改，在后面调用时就会被直接替换成数值。3 数组边界擦除，方法内联，比较偏，意义不大。4 逃逸分析，用于分析一个对象的作用范围，如果只局限在方法中被访问，则说明不会逃逸出方法，这样的话他就是线程安全的，不需要进行并发加锁。1JVM的垃圾回收1 GC算法：停止复制，存活对象少时适用，缺点是需要两倍空间。标记清除，存活对象多时适用，但是容易产生随便。标记整理，存活对象少时适用，需要移动对象较多。2 GC分区，一般GC发生在堆区，堆区可分为年轻代，老年代，以前有永久代，现在没有了。年轻代分为eden和survior，新对象分配在eden，当年轻代满时触发minor gc，存活对象移至survivor区，然后两个区互换，等待下一场gc，当对象存活的阈值达到设定值时进入老年代，大对象也会直接进入老年代。老年代空间较大，当老年代空间不足以存放年轻代过来的对象时，开始进行full gc。同时整理年轻代和老年代。一般年轻代使用停止复制，老年代使用标记清除。3 垃圾收集器serial串行parallel并行它们都有年轻代与老年代的不同实现。然后是scanvage收集器，注重吞吐量，可以自己设置，不过不注重延迟。cms垃圾收集器，注重延迟的缩短和控制，并且收集线程和系统线程可以并发。cms收集步骤主要是，初次标记gc root，然后停顿进行并发标记，而后处理改变后的标记，最后停顿进行并发清除。g1收集器和cms的收集方式类似，但是g1将堆内存划分成了大小相同的小块区域，并且将垃圾集中到一个区域，存活对象集中到另一个区域，然后进行收集，防止产生碎片，同时使分配方式更灵活，它还支持根据对象变化预测停顿时间，从而更好地帮用户解决延迟等问题。

这篇总结主要是基于我之前JVM系列文章而形成的的。主要是把重要的知识点用自己的话说了一遍，可能会有一些错误，还望见谅和指点。谢谢#更多详细内容可以查看我的专栏文章：深入理解JVM虚拟机https://blog.csdn.net/column/details/21960.htmlJVM介绍和源码首先JVM是一个虚拟机，当你安装了jre，它就包含了jvm环境。JVM有自己的内存结构，字节码执行引擎，因此class字节码才能在jvm上运行，除了Java以外，Scala，groovy等语言也可以编译成字节码而后在jvm中运行。JVM是用c开发的。JVM内存模型内存模型老生常谈了，主要就是线程共享的堆区，方法区，本地方法栈。还有线程私有的虚拟机栈和程序计数器。堆区存放所有对象，每个对象有一个地址，Java类jvm初始化时加载到方法区，而后会在堆区中生成一个Class对象，来负责这个类所有实例的实例化。栈区存放的是栈帧结构，栈帧是一段内存空间，包括参数列表，返回地址，局部变量表等，局部变量表由一堆slot组成，slot的大小固定，根据变量的数据类型决定需要用到几个slot。方法区存放类的元数据，将原来的字面量转换成引用，当然，方法区也提供常量池，常量池存放-128到127的数字类型的包装类。字符串常量池则会存放使用intern的字符串变量。JVM OOM和内存泄漏这里指的是oom和内存泄漏这类错误。oom一般分为三种，堆区内存溢出，栈区内存溢出以及方法区内存溢出。堆内存溢出主要原因是创建了太多对象，比如一个集合类死循环添加一个数，此时设置jvm参数使堆内存最大值为10m，一会就会报oom异常。栈内存溢出主要与栈空间和线程有关，因为栈是线程私有的，如果创建太多线程，内存值超过栈空间上限，也会报oom。方法区内存溢出主要是由于动态加载类的数量太多，或者是不断创建一个动态代理，用不了多久方法区内存也会溢出，会报oom，这里在1.7之前会报permgem oom，1.8则会报meta space oom，这是因为1.8中删除了堆中的永久代，转而使用元数据区。内存泄漏一般是因为对象被引用无法回收，比如一个集合中存着很多对象，可能你在外部代码把对象的引用置空了，但是由于对象还被集合给引用着，所以无法被回收，导致内存泄漏。测试也很简单，就在集合里添加对象，添加完以后把引用置空，循环操作，一会就会出现oom异常，原因是内存泄漏太多了，导致没有空间分配新的对象。常见调试工具命令行工具有jstack jstat jmap 等，jstack可以跟踪线程的调用堆栈，以便追踪错误原因。jstat可以检查jvm的内存使用情况，gc情况以及线程状态等。jmap用于把堆栈快照转储到文件系统，然后可以用其他工具去排查。visualvm是一款很不错的gui调试工具，可以远程登录主机以便访问其jvm的状态并进行监控。class文件结构class文件结构比较复杂，首先jvm定义了一个class文件的规则，并且让jvm按照这个规则去验证与读取。开头是一串魔数，然后接下来会有各种不同长度的数据，通过class的规则去读取这些数据，jvm就可以识别其内容，最后将其加载到方法区。JVM的类加载机制jvm的类加载顺序是bootstrap类加载器，extclassloader加载器，最后是appclassloader用户加载器，分别加载的是jdk/bin ，jdk/ext以及用户定义的类目录下的类（一般通过ide指定），一般核心类都由bootstrap和ext加载器来加载，appclassloader用于加载自己写的类。双亲委派模型，加载一个类时，首先获取当前类加载器，先找到最高层的类加载器bootstrap让他尝试加载，他如果加载不了再让ext加载器去加载，如果他也加载不了再让appclassloader去加载。这样的话，确保一个类型只会被加载一次，并且以高层类加载器为准，防止某些类与核心类重复，产生错误。defineclass findclass和loadclass类加载classloader中有两个方法loadclass和findclass，loadclass遵从双亲委派模型，先调用父类加载的loadclass，如果父类和自己都无法加载该类，则会去调用findclass方法，而findclass默认实现为空，如果要自定义类加载方式，则可以重写findclass方法。常见使用defineclass的情况是从网络或者文件读取字节码，然后通过defineclass将其定义成一个类，并且返回一个Class对象，说明此时类已经加载到方法区了。当然1.8以前实现方法区的是永久代，1.8以后则是元空间了。JVM虚拟机字节码执行引擎jvm通过字节码执行引擎来执行class代码，他是一个栈式执行引擎。这部分内容比较高深，在这里就不献丑了。编译期优化和运行期优化编译期优化主要有几种1 泛型的擦除，使得泛型在编译时变成了实际类型，也叫伪泛型。2 自动拆箱装箱，foreach循环自动变成迭代器实现的for循环。3 条件编译，比如if(true)直接可得。运行期优化主要有几种1 JIT即时编译Java既是编译语言也是解释语言，因为需要编译代码生成字节码，而后通过解释器解释执行。但是，有些代码由于经常被使用而成为热点代码，每次都编译太过费时费力，干脆直接把他编译成本地代码，这种方式叫做JIT即时编译处理，所以这部分代码可以直接在本地运行而不需要通过jvm的执行引擎。2 公共表达式擦除，就是一个式子在后面如果没有被修改，在后面调用时就会被直接替换成数值。3 数组边界擦除，方法内联，比较偏，意义不大。4 逃逸分析，用于分析一个对象的作用范围，如果只局限在方法中被访问，则说明不会逃逸出方法，这样的话他就是线程安全的，不需要进行并发加锁。1JVM的垃圾回收1 GC算法：停止复制，存活对象少时适用，缺点是需要两倍空间。标记清除，存活对象多时适用，但是容易产生随便。标记整理，存活对象少时适用，需要移动对象较多。2 GC分区，一般GC发生在堆区，堆区可分为年轻代，老年代，以前有永久代，现在没有了。年轻代分为eden和survior，新对象分配在eden，当年轻代满时触发minor gc，存活对象移至survivor区，然后两个区互换，等待下一场gc，当对象存活的阈值达到设定值时进入老年代，大对象也会直接进入老年代。老年代空间较大，当老年代空间不足以存放年轻代过来的对象时，开始进行full gc。同时整理年轻代和老年代。一般年轻代使用停止复制，老年代使用标记清除。3 垃圾收集器serial串行parallel并行它们都有年轻代与老年代的不同实现。然后是scanvage收集器，注重吞吐量，可以自己设置，不过不注重延迟。cms垃圾收集器，注重延迟的缩短和控制，并且收集线程和系统线程可以并发。cms收集步骤主要是，初次标记gc root，然后停顿进行并发标记，而后处理改变后的标记，最后停顿进行并发清除。g1收集器和cms的收集方式类似，但是g1将堆内存划分成了大小相同的小块区域，并且将垃圾集中到一个区域，存活对象集中到另一个区域，然后进行收集，防止产生碎片，同时使分配方式更灵活，它还支持根据对象变化预测停顿时间，从而更好地帮用户解决延迟等问题。

因为Java有一个很重要的特性——跨平台也就是“一次编写，到处运行”，也就是编写一个程序，可以在Windows，Linux，Mac等系统上直接运行，我们都知道不同的计算机有不同的硬件结构（CPU的体系架构不同），也有不同的操作系统，操作系统提供的API也不一样，而JVM就是屏蔽不同计算机上软硬件的差异，也就是代码只需要对虚拟机负责就OK，也就达到了我们的跨平台的目的。JVM也不仅仅是一个程序，不同的系统都会对应一个JVM的版本（如：Windows的JVM是一个版本，Linux的JVM也是一个版本），但是不管是那个版本的JVM，都懂Java语言。这也就说明为什么我们在官网上面下载的同一个 Tomcat 压缩包，既能在Windows上运行，也能够在Linux上运行，都是靠JVM把其中的差异给屏蔽掉了。注：JVM发展到现在，不仅仅是为了跨平台，而是已经打造成了一个生态圈，大量的程序/库/编程语言都是基于JVM的，但是对于一个编程语言来说，实现编译器（就是把源代码翻译成可执行指令），直接翻译成机器指令native指令，比较复杂，考虑到系统的差异，CPU的差异，那么工作量也就大了，干脆就将编程语言直接翻译成JVM能够之别的字节码，由JVM去考虑软硬件之间的差异，大大降低工作量。JVM有没有什么缺点呢？答：当然有，因为没有什么东西是完美无瑕的，在一个程序中，要先将编程语言翻译成JVM能够识别的字节码，然后再不同的系统中，JVM在屏蔽软硬件的差异再去翻译成不同系统能够识别的程序，那么效率肯定会受到影响。（注：虽然虚拟机能够影响到一定的效率，但是在真正的商业项目中，性能瓶颈往往不是编程语言自身带来的，更主要的瓶颈是网络IO/数据库/磁盘IO/复杂的CPU密集计算……）。

这篇总结主要是基于我之前JVM系列文章而形成的的。主要是把重要的知识点用自己的话说了一遍，可能会有一些错误，还望见谅和指点。谢谢#更多详细内容可以查看我的专栏文章：深入理解JVM虚拟机https://blog.csdn.net/column/details/21960.htmlJVM介绍和源码首先JVM是一个虚拟机，当你安装了jre，它就包含了jvm环境。JVM有自己的内存结构，字节码执行引擎，因此class字节码才能在jvm上运行，除了Java以外，Scala，groovy等语言也可以编译成字节码而后在jvm中运行。JVM是用c开发的。JVM内存模型内存模型老生常谈了，主要就是线程共享的堆区，方法区，本地方法栈。还有线程私有的虚拟机栈和程序计数器。堆区存放所有对象，每个对象有一个地址，Java类jvm初始化时加载到方法区，而后会在堆区中生成一个Class对象，来负责这个类所有实例的实例化。栈区存放的是栈帧结构，栈帧是一段内存空间，包括参数列表，返回地址，局部变量表等，局部变量表由一堆slot组成，slot的大小固定，根据变量的数据类型决定需要用到几个slot。方法区存放类的元数据，将原来的字面量转换成引用，当然，方法区也提供常量池，常量池存放-128到127的数字类型的包装类。字符串常量池则会存放使用intern的字符串变量。JVM OOM和内存泄漏这里指的是oom和内存泄漏这类错误。oom一般分为三种，堆区内存溢出，栈区内存溢出以及方法区内存溢出。堆内存溢出主要原因是创建了太多对象，比如一个集合类死循环添加一个数，此时设置jvm参数使堆内存最大值为10m，一会就会报oom异常。栈内存溢出主要与栈空间和线程有关，因为栈是线程私有的，如果创建太多线程，内存值超过栈空间上限，也会报oom。方法区内存溢出主要是由于动态加载类的数量太多，或者是不断创建一个动态代理，用不了多久方法区内存也会溢出，会报oom，这里在1.7之前会报permgem oom，1.8则会报meta space oom，这是因为1.8中删除了堆中的永久代，转而使用元数据区。内存泄漏一般是因为对象被引用无法回收，比如一个集合中存着很多对象，可能你在外部代码把对象的引用置空了，但是由于对象还被集合给引用着，所以无法被回收，导致内存泄漏。测试也很简单，就在集合里添加对象，添加完以后把引用置空，循环操作，一会就会出现oom异常，原因是内存泄漏太多了，导致没有空间分配新的对象。常见调试工具命令行工具有jstack jstat jmap 等，jstack可以跟踪线程的调用堆栈，以便追踪错误原因。jstat可以检查jvm的内存使用情况，gc情况以及线程状态等。jmap用于把堆栈快照转储到文件系统，然后可以用其他工具去排查。visualvm是一款很不错的gui调试工具，可以远程登录主机以便访问其jvm的状态并进行监控。class文件结构class文件结构比较复杂，首先jvm定义了一个class文件的规则，并且让jvm按照这个规则去验证与读取。开头是一串魔数，然后接下来会有各种不同长度的数据，通过class的规则去读取这些数据，jvm就可以识别其内容，最后将其加载到方法区。JVM的类加载机制jvm的类加载顺序是bootstrap类加载器，extclassloader加载器，最后是appclassloader用户加载器，分别加载的是jdk/bin ，jdk/ext以及用户定义的类目录下的类（一般通过ide指定），一般核心类都由bootstrap和ext加载器来加载，appclassloader用于加载自己写的类。双亲委派模型，加载一个类时，首先获取当前类加载器，先找到最高层的类加载器bootstrap让他尝试加载，他如果加载不了再让ext加载器去加载，如果他也加载不了再让appclassloader去加载。这样的话，确保一个类型只会被加载一次，并且以高层类加载器为准，防止某些类与核心类重复，产生错误。defineclass findclass和loadclass类加载classloader中有两个方法loadclass和findclass，loadclass遵从双亲委派模型，先调用父类加载的loadclass，如果父类和自己都无法加载该类，则会去调用findclass方法，而findclass默认实现为空，如果要自定义类加载方式，则可以重写findclass方法。常见使用defineclass的情况是从网络或者文件读取字节码，然后通过defineclass将其定义成一个类，并且返回一个Class对象，说明此时类已经加载到方法区了。当然1.8以前实现方法区的是永久代，1.8以后则是元空间了。JVM虚拟机字节码执行引擎jvm通过字节码执行引擎来执行class代码，他是一个栈式执行引擎。这部分内容比较高深，在这里就不献丑了。编译期优化和运行期优化编译期优化主要有几种1 泛型的擦除，使得泛型在编译时变成了实际类型，也叫伪泛型。2 自动拆箱装箱，foreach循环自动变成迭代器实现的for循环。3 条件编译，比如if(true)直接可得。运行期优化主要有几种1 JIT即时编译Java既是编译语言也是解释语言，因为需要编译代码生成字节码，而后通过解释器解释执行。但是，有些代码由于经常被使用而成为热点代码，每次都编译太过费时费力，干脆直接把他编译成本地代码，这种方式叫做JIT即时编译处理，所以这部分代码可以直接在本地运行而不需要通过jvm的执行引擎。2 公共表达式擦除，就是一个式子在后面如果没有被修改，在后面调用时就会被直接替换成数值。3 数组边界擦除，方法内联，比较偏，意义不大。4 逃逸分析，用于分析一个对象的作用范围，如果只局限在方法中被访问，则说明不会逃逸出方法，这样的话他就是线程安全的，不需要进行并发加锁。1JVM的垃圾回收1 GC算法：停止复制，存活对象少时适用，缺点是需要两倍空间。标记清除，存活对象多时适用，但是容易产生随便。标记整理，存活对象少时适用，需要移动对象较多。2 GC分区，一般GC发生在堆区，堆区可分为年轻代，老年代，以前有永久代，现在没有了。年轻代分为eden和survior，新对象分配在eden，当年轻代满时触发minor gc，存活对象移至survivor区，然后两个区互换，等待下一场gc，当对象存活的阈值达到设定值时进入老年代，大对象也会直接进入老年代。老年代空间较大，当老年代空间不足以存放年轻代过来的对象时，开始进行full gc。同时整理年轻代和老年代。一般年轻代使用停止复制，老年代使用标记清除。3 垃圾收集器serial串行parallel并行它们都有年轻代与老年代的不同实现。然后是scanvage收集器，注重吞吐量，可以自己设置，不过不注重延迟。cms垃圾收集器，注重延迟的缩短和控制，并且收集线程和系统线程可以并发。cms收集步骤主要是，初次标记gc root，然后停顿进行并发标记，而后处理改变后的标记，最后停顿进行并发清除。g1收集器和cms的收集方式类似，但是g1将堆内存划分成了大小相同的小块区域，并且将垃圾集中到一个区域，存活对象集中到另一个区域，然后进行收集，防止产生碎片，同时使分配方式更灵活，它还支持根据对象变化预测停顿时间，从而更好地帮用户解决延迟等问题。

【问题现象】SPECjvm2008测试过程中startup.compiler.sunflow堵塞一直卡住问题，执行java -jar SPECjvm2008.jar -base -ikv后卡在如下界面【解决方法】1、修改Main.java文件vim /SPECjvm2008/src/spec/benchmarks/compiler/sunflow/Main.java在第28行增加"-nowarn", 【注意，有逗号】，如下截图所示：2、进入/SPECjvm2008/路径解压build-tools.zipcd /SPECjvm2008/unzip build-tools.zip3、重新编译SPECjvm2008bash ./build-specjvm.sh4、查看编译后的文件ls build/release/SPECjvm2008/5、到/SPECjvm2008/build/release/SPECjvm2008/路径下运行SPECjvm测试cd /SPECjvm2008/build/release/SPECjvm2008/java -jar SPECjvm2008.jar --basejava -jar SPECjvm2008.jar --peak

编者按：两位笔者分享了不同的案例，一个是因为 JDK 小版本升级后导致运行出错，最终分析定位原因为应用启动脚本中指定了 Classpath 导致 JVM 加载了同一个类的不同版本，而 JVM 在选择加载的类则是先遇到的先加载，进而导致应用出错，该问题的根因是设置了错误的 Classpath。第二个案例是在相同的 OS、JDK 和应用，不同的文件系统导致应用运行的结果不一致，最终分析定位的原因是 JVM 在加载类时遇到了多个版本的问题，但是该问题的根因是没有指定 Classpath，JVM 加载类会依赖于 OS 读取文件的顺序，而不同的文件系统导致提供文件的顺序不同，导致了问题的发生。经过这两个案例的分析，可以得到 2 个结论：需要指定 Classpath 避免不同文件系统（或者 OS）提供不同的文件顺序；需要正确地指定 Classpath，避免加载错误的类。希望读者可以了解 JVM 加载类文件的基本原理，避免出现类似错误。1 问题1现象某产品线进行 JDK 升级，将 JDK 版本从 8u181 升级到 8u191 后，日志中报出大量 java.lang.NoSuchFieldError，导致基本服务功能不可用。 具体报错如下：2 分析从这个调用栈来看，问题可能出现在 JDK 自身，并没有涉及到业务代码。首先自然应该去看一下 ClientHandshaker.java 的源码，确认一下出错时的上下文。先看 JDK 8u191 的代码，相关如下：可以看到，虽然这里对 handshakeState 进行了 check，但是代码中完全没有出现 state 这个变量；那么 8u181 又如何呢？继续看代码：这里的实现方式和 8u191 中有明显的不同，其中最重要的一点是，在 194 行中确确实实访问了 state 这个变量。追踪一下代码可以得知，ClientHandshaker 类继承自 Handshaker 类，state 也是从父类之中继承过来的一个 field。 于是，可以得到一个初步的结论：JDK 8u191 中，ClientHandshaker 的实现方式与 8u181 不同，去除了 state 这个 field。既然报错报了这个 field，因此可以确定，JVM 中加载的 ClientHandshaker 肯定不是 8u191 中的这一个。 那么，可能是产品线在替换 JDK 时，没有替换完全，导致残留了一部分 8u181 的东西，让 JVM 加载了？这个猜测很快就被否定了，因为行号对不上：错误栈中的行号是 198，而 8u181 代码中对 state 的访问是在 194 行。因此，为了直接推进问题，最好的办法就是确定 JVM 到底是从哪里加载了 ClientHandshaker。在 java 启动命令中加入如下参数，就可以追踪每一个 class 的加载：java -XX:+TraceClassLoading会产生类似于下面的输出：（加载的类 + 类的来源）从这个输出中搜索一下 ClientHandshaker，最终发现了这么一行：[Loaded sun.security.ssl.ClientHandshaker from /mypath2/lib/alpn-boot.jar]果然，出问题的 ClientHandshaker 并不是加载自 JDK 8u191 中，而是加载自 alpn-boot.jar 这个包。那么这个包又是从哪里找到的？检查了一下产品线的 java 启动命令，发现里面用 -cp 参数指定了许多 Classpath 路径，最后从里面找到了 "/mypath2/lib/alpn-boot.jar"。到这个目录下，找到产品线所使用的 jar 包，然后将其中包含的 ClientHandshaker.class 反编译后，发现代码基本与 8u181 代码相同——也访问了 state，并且连行号（198）也能对应上。到此，根因基本确定。alpn-boot.jar 是 Jetty 中用来实现 TLS 的扩展。产品线当时所使用的 alpn 版本是 8.1.12.v20180117，根据官方文档，这个版本只能兼容到 JDK 8u181，而 8u191 之后，alpn 的版本也应有相应的变化，以兼容新的 JDK 代码。 为什么当时 alpn 没有自动适应 JDK 版本？因为产品的启动脚本里写死了那个老版本的 alpn-boot.jar，而在升级的时候却没有适配启动脚本。3 问题2现象笔者将相同的 java 应用和 JDK 部署在 Linux 环境中，一台机器上运行正常，另外一台和预期不一样。对于这个现象我们非常奇怪，从问题表象应该是外部环境导致了运行结果不同，为此我们对软件、硬件、环境进行排查，发现 2 台机器除了使用的文件系统不同外，其他并无不同。为什么不同的文件系统会影响 JVM 的运行结果？根源在哪里？通过排查发现有两个 jar 中存在全限定名相同的两个主类，那么 JDK 会去选择哪个主类加载呢，对于 Classpath 通配符 JDK 又是如何解析的，下面笔者对上面问题进行分析。4 环境介绍准备两台 Linux 机器，其中一台文件系统为 ext4，另一台为 xfs。可以使用 df -T 命令查看使用的文件系统。复现问题的方式非常简单，可以创建两个全限定名一样的类，然后编译打成 jar 包放在同一个目录中。运行 java 进程时，指定的 Classpath 路径使用通配符。可以通过下面的 demo 复现这个问题。• Demo 的目录结构moduleA Main.javamoduleB Main.java• 编译及打包先使用 java 命令将这两个类编译，然后分别使用 jar 命令打包到 moduleA.jar 和 moduleB.jar 中，并保存在 lib 目录中。切换到 demo 目录，执行如下命令进行编译、打包。• 运行5 测试结果对于不同文件系统的环境，输出的结果可能不同，下面以 ext 和 xfs 文件系统为例，可以看到输出不同的结果。• ext4moduleA.jar 创建时间早于 moduleB.jar，输出 module B。moduleA.jar 创建时间晚于 moduleB.jar，输出 module B。无论是先创建 moduleA.jar 还是 moduleB.jar，最终的输出结果都是 module B。• xfsmoduleA.jar 创建时间早于 moduleB.jar，输出 module A。moduleA.jar 创建时间晚于 moduleB.jar，输出 module B。如果先创建 moduleA.jar，然后创建 moduleB.jar，输出的结果是 module A；反之，输出的结果是 module B。6 原因分析6.1 排查方法使用 JDK 8 进程启动时，添加 VM 参数 -XX:+TraceClassPaths -XX:+TraceClassLoading。其中以 ext 文件系统为例，可以得到如下的日志：从日志可以发现 Classpath 解析后的路径是 moduleB.jar 在 moduleA.jar 之前，并且加载的是 moduleB.jar 的类。对于解析后的 Classpath，还可以通过添加 -XshowSettings 选项查看。对于常驻进程，查看通配符解析后的 Classpath，可以使用 jcmd 命令查看。当然使用 jconsole 或者 visualvm 等工具连接进程也可以查看解析后的 Classpath。6.2 Classpath 通配符如何解析以 Linux 系统为例，在 Classpath 中使用冒号分割多个路径，并且按照定义的顺序进行通配符解析。如下所示，任何文件系统解析出来的路径始终是 lib 目录的 jar 包在 lib2 目录的 jar 包之前。JVM 在解析通配符 * 时，最终会调用系统函数 opendir、readdir 读取遍历目录。ext4 创建文件的顺序与实际 readdir 读取的顺序不一致的原因主要在于 ext 系列文件系统有个 feature，即 dir_index，用于加快查找目录项（可直接计算其 hash 值定位到它的目录项），目录项也便成了以 hash 值大小进行排序。通常 dir_index 默认开启，可以通过 / etc/mke2fs.conf 查看默认配置。创建一个 test_readdir.c 文件，用 C 语言实现一个 demo。通过调用系统 readdir 遍历目录，并且打印文件的 d_off、d_name 属性值。编译、执行命令如下所示：编译执行test_readdir.c 文件运行结果分别在 ext4、xfs 文件系统上按顺序创建 m1~m10 文件，然后查看运行结果。对比发现 readdir 函数在不同文件系统中都是按照 d_off 属性值从小到大顺序进行遍历，不同的是 xfs 文件 d_off 的值按照创建时间依次增大，而 ext4 和文件的创建顺序无关。ext4xfs6.3 解决办法&修复方法可以将需要加载的主类所在的 jar 包存放在新创建的文件目录 libmain 下，并且将libmain 目录放在 lib 目录之前，则指定 Classpath 路径的顺序如下所示：.:/home/user/demo/libmain/*:/home/user/demo/lib/*后记如果遇到相关技术问题（包括不限于毕昇 JDK），可以进入毕昇 JDK 社区查找相关资源（点击阅读原文进入官网），包括二进制下载、代码仓库、使用教学、安装、学习资料等。毕昇 JDK 社区每双周周二举行技术例会，同时有一个技术交流群讨论 GCC、LLVM、JDK 和 V8 等相关编译技术，感兴趣的同学可以添加如下微信小助手，回复 Compiler 入群。

编者按：笔者通过在 Hive 的场景发现 AppCDS 技术存在的价值，然后分析了 AppCDS 的工作原理，并将 JDK 11 中的特性移植到毕昇 JDK 8，在移植过程中由于 JDK 8 和 JDK 11 在类加载实现有所不同，JDK 11 在加载过程中增强了安全性检查，为了达到相同的效果没有对 JDK 8 中的类加载进行修改，而是通过额外的安全检查保证共享类的安全性。最后笔者介绍了如何使用 AppCDS 以及使用的注意事项，希望对读者有所帮助。基于某产品集群业务中有使用 Hive 场景，我们发现该集群在执行任务时会启动大量的 Java 进程，且进程很快就执行结束。对于这种情况一个有效的解决方法是让 Java 进程之间重用部分公共数据，从而减少 Java 进程产生公共数据的耗时。在 JDK 11 中支持 CDS 和 AppCDS，CDS 的全称是 Class-Data Sharing，CDS 的作用是可以让类被预处理放到一个归档文件中，后续 Java 程序启动的时候可以直接带上这个归档文件，这样 JVM 可以直接将这个归档文件映射到内存中，以节约应用启动的时间。AppCDS 是 CDS 的扩展，不止能够作用于 Boot Class Loader，App Class Loader 和自定义的 Class Loader 也都能够起作用，加大了 CDS 的适用范围 [1]。技术原理是让多个 Java 进程共享类的元数据，其基本原理如下所示：左右两边分别都是一个 Java 进程，双方通过共享内存达到节约内存、减少类解析的目的。下面通过案例介绍一下我们发现的现象，然后再介绍类共享机制的内部原理。1. 技术背景1.1环境介绍Hive on tez 集群，4 个节点，一个管理节点，其他三个节点作为工作节点。软件版本：Hadoop 3.1.0，hive 3.1.2，tez-0.9.1，ambari2.6，TPC-DS 标准测试套。硬件环境： Kunpeng 920，128 核，512G 内存。1.2系统负载情况运行 TPC-DS 自带的 sql8，使用 top 观察其中的一个节点的工作负载，发现启动了大量的 JVM 进程。1.3 热点分布    同时使用 perf 采集整机的热点数据，发现 JVM 的 C1, C2 编译线程占比很高，如下图所示。因此判断 hive sql 的 startup 和 warmup 阶段占比比较高，可以考虑从这两个方向优化。考虑到目前 JVM 的 C2 代码比较难维护，也很难引进新的 feature。因此考虑看看在启动阶段有没有优化的可能。jdk1.8 带有 cds 功能，能够 share jdk 自带的 java class，能够减少 JVM 的类加载时间，因此首先尝试使用默认的 cds 功能，测试发现效果不明显。原因是 hive sql 执行过程中加载的类大部分是应用程序 classpath 下的类，jdk 自身的类占比很小，因此收益不明显。考虑到 jdk10 以后有了 AppCDS 功能，能够 share classpath 下的 class，因此考虑在 jdk1.8 上面实现 AppCDS 功能。2. AppCDS 实现毕昇 JDK 支持 AppCDS，即在原生 CDS 的基础上也支持用户自己程序 classpath 中的类共享。原生 CDS 只支持由 Bootstrap classloader 和 Ext Classloader 加载的 class，即 jdk 自带的 class 在多进程之间共享。但是在实际场景中，尤其是在使用了大量开源软件的情况下，用户指定 classpath 下的 jar 远远大于 jdk 自带的 class，这样 CDS 的实际效果比较有限。    AppCDS 能够扩大 class 共享的范围，从而在节省内存使用以及 JVM 的启动时间两个方面进一步提升效果。2.1 create class list 文件java class 文件被 JVM 执行之前首先要被加载进 JVM 内存里面，作为 meta data 存储在 JVM 的 metaspace 内存区域。其中一个关键步骤就是解析 class 文件。JVM 内部有个 ClassFileParser 类，提供了 parseClassFile 方法，解析成功之后会生成一个对应 Klass。AppCDS 的第一步逻辑就是在类被解析完成之后，如果 class 不是匿名类，且 class 文件的 major version 大于 JAVA_1_5 Version，则会把 class 对应的 qualified name 写去到 list 文件中去。2.2 create jsa 归档文件在这一步 JVM 会按行读取 appcds.lst 文件中内容，然后使用 App ClassLoader 去加载对应的 class。由于 Java classloader 自身的 delegate 机制，能够确保 jdk 自身的 class 也能够得到加载。Class 被加载之后存在 JVM 的 metaspace 区域，这个 metaspace 是 JVM Native Memory 的一部分，里面包含 klass, ConstantPool, Annotation, ConstMethod, Method, MethodData 等 meta 信息。    当 lst 文件中对应的 class 都被 JVM 加载完成之后，JVM 会把其对应的 metadata 写入到从虚拟地址 0x800000000 开始的内存区域，其格式是 JVM 内部私有的一种表示，然后再把这部分数据 dump 到归档文件中。2.3 与 JDK 11 实现的差别与 JDK 11 中的 AppCDS 实现差别主要体现在加载用户指定的 class 逻辑上。当加载用户 class 时，是需要计算获取一个 ProtectionDomain 来做安全验证的。JDK 11 是直接在 hotspot 中使用 JavaCalls 模块构造这个 ProtectionDomain，而毕昇 JDK 8 是在 Java 的 ClassLoader 中提供了一个 getProtectionDomainInternal 函数来获取，并在加载 class 的时候使用 JavaCalls 调用这个 java 方法。3. AppCDS使用说明3.1 创建 lst 文件启动 JVM 的时候添加 - Xshare:off 和 - XX:+DumpLoadedClassList=/path/to/class.lst 这两个选项。这里比较重要的是第二个选项，这个选项同时支持 %P，可以按进程生成 class.lst 文件，生成的文件名会带上 JVM 进程的 pid。class.lst 本质上是个纯文本文件，里面记录 JVM 运行过程中加载的 class 列表。在 java 程序被 JVM 执行的过程中，会不断地从 classpath 中加载 class，并在 JVM 内部创建对应的 klass 对象。Klass 对象创建成功之后 JVM 会把 class 在 JVM 内部的 qualified name 写入到 class.lst 文件中，比如 java.lang.Objectd 对应的是 java/lang/Object。使用例子：java -Xms16M -Xmx16M -XX:+UseG1GC -cp test.jar -Xshare:off -XX:+UseAppCDS -XX:DumpLoadedClassList=appcds.lst com.example.App3.2 创建 archive 文件第二步：创建 cds 归档文件。使用方式：java -Xms16M -Xmx16M -XX:+UseG1GC -cp test.jar -Xshare:dump -XX:+UseAppCDS -XX:SharedClassListFile=appcds.lst -XX:SharedArchiveFile=appcds.jsa com.example.App3.3 使用 archive 文件使用示例：java -Xms16M -Xmx16M -XX:+UseG1GC -cp test.jar -Xshare:on -XX:+UseAppCDS -XX:SharedArchiveFile=appcds.jsa com.example.App    第三步：JVM 在启动的过程中会把 jsa mmap 到内存中，然后在触发类加载时候 JVM 会首先尝试从这块 mmap 进来的内存中去获取 klass 对象，如果获取到则会更新 JVM 内部的 SystemDictionary，以后再来获取对应的 klass 对象则不需要从 jsa 中获取。如果获取失败，JVM 则会走正常的类加载流程，尝试从 classpath 中加载对应的 class 文件，解析，链接，初始化，然后再放入 SystemDictionary 中。4. AppCDS 效果TPC-DS 测试套的 10 个 sql 在 5T 数据的场景下测试了一下 AppCDS 的效果，结果收益好，最低是 8.42% 的性能提升，最高是 26.9% 的性能提升。5. 注意事项1. 使用 AppCDS 三部曲过程中要保持 JVM 版本、JAVA_HOME 路径一致，不然会校验失败，无法启动 JVM。2. 在第二步加载 class 并创建 jsa 归档文件的时候，JVM 会记录 class 的 fingerprint 信息 （相当于 hash 值），在第三步使用 jsa 中的 class 信息时会校验这个 fingerprint 信息，因此如果业务侧代码发生变更，要重新部署的话，jsa 归档文件要重新制作。3. 使用 AppCDS 或者 CDS 的时候不能 debug java 程序。因为 debug 的时候 jvmti 会修改 class 对应的内容，而根据第二点，必然会导致 fingerprint 不一致。4. 目前 AppCDS 并不支持 Custom ClassLoader，因此在 tomcat、jetty、SpringBoot 这些使用较多 Custom ClassLoader 场景的，整体收益跟原生 CDS 应该差不多，class 可以 share 的范围仅仅多了一些 Application 自身的 boot class。后记如果遇到相关技术问题（包括不限于毕昇 JDK），可以进入毕昇 JDK 社区查找相关资源（点击阅读原文进入官网），包括二进制下载、代码仓库、使用教学、安装、学习资料等。毕昇 JDK 社区每双周周二举行技术例会，同时有一个技术交流群讨论 GCC、LLVM、JDK 和 V8 等相关编译技术，感兴趣的同学可以添加如下微信小助手，回复 Compiler 入群。参考[1] https://juejin.cn/post/6844903581246914574

编者按：JVM 发生内存泄漏，如何能快速定位到内存泄漏点并不容易。笔者通过使用 jemalloc（可以替换默认的 glibc 库）中的 profiling 机制（通过对程序的堆空间进行采样收集相关信息），演示了如何快速找到内存泄漏的过程。Java 的内存对象一般可以分为堆内内存、堆外内存和 Native method 分配的内存，对于前面两种内存，可以通过 JVM 的 GC 进行管理，而 Native method 则不受 GC 管理，很容易引发内存泄露。Native Method 导致的内存泄漏，无法使用 JDK 自带的工具进行分析，需要通过 malloc_hook 追踪 malloc 的调用链帮助分析，一般可以采用内存分配跟踪工具（malloc tracing）协助分析内存泄漏。该工具的使用较复杂：需要修改源码，装载 hook 函数，然后运行修改后的程序，生成特殊的 log 文件，最后利用 mtrace 工具分析日志来确定是否存在内存泄露并分析可能发生内存泄露的代码位置。由于 hotspot 代码量较大，虽然可以通过一些选项逐步缩小可疑代码范围，但是修改代码总不是最优选择。另外，Valgrind 扫描也是一种常用的内存泄露分析工具，虽然 Valgrind 非常强大，但是 Valgrind 会报出很多干扰项，且使用较为麻烦。本文主要是介绍另一种分析 Native method 内存泄漏的方法，供大家参考。jemalloc 是通过 malloc(3) 实现的一种分配器，代替 glibc 中的 malloc 实现，开发人员通过 jemalloc 的 Profiling 功能分析内存分配过程，可帮助解决一些 Native method 内存泄漏问题。1 jemalloc 使用方法​jemalloc 使用方法的详细介绍，请参考本文附录章节。2 使用 jemalloc 工具解决实际业务中遇到 Native method 内存泄漏问题​毕昇 JDK 某个版本内部迭代开发期间，在特性功能开发测试完毕后，进行 7*24 小时长稳测试时发现开启 - XX:+UseG1GC 选项会导致内存迅速增加，怀疑 JVM 层面存在内存泄露问题。Java 例子参考（例子仅作为帮助问题理解使用）：import java.util.LinkedHashMap;​public class SystemGCTest {  static int Xmx = 10;  private static final int MB = 1024 * 1024;  private static byte[] dummy;  private static Integer[] funny;  private static LinkedHashMap<Integer, Integer[]> map = new LinkedHashMap<>();​  public static void main(String[] args) {      int loop = Integer.valueOf(args[0]);      if (loop < 0) {          loop = loop * -1;          while (true) {              doGc(loop);              map.clear();              System.gc();          }      } else {          doGc(loop);          map.clear();          System.gc();      }  }​  private static void doGc(int numberOfTimes) {      final int objectSize = 128;      final int maxObjectInYoung = (Xmx * MB) / objectSize;      for (int i = 0; i < numberOfTimes; i++) {          for (int j = 0; j < maxObjectInYoung + 1; j++) {              dummy = new byte[objectSize];              funny = new Integer[objectSize / 16];              if (j % 10 == 0) {                  map.put(Integer.valueOf(j), funny);              }          }      }  }}上图是开启 - XX:+UseG1GC 选项，Java 进程内存增长曲线图。横坐标是内存使用的统计次数，每 10 分钟统计一次；纵坐标是 Java 进程占用物理内存的大小。从上图可以看出：物理内存持续增涨的速度很快，存在内存泄露问题。我们在设置了 jemalloc 的环境下，重新运行该测试用例：java -Xms10M -Xmx10M -XX:+UseG1GC SystemGCTest 10000​注意：10000 与 jemalloc 无关，是 SystemGCTest 测试用例的参数，java 是疑似存在内存泄漏的 Java 二进制文件。程序启动后，会在当前目录下逐渐生成一些 heap 文件，格式如：jeprof.26205.0.i0.heap。jeprof 工具的环境变量设置正确后（可参考本文附录），开发可以直接执行 jeprof 命令查看运行结果，了解 jeprof 的使用方式。jeprof 可基于 jemalloc 生成的内存 profile 堆文件，进行堆文件解析、分析并生成用户容易理解的文件，工具使用方便。下面我们通过上述内存泄露问题，简单介绍 jeprof 工具的典型使用方法。jeprof 工具可以生成内存申请代码的调用路径图。上述 Java 例子运行一段时间后会产生一些 heap 文件，jeprof 可帮助开发者获取有助于分析的可视化文件。方法 1，通过使用 jeprof 工具将这些 heap 文件转成 svg 文件，命令如下：jeprof --show_bytes --svg /home/xxxx/jdk1.8.0_292/bin/java jeprof*.heap > app-profiling.svg这里需要注意的是：/home/xxxx/jdk1.8.0_292/bin/java 必须是绝对路径。注意：执行生成 svg 文件的命令时，部分环境会遇到类似如下错误：Dropping nodes with <= 2140452 B; edges with <= 428090 abs(MB)dot: command not found该问题的解决方法，需要在环境中安装 graphviz 和 gv：sudo apt install graphviz gv安装成功后，再次执行方法 1 中命令，可以得到可视化 svg 文件。测试用例执行三十分钟后，我们对最后十分钟的内存增长进行分析，结果发现：95.9% 的内存增长来自 G1DefaultParGCAllocator 的构造函数调用，这里的最后 10 分钟是和用例设置相关，如下图所示：​上图比较清晰显示了内存申请相关函数的调用关系以及内存申请比例和数量，约 95.9% 的堆内存是通过 G1DefaultParGCAllocator 完成申请，可以预测在 G1DefaultParGCAllocator 的构造函数中申请的内存没有被及时回收掉而导致内存泄漏的可能性非常大。这个时候可以通过代码协助分析了。jeprof 工具不仅可以查看详细信息或者生成调用路径图（如上图所示），还可以用来比较两个 dump 文件（显示增量部分），既然作为工具使用介绍，我们继续介绍另一种补充性分析方法：将连续两次的 heap 文件做差异对比，输出的 PDF 可视化文件可以进一步确定是哪里内存持续申请没有被释放而导致内存增长。方法如下：jeprof --base=jeprof.34070.0.i0.heap --pdf /home/xxxx/jdk1.8.0_292/bin/java jeprof.34070.1.i1.heap > diff.pdf内存增加差异图：​通过上图可以非常清晰看到：G1DefaultParGCAllocator 的构造函数持续申请内存，导致内存增长迅速。后续的工作就是针对 G1DefaultParGCAllocator 构造函数中内存申请情况，排查释放逻辑，寻找问题原因并解决，这块的工作不属于 jemalloc 范畴，本内容不再赘述。代码修复后 Java 进程物理内存使用情况如下（运行 30 小时 +）：内存使用符合预期，问题解决。​通过 jemalloc 工具和上面介绍的方法，帮助开发快速解决了此特性引起 Native method 内存泄漏问题，方法使用简单。在实际业务中有遇到类似问题的同学，不妨亲自尝试一下。附录：jemalloc 的编译jemalloc 普通版并不包含 profiling 机制，所以需要下载源代码重新编译，在 configure 的时候添加了 --enable-prof 选项，这样才能打开 profiling 机制。(1) 下载最新版本 jemalloc 源码git clone https://github.com/jemalloc/jemalloc.git(2) jemalloc 源码构建(a) 修改 autogen.sh 文件，使能 prof，如下：diff --git a/autogen.sh b/autogen.shindex 75f32da6..6ab4053c 100755--- a/autogen.sh+++ b/autogen.sh@@ -9,8 +9,8 @@ for i in autoconf; do    fidone​-echo "./configure --enable-autogen $@"-./configure --enable-autogen $@+echo "./configure --enable-prof $@"+./configure --enable-prof $@if [ $? -ne 0 ]; then    echo "Error $? in ./configure"    exit 1执行：$ ./autogen.sh$ make -j 6以下命令可选：$ make install (b) 源码构建成功后（一般不会出错），会在当前目录的bin和lib目录下生成重要的文件：$ ls -ltotal 376-rw-rw-r-- 1 xxxx xxxx   1954 Jun 19 06:16 jemalloc-config-rw-rw-r-- 1 xxxx xxxx   1598 Jun 19 06:12 jemalloc-config.in-rw-rw-r-- 1 xxxx xxxx   145 Jun 19 06:16 jemalloc.sh-rw-rw-r-- 1 xxxx xxxx   151 Jun 19 06:12 jemalloc.sh.in-rw-rw-r-- 1 xxxx xxxx 182460 Jun 19 06:16 jeprof-rw-rw-r-- 1 xxxx xxxx 182665 Jun 19 06:12 jeprof.in$ cd ../lib/$ ls -ltotal 89376-rw-rw-r-- 1 xxxx xxxx 42058434 Jun 19 06:19 libjemalloc.a-rw-rw-r-- 1 xxxx xxxx 42062016 Jun 19 06:19 libjemalloc_pic.alrwxrwxrwx 1 xxxx xxxx       16 Jun 19 06:19 libjemalloc.so -> libjemalloc.so.2-rwxrwxr-x 1 xxxx xxxx 7390832 Jun 19 06:19 libjemalloc.so.2$ pwd/home/xxxx/jemalloc/jemalloc/lib(c) 设置环境变量和执行权限bin 目录下的 jeprof 文件，没有执行权限，需要设置一下：bin$ chmod +x ./*退到 bin 的上一层目录设置环境变量，可参考如下方法：xxxx@hostname:jemalloc$ echo $JEMALLOC_DIR​xxxx@hostname:jemalloc$ export JEMALLOC_DIR=`pwd`xxxx@hostname:jemalloc$ echo $JEMALLOC_DIR/home/xxxx/jemalloc/jemallocxxxx@hostname:jemalloc$ export LD_PRELOAD=$JEMALLOC_DIR/lib/libjemalloc.soxxxx@hostname:jemalloc$ export MALLOC_CONF=prof:true,lg_prof_interval:30,lg_prof_sample:17xxxx@hostname:jemalloc$ which jeprofxxxx@hostname:jemalloc$ export PATH=$PATH:$JEMALLOC_DIR/binxxxx@hostname:jemalloc$ which jeprof/home/xxxx/jemalloc/jemalloc/bin/jeprofxxxx@hostname:jemalloc$ jeprof --versionjeprof (part of jemalloc 5.2.1-737-g2381efab5754d13da5104b101b1e695afb442590)based on pprof (part of gperftools 2.0)​Copyright 1998-2007 Google Inc.​This is BSD licensed software; see the source for copying conditionsand license information.There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR APARTICULAR PURPOSE.到这一步，jeprof 可以在该环境中启动使用了。后记如果遇到相关技术问题（包括不限于毕昇 JDK），可以进入毕昇 JDK 社区查找相关资源（点击阅读原文进入官网），包括二进制下载、代码仓库、使用教学、安装、学习资料等。毕昇 JDK 社区每双周周二举行技术例会，同时有一个技术交流群讨论 GCC、LLVM、JDK 和 V8 等相关编译技术，感兴趣的同学可以添加如下微信小助手，回复 Compiler 入群。参考%4. https://chenhm.com/post/2018-12-05-debuging-java-memory-leak %4. https://github.com/jemalloc/jemalloc %4. https://blog.csdn.net/qq_36287943/article/details/105491301 %4. https://www.cnblogs.com/minglee/p/10124174.html %4. https://www.yuanguohuo.com/2019/01/02/jemalloc-heap-profiling /

编者按：笔者使用 JDK 自带的内存跟踪工具 NMT 和 Linux 自带的 pmap 解决了一个非常典型的资源泄漏问题。这个资源泄漏是由于 Java 程序员不正确地使用 Java API 导致的，使用 Files.list 打开的文件描述符必须关闭。本案例一方面介绍了怎么使用 NMT 解决 JVM 资源泄漏问题，如果读者遇到类似问题，可以尝试用 NMT 来解决；另一方面也提醒 Java 开发人员使用 Java API 时需要必须弄清楚 API 使用规范，希望大家通过这个案例有所收获。背景知识：·NMTNMT 是 Native Memory Tracking 的缩写，一个 JDK 自带的小工具，用来跟踪 JVM 本地内存分配情况（本地内存指的是 non-heap，例如 JVM 在运行时需要分配一些辅助数据结构用于自身的运行）。NMT 功能默认关闭，可以在 Java 程序启动参数中加入以下参数来开启：-XX:NativeMemoryTracking=[summary | detail]其中，"summary" 和 "detail" 的差别主要在输出信息的详细程度。开启 NMT 功能后，就可以使用 JDK 提供的 jcmd 命令来读取 NMT 采集的数据了，具体命令如下：jcmd <pid> VM.native_memory [summary | detail | baseline | summary.diff | detail.diff | shutdown]NMT 参数的含义可以通过 "jcmd <pid> help VM.native_memory" 命令查询。通过 NMT 工具，我们可以快速区分内存泄露是否源自 JVM 分配。·pmap对于非 JVM 分配的内存，经常需要用到 pmap 这个工具了，这是一个 linux 系统自带工具，能够从系统层面输出目标进程内存使用的详细情况，用法非常简单：    pmap [参数] <pid>常用的选项是 "-x" 或 "-X"，都是用来控制输出信息的详细程度。上图是 pmap 部分输出信息，每列含义为Address每段内存空间起始地址Kbytes每段内存空间大小（单位KB）RSS每段内存空间实际使用内存大小（单位KB）Dirty每段内存空间脏页大小（单位KB）Mode每段内存空间权限属性Mapping可以映射到文件，也可以是“anon”表示匿名内存段，还有一些特殊名字如“stack”现象：某业务集群中，多个节点出现业务进程内存消耗缓慢增长现象，以其中一个节点为例：如图所示，这个业务进程当前占用了4.7G的虚拟内存空间，以及2.2G的物理内存。已知正常状态下该业务进程的物理内存占用量不超过1G。分析：使用命令 "jcmd <pid> VM.native_memory detail" 可以看到所有受 JVM 监控的内存分布情况：上图只是截取了 nmt(Native Memory Tracking) 命令展示的概览信息，这个业务进程占用的 2.2G 物理内存中，受 JVM 监控的大概只占了 0.7G（上图中的 committed），意味着有 1.5G 物理内存不受 JVM 管控。JVM 可以监控到 Java 堆、元空间、CodeCache、直接内存等区域，但无法监控到那些由 JVM 之外的 Native Code 申请的内存，例如典型的场景：第三方so库中调用malloc函数申请一块内存的行为无法被JVM感知到。nmt 除了会展示概览之外，还会详细罗列每一片受 JVM 监控的内存，包括其地址，将这些 JVM 监控到的内存布局和用 pmap 得到的完整的进程内存布局做一个对比筛查，这里忽略 nmt 和 pmap（下图 pmap 命令中 25600 是进程号）详细内存地址的信息，直接给出最可疑的那块内存：由图可知，这片1.7G左右的内存区域属于系统层面的堆区。备注：这片系统堆区之所以稍大于上面计算得到的差值，原因大概是 nmt 中显示的 committed 内存并不对应真正占用的物理内存（linux 使用 Lazy 策略管理进程内存），实际通常会稍小。系统堆区主要就是由 libc 库接口 malloc 申请的内存组合而成，所以接下来就是去跟踪业务进程中的每次 malloc 调用，可以借助GDB：实际上会有大量的干扰项，这些干扰项一方面来自 JVM 内部，比如：这部分干扰项很容易被排除，凡是调用栈中存在 "os::malloc" 这个栈帧的干扰项就可以直接忽视，因为这些 malloc 行为都会被 nmt 监控到，而上面已经排除了受 JVM 监控内存泄漏的可能。另一部分干扰项则来自 JDK，比如：有如上图所示，不少 JDK 的本地方法中直接或间接调用了 malloc，这部分 malloc 行为通常是不受 JVM 监控的，所以需要根据具体情况逐个排查，还是以上图为例，排查过程如下：注意图中临时中断的值（0x0000ffff5fc55d00）来自于第一个中断 b malloc 中断发生后的结果。这里稍微解释一下上面 GDB 在做的排查过程，就是检查 malloc 返回的内存地址后续是否有通过 free 释放（通过 tb free if $x0 ==$X3 这个命令，具体用法可以参考 GDB 调试），显然在这个例子中是有释放的。通过这种排查方式，几经筛选，最终找到了一个可疑的 malloc 场景：从调用栈信息可以知道，这是一个 JDK 中的本地方法 sun.nio.fs.UnixNativeDispatcher.opendir0，作用是打开一个目录，但后续始终没有进行关闭操作。进一步分析可知，该可疑 opendir 操作会周期性执行，而且都是操作同一个目录 "/xxx/nginx/etc/nginx/conf"，看来，是有个业务线程在定时访问 nginx 的配置目录，每次访问完却没有关闭打开的目录。分析到这里，其实这个问题已经差不多水落石出。和业务方确认，存在一个定时器线程在周期性读取 nginx 的配置文件，代码大概是这样子的：翻了一下相关 JDK 源码，Files.list 方法是有在末尾注册一个关闭钩子的：也就是说，Files.list 方法返回的目录资源是需要手动释放的，否则就会发生资源泄漏。由于这个目录资源底层是会关联一个 fd 的，所以泄漏问题还可以通过另一个地方进行佐证：该业务进程目前已经消耗了51116个 fd！假设这些 fd 都是 opendir 关联的，每个 opendir 消耗32K，则总共消耗1.6G，显然可以跟上面泄漏的内存值基本对上。总结：稍微了解了一下，发现几乎没人知道 JDK 方法 Files.list 是需要关闭的，这个案例算是给大家都提了个醒。后记：如果遇到相关技术问题（包括不限于毕昇 JDK），可以进入毕昇 JDK 社区查找相关资源（点击阅读原文进入官网），包括二进制下载、代码仓库、使用教学、安装、学习资料等。毕昇 JDK 社区每双周周二举行技术例会，同时有一个技术交流群讨论 GCC、LLVM、JDK 和 V8 等相关编译技术，感兴趣的同学可以添加如下微信小助手，回复 Compiler 入群。