1.Java类的加载机制
（1）JDK中提供了三个ClassLoader，根据层级从高到低为：
- 1.Bootstrap ClassLoader，主要加载JVM自身工作需要的类。
- 2.Extension ClassLoader，主要加载%JAVA_HOME%\lib\ext目录下的库类。
- 3.Application ClassLoader，主要加载Classpath指定的库类，一般情况下这是程序中的默认类加载器，也是ClassLoader.getSystemClassLoader() 的返回值。（这里的Classpath默认指的是环境变量中配置的Classpath，但是可以在执行Java命令的时候使用-cp 参数来修改当前程序使用的Classpath）
（2）双亲委派模型
JVM加载类的实现方式，称为双亲委托模型：
如果一个类加载器收到了类加载的请求，他首先不会自己去尝试加载这个类，而是把这个请求委托给自己的父加载器，每一层的类加载器都是如此，因此所有的类加载请求最终都应该传送到顶层的Bootstrap ClassLoader中，只有当父加载器反馈自己无法完成加载请求时，子加载器才会尝试自己加载。双亲委托模型的重要用途是为了解决类载入过程中的安全性问题，避免重复加载类以及实现了共享功能：父类加载了该类，子类可以直接共享。
假设有一个开发者自己编写了一个名为Java.lang.Object的类，想借此欺骗JVM。现在他要使用自定义ClassLoader来加载自己编写的java.lang.Object类。然而幸运的是，双亲委托模型不会让他成功。因为JVM会优先在Bootstrap ClassLoader的路径下找到java.lang.Object类，并载入它
注意：JVM会通过两个方式来判断类是否相同，一是类名，二是类加载器。
（3）类加载过程
类加载分为三个步骤：加载，连接，初始化；
a.加载
根据一个类的全限定名(如cn.edu.hdu.test.HelloWorld.class)来读取此类的二进制字节流到JVM内部;将字节流所代表的静态存储结构转换为方法区的运行时数据结构（hotspot选择将Class对象存储在方法区中，Java虚拟机规范并没有明确要求一定要存储在方法区或堆区中）最终转换为一个与目标类型对应的java.lang.Class对象，作为方法区这个类的各种数据的访问入口
b.连接
验证
为了保证Class文件的字节流中包含的信息符合当前虚拟机的要求，验证阶段主要包括四个检验过程：文件格式验证、元数据验证、字节码验证和符号引用验证;
准备
为类中的所有静态变量分配内存空间，并为其设置一个初始值（由于还没有产生对象，实例变量将不再此操作范围内）；
解析
将常量池中所有的符号引用转为直接引用（得到类或者字段、方法在内存中的指针或者偏移量，以便直接调用该方法）。这个阶段可以在初始化之后再执行。
c.初始化
在连接的准备阶段，类变量已赋过一次系统要求的初始值，而在初始化阶段，则是根据程序员自己写的逻辑去初始化类变量和其他资源，执行构造方法
2.JVM模型
JVM总体上是由类装载子系统（ClassLoader）、运行时数据区、执行引擎、垃圾收集这四个部分组成。其中JVM运行时数据区，也就是JVM的内存部分则是由方法区（Method Area）、JAVA堆（Java Heap）、虚拟机栈（JVM Stack）、程序计数器、本地方法栈（Native Method Stack）这5部分组成。
a.类装载子系统
Class Loader类加载器负责加载.class文件，class文件在文件开头有特定的文件标示，并>且ClassLoader负责class文件的加载等，至于它是否可以运行，则由Execution Engine决定。
b.运行时数据区
栈管运行，堆管存储。JVM调优主要是优化Java堆和方法区。
- 方法区(Method Area)
方法区是各线程共享的内存区域，它用于存储已被JVM加载的类信息、常量、静态变量、运行时常量池等数据。- Java堆(Java Heap)
Java堆是各线程共享的内存区域，在JVM启动时创建，这块区域是JVM中最大的， 用于存储应用的对象和数组，也是GC主要的回收区，一个 JVM 实例只存在一个堆内存，堆内存的大小是可以调节的。类加载器读取了类文件后，需要把类、方法、常变量放到堆内存中，以方便执行器执行，堆内存分为三部分：新生代、老年代、永久代。
说明：
Jdk1.6及之前：常量池分配在永久代 。
Jdk1.7：有，但已经逐步“去永久代” 。
Jdk1.8及之后：无永久代，改用元空间代替(java.lang.OutOfMemoryError: PermGen space,这种错误将不会出现在JDK1.8中)。元空间默认大小：20.75M- Java栈(JVM Stack)
1) 栈是什么
Java栈是线程私有的，是在线程创建时创建，它的生命期是跟随线程的生命期，线程结束栈内存也就释放，对于栈来说不存在垃圾回收问题，只要线程一结束该栈就Over，生命周期和线程一致。基本类型的变量和对象的引用变量都是在函数的栈内存中分配。
2) 栈存储什么
每个方法执行的时候都会创建一个栈帧，栈帧中主要存储3类数据：
局部变量表：输入参数和输出参数以及方法内的变量；
栈操作：记录出栈和入栈的操作；
栈帧数据：包括类文件、方法等等。
动态链接：
返回地址：回调的方法以及返回的值
3) 栈运行原理
栈中的数据都是以栈帧的格式存在，栈帧是一个内存区块，是一个数据集，是一个有关方法和运行期数据的数据集。每一个方法被调用直至执行完成的过程，就对应着一个栈帧在栈中从入栈到出栈的过程。
JVM栈的深度：18006
默认大小：1M，最小设置不能小于160k
每个栈帧的大小：110241024/18006
java中一个方法占用一个栈帧的区域
局部变量表：用来存放方法中的局部变量或对象的引用，主要是做通过从操作数栈中取出变量被赋予的值，存在局部变量表中
操作数栈：就是javap -c反编译后得到的字节码文件中的具体变量的操作步骤（通过压栈，从栈中取做操作，然后赋值给局部变量，到局部变量）存放临时的操作数
返回地址：即方法执行完成后，需要返回调用他的方法的具体位置，然后执行其他操作，没有的话，就是返回值
动态链接：栈帧中保存了一个引用，相当于C语言中的指针，指向该方法在运行时常量池中的位置。通过运行时常量池的符号引用（指向堆），完成将符号引用转化为直接引用。
补充：方法区存放的静态变量之类的实则是指向堆中的应用，真正的还在堆。- 本地方法栈(Native Method Stack)
本地方法栈和JVM栈发挥的作用非常相似，也是线程私有的，区别是JVM栈为JVM执行Java方法（也就是字节码）服务，而本地方法栈为JVM使用到的Native方法服务。它的具体做法是在本地方法栈中登记native方法，在执行引擎执行时加载Native Liberies.有的虚拟机（比如Sun Hotpot）直接把两者合二为一。- 程序计数器(Program Counter Register)
程序计数器是一块非常小的内存空间，几乎可以忽略不计，每个线程都有一个程序计算器，是线程私有的，可以看作是当前线程所执行的字节码的行号指示器，指向方法区中的方法字节码（下一个将要执行的指令代码），由执行引擎读取下一条指令。- 运行时常量池
运行时常量池是方法区的一部分，用于存放编译器生成的各种字面量和符号引用，这部分内容将在类加载后存放到方法区的运行时常量池中。相较于Class文件常量池，运行时常量池更具动态性，在运行期间也可以将新的变量放入常量池中，而不是一定要在编译时确定的常量才能放入。最主要的运用便是String类的intern()方法。intern() 方法返回字符串对象的规范化表示形式。
它遵循以下规则：对于任意两个字符串 s 和 t，当且仅当 s.equals(t) 为 true 时，s.intern() == t.intern() 才为 true。
c.执行引擎(Execution Engine)
执行引擎执行包在装载类的方法中的指令，也就是方法。执行引擎以指令为单位读取Java字节码。它就像一个CPU一样，一条一条地执行机器指令。每个字节码指令都由一个1字节的操作码和附加的操作数组成。执行引擎取得一个操作码，然后根据操作数来执行任务，完成后就继续执行下一条操作码。
不过Java字节码是用一种人类可以读懂的语言编写的，而不是用机器可以直接执行的语言。因此，执行引擎必须把字节码转换成可以直接被JVM执行的语言。字节码可以通过以下两种方式转换成合适的语言：
解释器： 一条一条地读取，解释并执行字节码执行，所以它可以很快地解释字节码，但是执行起来会比较慢。这是解释执行语言的一个缺点。
即时编译器：用来弥补解释器的缺点，执行引擎首先按照解释执行的方式来执行，然后在合适的时候，即时编译器把整段字节码编译成本地代码。然后，执行引擎就没有必要再去解释执行方法了，它可以直接通过本地代码去执行。执行本地代码比一条一条进行解释执行的速度快很多，编译后的代码可以执行的很快，因为本地代码是保存在缓存里的。
d.垃圾收集(Garbage Collection, GC)- 什么是垃圾收集
垃圾收集即垃圾回收，简单的说垃圾回收就是回收内存中不再使用的对象。所谓使用中的对象（已引用对象），指的是程序中有指针指向的对象；而未使用中的对象（未引用对象），则没有被任何指针给指向，因此占用的内存也可以被回收掉。
垃圾回收的基本步骤分两步：
查找内存中不再使用的对象（GC判断策略）
释放这些对象占用的内存（GC收集算法）- GC判断策略
1) 引用计数算法
引用计数算法是给对象添加一个引用计数器，每当有一个引用它时，计数器值就加1；当引用失效时，计数器值就减1；任何时刻计数器都为0的对象就是不可能再被使用的对象。缺点：很难解决对象之间相互循环引用的问题。
2) 根搜索算法
根搜索算法的基本思路就是通过一系列名为“GC Roots”的对象作为起始点，从这些节点开始向下搜索，搜索所走过的路径称为引用链（Reference Chain），当一个对象到GC Roots没有任何引用链相连（也就是说从GC Roots到这个对象不可达）时，则证明此对象是不可用的。
在Java语言里，可作为GC Roots的对象包括以下几种：
虚拟机栈（栈帧中的本地变量表）中引用的对象；
方法区中类静态属性引用的对象；
方法区中常量应用的对象；
本地方法栈中JNI（Native方法）引用的对象。
在根搜索算法中不可达的对象，也并非是“非死不可”的，因为要真正宣告一个对象死亡，至少要经历两次标记过程：第一次是标记没有与GC Roots相连接的引用链；第二次是GC对在F-Queue执行队列中的对象进行的小规模标记(对象需要覆盖finalize()方法且没被调用过)。
GC收集算法
- 标记-清除算法（Mark-Sweep）
标记-清楚算法采用从根集合（GC Roots）进行扫描，首先标记出所有需要回收的对象（根搜索算法），标记完成后统一回收掉所有被标记的对象。
该算法有两个问题：
效率问题：标记和清除过程的效率都不高；
空间问题：标记清除后会产生大量不连续的内存碎片, 空间碎片太多可能会导致在运行过程中需要分配较大对象时无法找到足够的连续内存而不得不提前触发另一次垃圾收集。- 复制算法（Copying）
复制算法是将可用内存按容量划分为大小相等的两块, 每次只用其中一块, 当这一块的内存用完, 就将还存活的对象复制到另外一块上面, 然后把已使用过的内存空间一次清理掉。- 标记-整理算法（Mark-Compact）
标记整理算法的标记过程与标记清除算法相同, 但后续步骤不再对可回收对象直接清理, 而是让所有存活的对象都向一端移动,然后清理掉端边界以外的内存。- 分代收集算法（Generational Collection）
分代收集算法是目前大部分JVM的垃圾收集器采用的算法。它的核心思想是根据对象存活的生命周期将内存划分为若干个不同的区域。一般情况下将堆区划分为老年代（Tenured Generation）和新生代（Young Generation），在堆区之外还有一个代就是永久代（Permanet Generation）。老年代的特点是每次垃圾收集时只有少量对象需要被回收，而新生代的特点是每次垃圾回收时都有大量的对象需要被回收，那么就可以根据不同代的特点采取最适合的收集算法。- 新生代（Young Generation）的回收算法（以复制算法为主）
1.所有新生成的对象首先都是放在年轻代的。年轻代的目标就是尽可能快速的收集掉那些生命周期短的对象。
2.新生代内存按照8:1:1的比例分为一个eden区和两个survivor(survivor0,survivor1)区。一个Eden区，两个 Survivor区(一般而言)。大部分对象在Eden区中生成。回收时先将eden区存活对象复制到一个survivor0区，然后清空eden区，当这个survivor0区也存放满了时，则将eden区和survivor0区存活对象复制到另一个survivor1区，然后清空eden和这个survivor0区，此时survivor0区是空的，然后将survivor0区和survivor1区交换，即保持survivor1区为空， 如此往复。
3.当survivor1区不足以存放 eden和survivor0的存活对象时，就将存活对象直接存放到老年代。若是老年代也满了就会触发一次Full GC(Major GC)，也就是新生代、老年代都进行回收。
4.新生代发生的GC也叫做Minor GC，MinorGC发生频率比较高(不一定等Eden区满了才触发)。- 老年代（Tenured Generation）的回收算法（以标记-清除、标记-整理为主）
在年轻代中经历了N次垃圾回收后仍然存活的对象，就会被放到老年代中。因此，可以认为老年代中存放的都是一些生命周期较长的对象。
内存比新生代也大很多(大概比例是1:2)，当老年代内存满时触发Major GC即Full GC，Full GC发生频率比较低，老年代对象存活时间比较长，存活率标记高。- 永久代（Permanet Generation）的回收算法
用于存放静态文件，如Java类、方法等。永久代对垃圾回收没有显著影响，但是有些应用可能动态生成或者调用一些class，例如Hibernate 等，在这种时候需要设置一个比较大的永久代空间来存放这些运行过程中新增的类。永久代也称方法区。方法区主要回收的内容有：废弃常量和无用的类。对于废弃常量也可通过根搜索算法来判断，但是对于无用的类则需要同时满足下面3个条件：
1.该类所有的实例都已经被回收，也就是Java堆中不存在该类的任何实例；
2.加载该类的ClassLoader已经被回收；
3.该类对应的java.lang.Class对象没有在任何地方被引用，无法在任何地方通过反射访问该类的方法。
垃圾收集器
1) Serial收集器（复制算法)
新生代单线程收集器，标记和清理都是单线程，优点是简单高效。是client级别默认的GC方式，可以通过-XX:+UseSerialGC来强制指定。
2) Serial Old收集器(标记-整理算法)
老年代单线程收集器，Serial收集器的老年代版本。
3) ParNew收集器(停止-复制算法)
新生代多线程收集器，其实就是Serial收集器的多线程版本,在多核CPU环境下有着比Serial更好的表现。
4) Parallel Scavenge收集器(停止-复制算法)
新生代并行的多线程收集器，追求高吞吐量，高效利用CPU。吞吐量一般为99%， 吞吐量= 用户线程时间/(用户线程时间+GC线程时间)。适合后台应用等对交互相应要求不高的场景。是server级别默认采用的GC方式，可用-XX:+UseParallelGC来强制指定，用-XX:ParallelGCThreads=4来指定线程数。
5) Parallel Old收集器(停止-复制算法)
老年代并行的多线程收集器，Parallel Scavenge收集器的老年代版本，并行收集器，吞吐量优先。
6) CMS(Concurrent Mark Sweep)收集器（标记-清除算法）
CMS收集器是一种以获取最短回收停顿时间为目标的收集器，CMS收集器是基于“标记–清除”(Mark-Sweep)算法实现的，整个过程分为四个步骤：
1.初始标记： 标记GC Roots能直接关联到的对象，速度很快；
2.并发标记： 进行GC Roots Tracing的过程；
3.重新标记： 修正并发标记期间因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间一般会比初始标记阶段稍长一些，但比并发标记时间短；
4.并发清除： 整个过程中耗时最长的并发标记和并发清除过程收集器线程都可以与用户线程一起工作，所以，从总体上来说，CMS收集器的内存回收过程是与用户线程一起并发执行的。
优点：并发收集、低停顿
缺点：对CPU资源非常敏感、无法处理浮动垃圾、产生大量空间碎片。
7) G1(Garbage First)收集器（标记-整理算法）
G1是一款面向服务端应用的垃圾收集器，是基于“标记-整理”算法实现的，与其他GC收集器相比，G1具备如下特点：
并行与并发
分代收集
空间整合
可预测性的停顿
G1运作步骤：
1.初始标记(stop the world事件，CPU停顿只处理垃圾)
2.并发标记(与用户线程并发执行)
3.最终标记(stop the world事件，CPU停顿处理垃圾)
4.筛选回收(stop the world事件，根据用户期望的GC停顿时间回收)
垃圾回收结构图：
3.JVM调优
什么情况下触发垃圾回收
由于对象进行了分代处理，因此垃圾回收区域、时间也不一样。GC有两种类型：Scavenge GC和Full GC。
Scavenge GC
一般情况下，当新对象生成，并且在Eden申请空间失败时，就会触发Scavenge GC，对Eden区域进行GC，清除非存活对象，并且把尚且存活的对象移动到Survivor区。然后整理Survivor的两个区。这种方式的GC是对年轻代的Eden区进行，不会影响到年老代。因为大部分对象都是从Eden区开始的，同时Eden区不会分配的很大，所以Eden区的GC会频繁进行。因而，一般在这里需要使用速度快、效率高的算法，使Eden去能尽快空闲出来。
Full GC
对整个堆进行整理，包括Young、Tenured和Perm。Full GC因为需要对整个对进行回收，所以比Scavenge GC要慢，因此应该尽可能减少Full GC的次数。在对JVM调优的过程中，很大一部分工作就是对于FullGC的调节。有如下原因可能导致Full GC：
年老代（Tenured）被写满
持久代（Perm）被写满
System.gc()被显示调用
上一次GC之后Heap的各域分配策略动态变化
优化策略一：选择合适的垃圾收集算法
串行收集器
用单线程处理所有垃圾回收工作，因为无需多线程交互，所以效率比较高。但是，也无法使用多处理器的优势，所以此收集器适合单处理器机器。当然，此收集器也可以用在小数据量（100M左右）情况下的多处理器机器上。可以使用-XX:+UseSerialGC打开。
并行收集器
对年轻代进行并行垃圾回收，因此可以减少垃圾回收时间。一般在多线程多处理器机器上使用。使用-XX:+UseParallelGC.打开。并行收集器在J2SE5.0更新上引入，在Java SE6.0中进行了增强–可以对年老代进行并行收集。如果年老代不使用并发收集的话，默认是使用单线程进行垃圾回收，因此会制约扩展能力。
使用-XX:+UseParallelOldGC打开。
使用-XX:ParallelGCThreads=< N>设置并行垃圾回收的线程数。此值可以设置与机器处理器数量相等。
此收集器可以进行如下配置：
最大垃圾回收暂停:指定垃圾回收时的最长暂停时间，通过-XX:MaxGCPauseMillis=< N>指定。< N>为毫秒.如果指定了此值的话，堆大小和垃圾回收相关参数会进行调整以达到指定值。设定此值可能会减少应用的吞吐量。
吞吐量:吞吐量为垃圾回收时间与非垃圾回收时间的比值，通过-XX:GCTimeRatio=< N>来设定，公式为1/（1+N）。例如，-XX:GCTimeRatio=19时，表示5%的时间用于垃圾回收。默认情况为99，即1%的时间用于垃圾回收。
并发收集器
可以保证大部分工作都并发进行（应用不停止），垃圾回收只暂停很少的时间，此收集器适合对响应时间要求比较高的中、大规模应用。使用-XX:+UseConcMarkSweepGC打开。
并发收集器主要减少年老代的暂停时间，他在应用不停止的情况下使用独立的垃圾回收线程，跟踪可达对象。在每个年老代垃圾回收周期中，在收集初期并发收集器 会对整个应用进行简短的暂停，在收集中还会再暂停一次。第二次暂停会比第一次稍长，在此过程中多个线程同时进行垃圾回收工作。
并发收集器使用处理器换来短暂的停顿时间。在一个N个处理器的系统上，并发收集部分使用K/N个可用处理器进行回收，一般情况下1<=K<=N/4。
在只有一个处理器的主机上使用并发收集器，设置为incremental mode模式也可获得较短的停顿时间。
浮动垃圾：由于在应用运行的同时进行垃圾回收，所以有些垃圾可能在垃圾回收进行完成时产生，这样就造成了“Floating Garbage”，这些垃圾需要在下次垃圾回收周期时才能回收掉。所以，并发收集器一般需要20%的预留空间用于这些浮动垃圾。
Concurrent Mode Failure：并发收集器在应用运行时进行收集，所以需要保证堆在垃圾回收的这段时间有足够的空间供程序使用，否则，垃圾回收还未完成，堆空间先满了。这种情况下将会发生“并发模式失败”，此时整个应用将会暂停，进行垃圾回收。
启动并发收集器：因为并发收集在应用运行时进行收集，所以必须保证收集完成之前有足够的内存空间供程序使用，否则会出现“Concurrent Mode Failure”。通过设置-XX:CMSInitiatingOccupancyFraction=< N>指定还有多少剩余堆时开始执行并发收集
总结
串行处理器：
–适用情况：数据量比较小（100M左右）；单处理器下并且对响应时间无要求的应用。
–缺点：只能用于小型应用
并行处理器：
–适用情况：“对吞吐量有高要求”，多CPU、对应用响应时间无要求的中、大型应用。举例：后台处理、科学计算。
–缺点：垃圾收集过程中应用响应时间可能加长
并发处理器：
–适用情况：“对响应时间有高要求”，多CPU、对应用响应时间有较高要求的中、大型应用。举例：Web服务器/应用服务器、电信交换、集成开发环境。
加一些JVM常用的命令：1
2# 查看栈的默认大小
java -XX:+PrintFlagsFinal -version | grep ThreadStack
调优实操文章：
https://blog.csdn.net/J080624/article/details/85679252
https://blog.csdn.net/wd2014610/article/details/82182617
方式1：
在IDEA界面：help->Edit Custom VM Options
方式2：
打开 IDEA 安装目录，看到有一个 bin 目录，其中有两个 vmoptions 文件，需针对不同的JDK进行配置：
32 位：idea.exe.vmoptions
64 位：idea64.exe.vmoptions
引用：
https://www.toutiao.com/i6717906477710836236/?tt_from=weixin&utm_campaign=client_share&wxshare_count=1×tamp=1605000967&app=news_article&utm_source=weixin&utm_medium=toutiao_android&use_new_style=1&req_id=202011101736070100260790153A059AB9&group_id=6717906477710836236
https://www.toutiao.com/i6715302733953368588/?tt_from=weixin&utm_campaign=client_share&wxshare_count=1×tamp=1605000985&app=news_article&utm_source=weixin&utm_medium=toutiao_android&use_new_style=1&req_id=2020111017362501002607720708059D86&group_id=6715302733953368588
