jdkJVM调优

加载java.lang.ClassLoader，扩展类和应用加载器

加载JRE所需要的基本组件

没有继承java.lang.ClassLoader

sun.misc.Launcher.ExtClassLoader

继承java.lang.ClassLoader

sun.misc.Launcher.AppClassLoader

java.lang.ClassLoader#getSystemClassLoader
默认返回的AppClassLoader

继承java.lang.ClassLoader

一个类加载器必须重写findClass方法，但是loadClass 里面其实里面就实现了双亲委派， //想打破双亲委派就需要重写 loadClass

实现java.lang.ClassLoader类，然后覆盖他的findClass(String name)方法即可。findClass根据 指定的类的名字，返回对应的Class对象的引用

private String path;
指定这个类加载器加载类的路径

为什么可以使用clazz.getClassLoader()获取到类加载器，因为类加载 器的作用是加载类而不是对象，
想获取对象的话还需要类对象newInstance方法才可以获取实例的对象

实现沙箱安全，核心类不会被破坏，用户自定义的类加载器不能加载应该由父类加载器加载的可靠类，从而防止恶意代码的加载
java.lang.Object总是会被启动类加载器加载，不会被其他加载

避免重复加载，各司其职

loadClass

但是线程上下文可以看到，打破双亲委派

给定二进制名字，生成类定义的数据，将给定的二进制名字转换为路径，文件读取字节码内容

findLoadedClass(String)

findClass(String)用户想要自定义的话必须自己实现

获取系统类加载器就是在初始化的时候设置的应用类加载器

通过线程上下文类加载器获取应用类加载器

JDBC加载驱动机制
主动使用forName注册

不使用forName注册
直接使用驱动管理器获取连接

ServiceLoader的源码

老年代空间分配担保机制

大于限制的值直接进入老年代不会尝试在年轻代分配

到达年龄限制的会进入老年代

 新生代gc过后存活对象过多无法放入Survivor区域

动态年龄判断

为什么：减轻GC压力

逃逸分析

标量替换

Eden专属于线程的部分

内存分配方式

分配内存

1. 使用句柄

2. 直接指向Heap里面的对象（Hotspot使用的）（使用压缩算法的效率更高）

使用句柄访问

直接指针访问

原生类型

引用类型

字面量：字符串常量池，在堆

符号引用

大量的反向代理会创建大量的代理类占用永久代

方法区里的虚方法表vtable

方法区里的接口方法表itable

上面的两个表在虚拟机启动的时候，按照一定的规则去子类找是否有对应的实现，有的话先使用子类的

两个字节00 00 == > 次版本号0

后两个字节 00 34 ==》16*3+4 = 52  ==》jdk8.0
低版本依次减1，6就是50

字面量：声明为final的常量值

符号引用：类和接口的全局限定名，
字段的名称和描述符，
方法的名称和描述符

每一个元素的第一个数据都是一个u1类型，该字节是标志位，占据1个字节。
JVM在解析常量池的时候，会根据u1类型获取元素是上面的具体的类型（
是字符串还是常量普通类型数据，
还是类型的索引还是字符串常量的索引
还是方法的索引，还是字段的索引，还是接口方法的索引还是；）

access_flags  方法  访问标记

name_index  方法名索引--》常量池里面

descriptor_index   描述符   也就是参数以及返回值的索引 --》 常量池里面

属性个数

属性表结构

CPU中用于运行用户代码的时间与CPU总消耗时间的比值

初始标记

并发标记（耗时但是用户并行）

重新标记

并发清理（耗时但是用户并行）

并发重置

STW减少，适合内存大的效果显著，也就是适合对停顿时间敏感的程序，而且CPU充足

获取最短回收停顿时间，（提高用户体验）

浮动垃圾

CPU敏感

空间碎片

并发失败

启用。并发GC线程数。

 Full GC 之后压缩以及多少次之后压缩

老年代默认到达92就会Full GC，就是为了避免并发失败，系统中大对象多的话需要设置小，可以设置自动调整

-XX:+CMSScavengeBeforeRemark：在CMS GC前启动一次minor gc，目的在于减少老年代对年轻代的引 用，降低CMS GC的标记阶段时的开销，一般CMS的GC耗时 80%都在标记阶段

初始标记和重新标记都可以设置线程数

失效触发full GC

初始标记STW 

并发标记（耗时，要追踪所有的存活对象）

最终标记STW

筛选回收STW

young

mixed 

full

-XX:ParallelGCThreads:指定GC工作的线程数量

-XX:G1HeapRegionSize:指定分区大小(1MB~32MB，且必须是2的N次幂)，默认将整堆划分为2048个分区

-XX:MaxGCPauseMillis:目标暂停时间(默认200ms)

-XX:TargetSurvivorRatio:Survivor区的填充容量(默认50%)，Survivor区域里的一批对象(年龄1+年龄2+年龄n的多个 年龄对象)总和超过了Survivor区域的50%，此时就会把年龄n(含)以上的对象都放入老年代

-XX:InitiatingHeapOccupancyPercent

-XX:G1MixedGCLiveThresholdPercent(默认85%) 

-XX:G1MixedGCCountTarget

