先说点废话
咱们好多java开发者，代码编写了很多年，然而要么始终是在做CRUD的活儿，要么就是不停的学习各种框架怎么应用，对于java最最根底的JVM局部，除了在最开始学习java的时候有过一些隐约的印象。
晓得JVM是java编译后可能跨平台运行的根底，也晓得能够应用-Xms和-Xmx配置堆内存大小，然而对于什么是堆内存，jvm就只有堆内存吗？jvm外部各个区域的构造是怎么样的，为什么要这么设计？代码在jvm外部是怎么执行的，并没有一个清晰的概念。
对于一般开发者来说，如果始终是在编写业务代码的，仿佛不理解这些也并不影响，可能也确实没啥影响。
不过我想，但但凡对技术有点谋求的，还是须要去理解一下jvm的内部结构的。包含咱们去面试一些java岗位的时候，jvm都是必问的。如果面试的时候一家公司连jvm都不问，那基本上能够必定这家公司的java技术团队是挺拉跨的。
对于jvm的学习，其实和java源码、框架原理的学习有点相似。
很多时候咱们会有一种感觉，不往下深刻学习，也不影响把货色做进去。
然而真的如此吗？大家能够尝试一下深刻学习一门技术，而后再回过头去看看先前对该常识的利用，必定会有不一样的领会。
JDK、JRE与JVM
这是一张Java世界中比拟有名的图了，
位于最底层的，是各类操作系统，往上一层，就是咱们的JVM了，这里大家可能会有个疑难，JVM怎么还辨别Client和Server？
这其实是JVM的两种运行模式，Client模式启动速度较快，Server模式启动较慢；然而启动进入稳定期长期运行之后Server模式的程序运行速度比Client要快很多。这是因为Server模式启动的JVM采纳的是重量级的虚拟机，对程序采纳了更多的优化；而Client模式启动的JVM采纳的是轻量级的虚拟机。所以Server启动慢，但稳固后速度比Client远远要快。
要想查看以后jvm是以何种模式运行的，咱们的jvm默认都是以server模式运行的
mac@MACs-iMac-2 ~ java -versionjava version "11.0.10" 2021-01-19 LTSJava(TM) SE Runtime Environment 18.9 (build 11.0.10+8-LTS-162)Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11.0.10+8-LTS-162, mixed mode)JVM和其余java程序运行所需的根底类库，组成了JRE，即 Java Runtime Environment
JRE联合开发应用的工具包，则造成了整个JDK
JDK加上其余所有基于Java开发的各种类库、框架，就造成了咱们的Java生态
当然，这里只是从语言层面上比拟不那么谨严的这么一说，真正的Java生态，要简单的多。
根本堆栈构造
JVM在启动后，会将内存分为两大类，
一类是跟着线程存在而存在的内存空间，包含程序计数器、虚拟机、本地办法栈
一类是所有线程共享的区域，包含堆、办法区。
第一类空间，存储的是以后正在执行的线程的局部变量、办法参数，会随着线程的终止而开释
堆空间，存储new进去的对象是JVM中占用空间最大的一个区域，
办法区，存储的是类信息、常量、动态变量等等
而咱们对JVM的调优，次要就是设置各项存储空间的大小、比例，以及前面会讲到的各项GC参数
聊聊线程隔离区
其实对于jvm调优来说，线程隔离区不是重点，须要配置的参数也不多，不过因为内容不多，所以还是简略的来介绍一下。
线程隔离去所有的内存空间占用，都会随着线程的完结而开释
程序计数器
存储的是 以后线程所执行的字节码的行号指示器。字节码解释器通过线程的程序计数器的值，晓得以后执行到哪一行，下一步执行哪一步。不过不同于咱们的java代码，jvm层面的一行和java代码的一行往往不是一个概念，如下代码
package com.zhangln;/** * @author sherry * @date 2021年08月11日 8:00 下午 */public class HelloWorld { public static void main(String[] args) { int a = 1; int b = 2; System.out.println(a + b); }}当我把它编译后，再应用javap命令进行反编译
master ●✚ javap -c HelloWorld.classCompiled from "HelloWorld.java"public class com.zhangln.HelloWorld { public com.zhangln.HelloWorld(); Code: 0: aload_0 1: invokespecial #1 // Method java/lang/Object."<init>":()V 4: return public static void main(java.lang.String[]); Code: 0: iconst_1 1: istore_1 2: iconst_2 3: istore_2 4: getstatic #2 // Field java/lang/System.out:Ljava/io/PrintStream; 7: iload_1 8: iload_2 9: iadd 10: invokevirtual #3 // Method java/io/PrintStream.println:(I)V 13: return}这才是jvm层面上理论执行的内容
具体的每一行代表什么意思，咱们须要联合jvm指令手册来进行浏览，我这里就不赘述了。
每个线程都有本人的程序计数器，其理论记录的是正在执行的虚拟机字节码指令的地址。
如果正在执行的是本地（Native）办法，这个计数器值则应为空（Undefined）。此内存区域是惟一一个在《Java虚拟机标准》中没有规定任何OutOfMemoryError状况的区域。
- 为什么须要程序计数器呢？
咱们举一个单核多线程的例子就明确了，如果没有程序计数器，当CPU去执行其余线程的时候，当操作系统将CPU的执行权限再次给到了以后线程，程序是不晓得从哪里开始执行的，总不能从头开始执行吧。
本地办法栈
本地办法栈的作用和虚拟机栈是相似的，不同之处在于本地办法栈中的内存开销，服务的是native办法。个别都是c/c++编写的。
虚拟机栈
虚拟机栈，也能够称为线程栈，它的生命周期与线程雷同。存储的是各种局部变量、操作数等等。
不同的存储内存，存储在不同的栈帧中。
栈帧：在线程栈外部，每执行一个办法，则开拓一个内存空间，遵循FILO准则。局部变量就是放在一个个办法栈帧中的。
栈帧用于存储局部变量表、操作数栈、动静连贯、办法进口等信息
每一个办法被调用直至执行结束的过程，就对应着一个栈帧在虚拟机栈中从入栈到出栈的过程
局部变量表寄存了编译器可知的各种Java根本类型和对象援用类型
如果线程申请的栈深度大于虚拟机所容许的深度，将派出StackOverfowError
如果虚拟机栈容量能够动静扩大，当栈扩大时无奈申请到足够的内容就会抛出OOM
每个线程栈的大小，通过-Xss设置，如-Xss128k。JDK5当前默认1M，之前是256k。
雷同物理内存下，缩小这个值，可能生成更多的线程，不过操作系统还是会限度一个过程可能产生的线程数的，也不是可能有限生成的
办法区
办法区：在jdk8之前，叫永恒代，jdk8开始，改名叫元空间（不过他们俩并不是等价的）。存储的内容包含 常量、动态变量、类信息
运行时常量池：是办法区的一部分，Class文件中除了有类的版本、字段、办法、接口等形容信息外，还有一项信息是常量池表，用于寄存编译期生成的各种字面量与符号援用
这部分内容将在类加载后寄存到办法区的运行时常量池中
当常量池无奈申请到内存时，也会抛出OOM
对于64位JVM来说，默认初始大小为20.75M，默认最大值是有限的。
通过-XX:MetaspaceSize=N和 -XX:MaxMetaspaceSize=N调整初始值和最大值，个别设置成一样大，因为元空间的调整须要full gc，这个是十分低廉的操作
堆内存
以后大多数商业虚拟机的垃圾收集器，都遵循分代收集的实践进行设计
弱分代假说：绝大多数对象都是朝生夕灭的
强分代假说：熬过越屡次垃圾收集过程的对象就越难以沦亡
所以咱们罕用的垃圾收集器，都有一个共性：将Java堆分出不同的区域，根据回收对象的年龄，调配到不同的区域中进行存储。不同区域的对象对应不同的分代年龄，同时也对应不同的垃圾收集频率
在Java堆划分出不同的区域之后，垃圾收集器才能够每次只回收其中某一个或者某些局部的区域——因此才有了“Minor GC”“Major GC”“Full GC”这样的回收类型的划分
也才可能针对不同的区域安顿与外面存储对象存亡特色相匹配的垃圾收集算法——因此倒退出了“标记-复制算法”“标记-革除算法”“标记-整顿算法”等针对性的垃圾收集算法
1、堆内存分为老年代和年老代，默认占比为2：1
2、年老代中分为Eden和s0、s1，默认占比为8：1：1
3、新new进去的对象，先进入eden
4、eden满了后，触发minor gc后，采纳可达性算法，无援用的间接革除
5、minor gc时，在eden标记的非垃圾对象，从eden区转移到s0区
6、minor gc时，在s0区找到的非垃圾对象，从s0转移到s1区，垃圾间接革除
相当于每一次gc，年老代中的对象，要么被垃圾回收，要么在eden、s0、s1之间进行一次区域转移，留神，程序只可能是eden—>s0—>s1。每个对象会被标记以后曾经经验了几次gc
7、当对象经验过15次gc还没被干掉，则转移到老年代
至此，咱们应该对堆内存有了一个大略的印象了。
堆内存调优实战
案例1：s0空间过小导致的老年代堆空间问题
通过接口状况，计算出每秒钟新生成的对象大略有多少，咱们以每个对象1kb进行计算，假如算下来每秒钟生成60MB的堆内存对象
如果咱们只设置了堆内存大小（-Xms -Xmx），那么就会依照老年代：年老代 2：1，edge：s0：s1 8：1：1的比例进行堆内存的调配
景象：频繁的触发full gc，即老年代老是不够用
起因：当一次minor gc的时候，局部对象逃过了被革除的命运，失常是应该从eden到s0去的，然而，如果这部分内存的大小超过了s0大小的一半，就会被间接挪到老年代。这就会导致老年代不够用，几轮minor gc后就触发full gc
解决办法：将JVM配置改为
将老年代的内存空间放大，空间给年老代。
留神：eden和s0、s1之间的空间大小比值，是通过大量计算后得出的最优值，个别不会进行调整，所以这里就调整了年老代和老年代的比值，就达到了成果
这里的解决思路，就是让那些长期对象，尽可能在年老代中就被gc革除，而不要让他们因为某些起因，被转移到老年代中
案例2：eden过大导致的垃圾回收不及时问题
在案例1中，除了咱们通过调配年老代和老年代之间的内存大小，来达到让垃圾内存在年老代就被革除掉的目标，其实还能够间接通过扩充堆内存的形式来进行，而后依照默认比例，各个堆内存空间同比放大了。
可是内存难道就是越大越好吗？
所谓物极必反，如果内存空间很大，那么势必eden空间也很大，长期都无奈触发minor gc，一旦达到gc条件了，一次性要革除的对象就会十分多。这就导致STW的工夫变长，升高gc时刻零碎的可用性/吞吐量
那么该怎么解决大内存下的gc问题呢？
思路：不要等到eden满了再去回收，能够设置触发gc的时候，只回收局部区域的内存。这样就能保障一次gc的时候SWT的工夫不会太长
可能实现这种垃圾回收形式的，就是G1垃圾回收器，实用于大内存的场景
怎么配置呢？ -XX:UseG1GC -XX:MaxGCPauseMillis=100，这里的意思是每次gc的时候最大进展工夫为100毫秒，默认为200毫秒
java-Xms64G-Xmx64G-Xss1M-XX：+UseG1GC-XX:MaxGCPauseMillis=100 -XX:MetaspaceSize=512M -XX:MaxMetaspaceSize=512M -jar micro service-eureka-server.jar