Cover_sky的博客

针对的是热点代码(触发JIT的条件)Client模式:32bit才有Server模式:64bit触发条件后，谁来编译，编译线程C1:Client模式下C2: Server模式下JDK6之后，混合在一起，热点代码((统计的并不是被调用的绝对次数，而是一个相对的执行频率，一段时间内方法被调用的次数))其中包括但是热点代码会有一个热度衰减的概念，

分成两个角度来看1.触发JIT之前javac编译，java运行2.触发JIT之后，运行期即时编译(C1、C2)+解释执行(模板解释器比字节码解释器高效很多)

ZGC是一款JDK11中新加入的具有实验性质的低延迟垃圾收集器，ZGC可以说源自于Azul System公司开发的C4(Concurrent Continuously Compacting Collector)收集器参考文章：https://wiki.openjdk.java.net/display/zgc/Main。

串行:一个GC线程运行并行(Parallel):指多条垃圾收集线程并行工作，但此时用户线程仍然处于等待状态。并发(Concurrent):指用户线程与垃圾收集线程同时执行(但不一定是并行的，可能会交替执行)，用户程序在继续运行，而垃圾收集程序运行于另一个CPU上。

所有的垃圾回收算法都要经历标记阶段。如果GC线程在标记的时候暂停所有用户线程(STW)，那就没三色标记什么事儿了，但是这样会有一个问题，用户线程需要等到GC线程标记完才能运行，给用户的感觉就是很卡，用户体验很差。现在主流的垃圾收集器都支持并发标记。什么是并发标记呢？就是标记的时候不暂停或少暂停用户线程，一起运行。这势必会带来三个问题:多标、少标、漏标。垃圾收集器是如何解决这个问题的呢？三色标记+读写屏障。

Java程序在运行过程中会产生大量的对象，但是内存大小是有限的，如果光用而不释放，那内存迟早被耗尽。如C/C++程序，需要程序员手动释放内存，Java则不需要，是由垃圾回收期去自动回收。垃圾回收器回收内存至少需要做两件事情:标记垃圾、回收垃圾。于是诞生了很多算法。

该命令是纯Java编写的-q:只显示Java进程的ID-m:输出Java进程的ID + main函数所在类的名字 + 传递给main函数的参数-l:输出Java进程的ID+main函数所在类的全限定名(包名+类名)-v:输出Java进程的ID+main函数所在类的名称+传递给JVM的参数应用：可以通过次方式快速查看JVM参数是否设置成功。

模拟OOM

要突破32G内存瓶颈的话，需要改写8字节对齐这条规则，8字节对齐的话，瓶颈是32G,16字节对齐，瓶颈也会扩大一倍，变成64G.但是这样需要考虑内存的使用率，因为在对齐填充的时候，补充的都是空白地址，也就是说在突破瓶颈的同时，也会带来内存空间的浪费。现在64位机器，并没有完全使用64位地址来表示，只使用了48位，剩下16位保留。也就是说，64位机器上最大使用的内存是2的48次方，原因在于CPU还没有强大到能处理这么大的内存，受制于CPU的算力例如:8字节对齐:17B+7B=24B。

前面的klass模型，它是Java类的元信息在JVM中的存在形式。这个oop模型是Java对象在JVM中的存在形式。

jdk8:底层是一个char[]数组jdk9及之后:底层是一个byte[]数组一个中文占两个字节，一个char占两个字节，一个byte占一个字节Jdk9及之后的版本中，多了一个code属性，这个属性标记是告诉调用者按几个字节来取的问题，如果按byte存储的话，存不是什么问题，问题是如何取呢？

这里要明确一点的是，在Jdk6以及以前的版本中，字符串的常量池是放在堆的Perm区的，Perm区是一个类静态的区域，主要存储一些加载类的信息，常量池，方法片段等内容，默认大小只有4m，一旦常量池中大量使用intern是会直接产生java.lang.OutOfMemoryError:PermGen Space错误的。JDK1.6及之前:有永久代，运行时常量池在永久代，运行时常量池包含字符串常量池，Perm区域只有4m,一旦常量池大量使用intern很容易发生永久代的OOM。为什么输出会有这些变化呢？

与虚拟机栈发挥的作用是相似的，他们之间的区别不过是虚拟机栈为虚拟机执行Java方法(也就是字节码)服务，而本地方法栈则为虚拟机使用到的Native方法服务。在虚拟机规范中对本地方法栈中使用、使用方式与数据结构并没有强制规定，因此具体的虚拟机可以自由实现它。甚至有的虚拟机 比如(SUn HotSpot虚拟机)直接就把本地方法栈和虚拟机栈合二为一。与虚拟机栈一样，本地方法栈区域也会抛出StackOverflowError和OutOfMemoryErr异常。