-XX:G1HeapWastePercent

垃圾回收时间长

内存对象较多，可以有效减少回收时间

G1的思路就是边处理业务变收集垃圾，不会一次性清理，所以也会有STAB

大、 中、 小三类容量：

小型Region（Small Region） ： 容量固定为2MB， 用于放置小于256KB的小对象。

中型Region（Medium Region） ： 容量固定为32MB， 用于放置大于等于256KB但小于4MB的对象。

大型Region（Large Region） ： 容量不固定， 可以动态变化， 但必须为2MB的整数倍， 用于放置4MB或以上的大对象。 每个大型Region中只会存放一个大对象，

每个CPU对应有一块内存，且这块内存在主板上离这个CPU是最近的，每个CPU优先访问这块内存，那效率自然就提高了：

ZGC是能自动感知NUMA架构并充分利用NUMA架构特性的。

以前的垃圾回收器的GC信息都保存在对象头中，而ZGC的GC信息保存在对象地址指针中。
不读取对象，只需要读取内存指针，就可以知道是不是需要回收

每个对象有一个64位指针，低42位寻址，剩下的18不用，最后4位做标记

对象指针必须是64位，那么ZGC就无法支持32位操作系统，同样的也就无法支持压缩指针了（CompressedOops，压缩指针也是32位）。

1位：Finalizable标识，此位与并发引用处理有关，它表示这个对象只能通过finalizer才能访问；

1位：Remapped标识，设置此位的值后，对象未指向需要GC的Region集合

1位：Marked1标识；

1位：Marked0标识，和上面的Marked1都是标记对象用于辅助GC；

颜色指针的三大优势：

在标记和移动对象的阶段，每次「从堆里对象的引用类型中读取一个指针」的时候，都需要加上一个Load Barriers。

并发标记

并发预备重分配

并发重分配

并发重映射

三个STW阶段

浮动垃圾。ZGC的停顿时间是在10ms以下，但是ZGC的执行时间还是远远大于这个时间的。假如ZGC
全过程需要执行10分钟，在这个期间由于对象分配速率很高，将创建大量的新对象，这些对象很难进入当次GC，所以只
能在下次GC的时候进行回收，这些只能等到下次GC才能回收的对象就是浮动垃圾。

ZGC没有分代概念，每次都需要进行全堆扫描，导致一些“朝生夕死”的对象没能及时的被回收。

由于可以并行清除，所以在扫描的时候gcroot可能还在栈里面，扫描之后弹出，这个时候就是多标记黑色，变成浮动垃圾，等待下次GC就好

一开始A引用B，B引用CD。扫描完A之后是黑色，不会再扫描，扫描B到C但是没有扫描D的时候，此时A是黑色，B是灰色，C是黑色，D是白色。由于是并发标记，所以此时用户线程可以将B对D的引用去掉让A指向D，由于A不会再被扫描，所以此时D其实还是白色的，不处理最后会被当垃圾回收

增量更新update

原始快照SATB

写的时候是异步写到集合里面的

读屏障是直接针对第一步：D d = a.b.d，当读取成员变量时，一律记录下来

写屏障+增量更新：也就是在写操作后将新的引用放到一个集合，重新标记的时候重新扫描这个黑色的节点

写屏障+原始快照SATB：也就是写操作前将老的引用放到集合里面，并发标记之后直接变为黑色，下次GC再说

读屏障：在读取一个对象的时候就记录在集合里面，说白了还是类似于写屏障的写操作后

SATB相对于增量更新效率高，不需要在重新标记阶段再次深度扫描被删除引用的对象，CMS对增量引用的根对象会做深度扫描，CMS只有一个老年代扫描代价会小一些。

多级缓存的时候会使用本地缓存，不回收一直往里面放，堆积老年代。出问题

这种情况完全可以考虑采用一些成熟的JVM级缓存框架来解决，比如ehcache等自带一些LRU数据淘汰算法的框架来作为JVM级的缓存。

JDK8默认的垃圾回收器是-XX:+UseParallelGC(年轻代)和-XX:+UseParallelOldGC(老年代)，如果内存较大(超过4个G，只是经验 值)，系统对停顿时间比较敏感，我们可以使用ParNew+CMS(-XX:+UseParNewGC -XX:+UseConcMarkSweepGC)

可以适当将年龄阈值变小，留出来更多的空间给Survivor区域。长久使用的对象直接进入老年代

这些对象一般就是你系统初始 化分配的缓存对象，比如大的缓存List，Map之类的对象。

设置合理的大小让对象直接进入老年代

‐Xms3072M ‐Xmx3072M ‐Xmn2048M ‐Xss1M ‐XX:MetaspaceSize=256M ‐XX:MaxMetaspaceSize=256M ‐XX:SurvivorRatio=8
‐XX:MaxTenuringThreshold=5 ‐XX:PretenureSizeThreshold=1M ‐XX:+UseParNewGC ‐XX:+UseConcMarkSweepGC
‐XX:CMSInitiatingOccupancyFraction=92 ‐XX:+UseCMSCompactAtFullCollection ‐XX:CMSFullGCsBeforeCompaction=0