可以这样理解:JVM内存模型其实就是JVM在启动的时候从操作系统内存中要了一块大内存，然后将这个大内存分成五个区域:方法区、堆区、虚拟机栈、本地方法栈、本地方法栈、程序计数器.其实叫JVM运行时区域更合适。但是要区分JVM内存模型与JMM(Java Memory Model)InstanceKlass:类的元信息(方法区)InstanceMirrorKlass:镜像类Class对象(堆区)四个名词:class文件:即硬盘上的.class文件。

在Java字节码中，field_info结构是用来描述类或接口中的字段(成员变量的)。每个field_info结构对应类文件中的一个字段。其中它的组成部分包括如下：1.access_flags:访问标志,表示字段的访问级别(如public, private, protected, static等)和其他属性(如final volatile等)2.name_index:字段名的索引，它是一个指向常量池的索引，常量池中的对应条目包含字段的名称。

大端模式:高位存在低地址，低位存高地址小段模式：与大端模式相反。

元空间内部给各个类加载器划分了内存区域。另外还需要注意一点的是，方法区会有碎片化问题，方法区的垃圾回收通常被称为类的卸载。方法区回收之后是没有整理的。

实现方式，需要继承java.lang.ClassLoader类,通过源码查看我们也得知了ClassLoader在loadClass的时候不会立马触发解析阶段，因为源码里面就写死了是false.懒汉模式，你可能听过loadClass()和findClass()方法，两者的职责是不一样的loadClass方法与findClass方法分析:1.loadClass方法是ClassLoader类中最常用的方法之一，它负责加载指定的类。它的主要特点是:1.1 它是一个public方法，可以被外部类调用。

Hotspot Debugger(HSDB):JDK原生自带以Windows系统为例，jdk8的环境，在jdk的lib目录下，启动之前，你需要确保你进入的lib目录和你当前的JAVA_HOME配置的JDK是相同的，否则可能会出现无法加载libarary的异常，进而无法使用HSDB,命令如下调节字体大小的方法，添加环境变量JAVA_TOOL_OPTIONS这里需要用attach到一个java进程，利用jps可以查看到相关指令将进程号输入进去，我这里换了一个程序，进程号不同。

Java的每个类，在JVM中都有一个对应的Klass类实例与之对应，存储类的元信息如:常量池、属性信息、方法信息…从继承关系上也能看出来，类的元信息是存储在元空间的。总结:非数组:InstanceKlass -> 普通的类在JVM中对应的C++类 方法区InstanceMirrorKlass -> 对应的是Class对象 镜像类 堆区数组:基本类型数组引用类型数组: ObjArrayKlass为什么还要有镜像类？是为了安全，由JVM控制可以将哪些参数返回给用户。

作为一名Javer，应该不少人都想编译一下OpenJDK然后在项目中用上它，自己还可以在OpenJDK中加入自己的东西，而不用受限于Oracle官网上的JDK,市面上还有很多技术也是运行在JVM之上的，这更加说明了研究JVM的重要性，比如Kotlin、Groovy、JRuby、Jython、Scala等等，接下来让我们一起探索JVM吧~

前天线上服务器突然内存和CPU都爆掉了，两者都处于一种高负载的状态，而且还是周末的情况下，起初运维同事怀疑是用户数量暴增，但是数据面板上并没有出现很大的暴增现象，之前的服务器4G的内存都跑不满后面升到8G还是不够,于是我用jps查看了下堆状态，发现老年代的空间占用率99%(大小为5个G),新生代2个多G,于是我怀疑是某个业务一直在创建大量的对象，当然这只能是初步怀疑，接着我又去分析CPU，主要使用了以下命令。

前言:OOM常见的错误类型有如下:1.Java Heap Space(堆)2.GC overhead limit exceeded(GC回收的开销小于回报,下面进行详细分析)3.PermGen space(永久代)4.Metaspace(元空间)该异常的描述是:GC在经过一番运算之后,发现回收的内存很小,不能满足新对象所需的内存,新对象所需的内存空间.默认情况下,如果GC花费的时间超过98%,并且GC回收的内存少于2%,就会发生该错误.实际上,我们知道JVM内存不够了,可以通过GC回收垃圾对