年轻代变大，CMS老年代可使用的百分比变大，

-Xms1536M -Xmx1536M -Xmn1024M -Xss256K -XX:SurvivorRatio=6 -XX:MetaspaceSize=256M -XX:MaxMetaspaceSize=256M
-XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=92 -XX:+UseCMSInitiatingOccupancyOnly

，full gc的次数比minor gc的次数还多了

jmap命令大概看下是什么对象

jmap -histo pid

确定对象被频繁创建的位置

jstack或jvisualvm来定位cpu使用较高的代码

类和接口的全限定名

字段的名称和描述符

方法的名称和描述符

String s="zhuge"; // s指向常量池中的引用

创建的对象只会在常量池里面

 JVM会先去常量池中通过 equals(key) 方法，判断是否有相同的对象 如果有，则直接返回该对象在常量池中的引用； 如果没有，则会在常量池中创建一个新对象，再返回引用。

会保证字符串常量池和堆中都有这个对象，没有就创建，最后返回堆内存中的对象引用。

先去字符串常量池检查是否存在字面量，不存在的话就先在常量池创建一个，之后去内存中创建一个字符串对象。存在的话直接去堆内存 中创建一个字符串对象"deltaqin"

最后，将内存中的引用返回。

String s1=new String("zhuge");
String s2=s1.intern();
System.out.println(s1==s2); //false

String中的intern方法是一个 native 的方法， 当调用 intern方法时， 如果池已经包含一个等于此String对象的字符串 （用equals(oject)方法确定），则返回池中的字符串。否则，将intern返回的引用指向当前字符串 s1(jdk1.6版本需要将 s1 复制到字符串常量池里)。

当一个字 符串由多个字符串常量连接而成时，它自己肯定也是字符串常量

JVM对于字符串常量的"+"号连接，将在程序编译期，JVM就将常量字符串的"+"连接优化为连接后的值

有new就无法在编译期执行，所以会在运行时创建一个新的对象

由于在字符串的"+"连接中，有字符串引用存在，而引用的值在程序编译期是无法确定的，无法被编译器优化。
只有在程序运行期来动态分配并将连接后的新地址赋给b。所以上面程序的结果也就为 false。

编译时候的字节码会转换为StringBuilder的append方式

由于在字符串的"+"连接中，有字符串引用存在，而引用的值在程序编译期是无法确定的，无法被编译器优化。
只有在程序运行期来动态分配并将连接后的新地址赋给b。所以上面程序的结果也就为 false。

对于final修饰的变量，它在编译时被解析为常量值的一个本地拷贝存储到自己的常量池中或嵌入到它的字节码流中。所以此时的"a" + bb和"a" + "b"效果是一样的。

JVM对于字符串引用bb，它的值在编译期无法确定，只有在程序运行期调用方法后，将方法的返回值和"a"来动态 连接并分配地址为b，故上面 程序的结果为false。

运算

多态

主流的Java虚拟机里面没有选用引用计数算法来管理内存，其中最主要的原因是它很难解决对象之间相互引用的问题

可作为GC Roots的对象

客户端

客户端

多核

多核+大吞吐量

多核+大吞吐量

流程

缺点

多核+低停顿=响应速度优先

阶段

核心思想：空间换时间

优点

面向服务端，响应速度优先

ZGC是一种并发的、不分代的、基于Region且支持NUMA的压缩收集器

初始标记，再标记，初始转移

Eden内存不足

为TLAB分配内存

年老代（Tenured）被写满；

YGC晋升总内存大于剩余内存

持久代（Perm）被写满；

System.gc()被显示调用；

上一次GC之后Heap的各域分配策略动态变化；

老年代空间担保机制

CMS收集器导致碎片化严重，导致老年代没有足够的空间用于担保的。进而导致CMSgc失败，系统使用了serial old收集器。
然后这个收集器是使用标记整理的算法，耗时长。

CMS六个阶段中重新标记的时间长

参数：-XX:+HeapDumpOnOutOfMemoryError

栈容量由-Xss 参数设定

通过-XX:PermSize和-XX:MaxPermSize限制方法区大小

通过-XX:MaxDirectMemorySize指定

查找并加载类的二进制数据；

验证

准备

解析

为类的静态变量赋予正确的初始值

为什么需要

怎么实现

为什么打破

怎么打破

内存分配方式

线程安全解决

线程逃逸

自身运行时数据（Mark Word）

类型指针(一般是4个字节)

对象真正存储的有效信息

并不是必然存在的，也没有特别的含义，仅仅骑着占位符的作用

jstack导出栈信息

-Xms

-Xmx

-XX:+HeapDumpOnOutOfMemorryError  -XX:HeapDumpPath=/data/log/

压缩之后拉取下来放到MAT分析内存泄漏

查看stack信息找到调用栈的代码

jmap -heap 查询堆区域的统计信息

jmap -histo 查看大对象

jamp -dump导出内存镜像

1000表示采样间隔(ms)，S0C/S1C、S0U/S1U、EC/EU、OC/OU、MC/MU分别代表两个Survivor区、Eden区、老年代、元数据区的容量和使用量

使用top命令，查看占用cpu的进程的pid