对于JVM“逃逸分析” 特性，也是近年来大厂面试、高薪面试的常见面试题。
和逃逸分析有关的常见面试题：
- Java中的对象一定是在堆上分配的吗？
JVM的内存分配策略-
首先回顾一下JVM的内存分配策略。
JVM的内存包括方法区、堆、虚拟机栈、本地方法栈、程序计数器。
一般情况下JVM运行时的数据都是存在栈和堆上的。
- 栈用来存放一些基本变量和对象的引用，
- 堆用来存放数组和对象，也就是说new出来的实例。
但是：凡事都有例外
随着JIT编译器的发展和逃逸分析的技术成熟，栈上分配、标量替换等优化技术，使对象不一定全都分配在堆中。
so，重点来了：对象不一定全都分配在堆中
在JVM的实现中，为了提高JVM的性能和节省内存空间，JVM提供了一种叫做 “逃逸分析” 的特性，逃逸分析是目前Java虚拟机中比较前沿的优化技术，也是JIT中一个很重要的优化技术。
“逃逸分析” 的直观认知
直接说这些概念，确实有点晕啊，那我们就来“逃逸分析” 的直观认知。
三连问： “逃逸分析” 的本质是什么呢？为什么叫逃逸？逃逸的范围是什么呢？
“逃逸分析” 的本质：
主要就是分析对象的动态作用域，分析一个对象的动态作用域是否会逃逸出方法范围、或者线程范围。
简单的说：
如果一个对象在一个方法内定义，如果被方法外部的引用所指向，那认为它逃逸了。
否者，这个对象，没有发生逃逸。
尼恩提示：
看起来一个 很牛逼轰轰的概念，其实就是这么简单。
逃逸分析的概念
先以官方的形式来说下什么是逃逸分析。
逃逸分析就是：一种确定指针动态范围的静态分析，它可以分析在程序的哪些地方可以访问到指针。
在JVM的即时编译语境下，逃逸分析将判断新建的对象是否逃逸。
即时编译判断对象是否逃逸的依据：
一种是对象是否被存入堆中（静态字段或者堆中对象的实例字段），另一种就是对象是否被传入未知代码。
逃逸分析的类型
逃逸分析的类型有两种：
- 方法逃逸
- 线程逃逸
什么是：方法逃逸(对象逃出当前方法)：
当一个对象在方法里面被定义后，它可能被外部方法所引用，例如作为调用参数传递到其它方法中。
什么是：线程逃逸((对象逃出当前线程)：
这个对象甚至可能被其它线程访问到，例如赋值给类变量或可以在其它线程中访问的实例变量
方法逃逸
当一个对象在方法里面被定义后，它可能被外部方法所引用，这种称为方法逃逸
方法逃逸包括：
- 通过调用参数，将对象地址传递到其他方法中，
- 对象通过return语句将对象指针，返回给其他方法
- 等等
我们可以用下面的代码来表示这个现象。
//StringBuffer对象发生了方法逃逸
public static StringBuffer createStringBuffer(String s1, String s2) {
StringBuffer sb = new StringBuffer();
sb.append(s1);
sb.append(s2);
return sb;
}
上面的例子中，StringBuffer 对象通过return语句返回。
StringBuffer sb是一个方法内部变量，上述代码中直接将sb返回，这样这个StringBuffer有可能被其他方法所改变，这样它的作用域就不只是在方法内部，虽然它是一个局部变量，称其逃逸到了方法外部。
甚至还有可能被外部线程访问到，譬如赋值给类变量或可以在其他线程中访问的实例变量，称为线程逃逸。
不直接返回 StringBuffer，那么StringBuffer将不会逃逸出方法。
具体的代码如下：
// 非方法逃逸
public static String createString(String s1, String s2) {
StringBuffer sb = new StringBuffer();
sb.append(s1);
sb.append(s2);
return sb.toString();
}
可以看出，想要逃逸方法的话，需要让对象本身被外部调用，或者说， 对象的指针，传递到了 方法之外。
线程逃逸
当一个对象可能被外部线程访问到，这种称为线程逃逸。
例如赋值给类变量或可以在其它线程中访问的实例变量
逃逸分析后的代码优化
从不逃逸、方法逃逸到线程逃逸，称为对象由低到高的不同逃逸程度。
如果能证明一个对象不会逃逸到方法或线程之外（换句话说是别的方法或线程无法通过任何途径访问到这个对象），或者逃逸程度比较低（只逃逸出方法而不会逃逸出线程），则可能为这个对象实例采取不同程度的优化。
通过逃逸分析，编译器会对代码进行优化。
如果能够证明一个对象不会逃逸到方法外或者线程外，或者说逃逸程度比较低，则可以对这个对象采用不同程度的优化：
- 栈上分配
- 标量替换
- 消除同步锁
栈上分配
对象不分配在堆上，而是分配在栈内存上。
前提是：对象没有逃逸，很老实的话。
具体而言：
完全不会逃逸的局部变量和不会逃逸出的线程对象，采用栈上分配，
对于发生逃逸的、不老实的对象，才使用 堆上分配。
栈上分配可以快速地在栈帧上创建和销毁对象，不用再将对象分配到堆空间，可以有效地减少 JVM 垃圾回收的压力。
标量替换
一个对象可能不需要作为一个连续的存储空间，也能被访问到，那么对象的部分可以不存储的在连续的内存，而是存可以打散存储，甚至部分存储或者打散在CPU寄存器中。
通过逃逸分析确定该对象不会被外部访问后，JVM判断对象是否可以被进一步分解，如果对象可以打散为 变量，则 JVM不会创建该对象，而是化整为零， 将该对象成员变量分解若干个被这个方法使用的成员变量，
JVM将一个大的对象打散成若干变量的过程，叫做标量替换，也称之为 分离对象。
比如如下代码：
public static void main(String[] args) {
alloc();
}
private static void alloc() {
Point point = new Point（1,2）;
System.out.println("point.x="+point.x+"; point.y="+point.y);
}
class Point{
private int x;
private int y;
}
从以上代码可以看出，Point对象并没有逃逸出alloc方法，并且Point对象是可以拆解成标量的。
此时，JIT就会不会直接创建Point对象，而是直接使用两个标量int x,int y来替代Point对象
为啥要 化整为零 呢？
因为 栈空间是非常有限的，很多的场景下，一个线程的栈空间就是1M的大小。
标量替换之后的成员变量，可以选择在栈帧分配，也可以就近在寄存器上分配空间，这样就不会因为没有一大块连续空间导致对象内存不够分配。
开启标量替换参数-XX:+EliminateAllocations，JDK7之后默认开启。
总之：
当JVM通过逃逸分析，确定要将对象分配到栈上时，即时编译可以将对象打散，将对象替换为一个个很小的局部变量，我们将这个打散的过程叫做标量替换。
将对象替换为一个个局部变量后，就可以非常方便的在栈上进行分配了。
同步锁消除
如果JVM通过逃逸分析，发现一个对象只能从一个线程被访问到，则访问这个对象时，可以不加同步锁。
具体来说：
如果同步块所使用的锁对象通过这种分析后，发现只能够被一个线程访问，根本用不着同步，
那么，JIT编译器在编译这个同步块的时候就会取消对这部分代码的同步锁。
所以：如果程序中使用了synchronized内置锁锁，则JVM会将synchronized内置锁消除。
注意：
这种情况针对的是synchronized锁，而对于非内置锁，比如 Lock 显示锁、CAS乐观锁等等，则JVM并不能消除。
要开启同步消除，需要加加上两个JVM启动选项：
-XX:+EliminateLocks
-XX:+DoEscapeAnalysis
-XX:+EliminateLocks启动选项，表示启动同步锁消除。
-XX:+DoEscapeAnalysis 选项，表示启动逃逸分析。
因为同步锁消除依赖逃逸分析，所以同时要打开 -XX:+DoEscapeAnalysis 选项。
逃逸分析相关JVM参数
-XX:+DoEscapeAnalysis 开启逃逸分析
-XX:+PrintEscapeAnalysis 开启逃逸分析后，可通过此参数查看分析结果。
-XX:+EliminateAllocations 开启标量替换
-XX:+EliminateLocks 开启同步消除
-XX:+PrintEliminateAllocations 开启标量替换后，查看标量替换情况。
逃逸分析的底层原理是什么呢？
在Java的编译体系中，一个Java的源代码文件变成计算机可执行的机器指令的过程中，需要经过两段编译：
第一段编译，指前端编译器把**.java文件**转换成 .class文件(字节码文件)。
前端编译器产品可以是JDK的Javac、Eclipse JDT中的增量式编译器。
第二编译阶段，JVM 通过解释字节码将其翻译成对应的机器指令，逐条读入字节码，逐条解释翻译成机器码。
很显然，由于有一个解释的中间过程，其执行速度必然会比可执行的二进制字节码程序慢很多。
这就是传统的JVM的解释器（Interpreter）的功能。
如何去掉中间商，提升效率？
为了解决这种效率问题，引入了JIT（即时编译器，Just In Time Compiler）技术。
引入了 JIT 技术后，Java程序还是通过解释器进行解释执行，也就是说，主体还是解释执行，只是局部去掉中间环节。
怎么做局部去掉中间环节呢？
当JVM发现某个方法或代码块运行特别频繁的时候，就会认为这是“热点代码”（Hot Spot Code)。
然后JIT会把部分“热点代码”翻译成本地机器相关的机器码，并进行优化，然后再把翻译后的机器码缓存起来，以备下次使用。
把翻译后的机器码缓存在哪里呢？ 这个 缓存，叫做 Code Cache。 可见，JVM和WEB应用实现高并发的手段是类似的，还是使用了缓存架构。
当JVM下次遇到相同的热点代码时，跳过解释的中间环节，直接从 Code Cache加载机器码，直接执行，无需 再编译。
所以，JIT总的目标是发现热点代码， 热点代码变成了提升性能的关键，hotspot JVM的名字，也就是这么来的，把识别热点代码，写在名字上，作为毕生的追求。
所以，JVM总的策略为：
- 对于占据大部分的不常用的代码，我们无需耗费时间将其编译成机器码，而是采取解释执行的方式运行；
- 另一方面，对于仅占据小部分的热点代码，我们则可以将其编译成机器码，以达到理想的运行速度。
JIT(即时编译)的出现与 解释器的区别
（1）解释器是将字节码解释为机器码，下次即使遇到相同的字节码，仍会执行重复的解释。
（2）JIT 是将一些字节码编译为机器码，并存入 Code Cache，下次遇到相同的代码，直接执行，无需 再编译。
（3）解释器是将字节码解释为针对所有平台都通用的机器码。
（4）JIT 会根据平台类型，生成平台特定的机器码。
JVM包含多个即时编译器，主要有C1和C2，还有个Graal (实验性的)。
多个即时编译器, 都会对字节码进行优化并生成机器码
C1会对字节码进行简单可靠的优化，包括方法内联、去虚拟化、冗余消除等，编译速度较快，可以通过-client强制指定C1编译
C2会对字节码进行激进优化，包括分支频率预测、同步擦除等，
可以通过-server强制指定C2编译
JVM 将执行状态分成了 5 个层次：
- 0 层，解释执行（Interpreter）
- 1 层，使用 C1 即时编译器编译执行（不带 profiling）
- 2 层，使用 C1 即时编译器编译执行（带基本的 profiling）
- 3 层，使用 C1 即时编译器编译执行（带完全的 profiling）
- 4 层，使用 C2 即时编译器编译执行
JVM不会直接启用C2，而是先通过C1编译收集程序的运行状态，再根据分析结果判断是否启用C2。
分层编译模式下, 虚拟机执行状态由简到繁、由快到慢分为5层
在编译期间，JIT 除了对 热点代码做缓存提速，会对代码做很多优化。
其中有一部分优化的目的就是减少内存堆分配压力，其中JIT优化中一种重要的技术叫做逃逸分析。根据逃逸分析，即时编译器会在编译过程中对代码做如下优化：
- 锁消除：当一个锁对象只被一个线程加锁时，即时编译器会把锁去掉
- 栈上分配：当一个对象没有逃逸时，会将对象直接分配在栈上，随着线程回收，由于JVM的大量代码都是堆分配，所以目前JVM不支持栈上分配，而是采用标量替换
- 标量替换：当一个对象没有逃逸时，会将当前对象打散成若干局部变量，并分配在虚拟机栈的局部变量表中
关于面试题答案：Java中的对象一定是在堆上分配的吗？
答：不一定。
如果满足了逃逸分析的条件，一个对象，完全可以在栈上分配。减少堆内存的分配和GC压力。
由于栈内存有限，所以， 如果对象符合标量替换的条件，进一步为对象来一次化整为零的手术
标量替换具体的做法是：
JVM会将对象进一步打散，将对象分解为若干个被这个方法使用的成员变量，从而，达到更好的利用栈内存和寄存器的目标
参考文献
-
ThreadLocal（史上最全）
https://www.cnblogs.com/crazymakercircle/p/14491965.html -
3000页《尼恩 Java 面试宝典 》的 35个面试专题 ：
https://www.cnblogs.com/crazymakercircle/p/13917138.html -
价值10W的架构师知识图谱
https://www.processon.com/view/link/60fb9421637689719d246739
4、尼恩 架构师哲学
https://www.processon.com/view/link/616f801963768961e9d9aec8
5、尼恩 3高架构知识宇宙
https://www.processon.com/view/link/635097d2e0b34d40be778ab4
Guava Cache主页：https://github.com/google/guava/wiki/CachesExplained
Caffeine的官网：https://github.com/ben-manes/caffeine/wiki/Benchmarks
https://gitee.com/jd-platform-opensource/hotkey
https://developer.aliyun.com/article/788271?utm_content=m_1000291945
https://b.alipay.com/page/account-manage-oc/approval/setList
Caffeine: https://github.com/ben-manes/caffeine
这里: https://albenw.github.io/posts/df42dc84/
Benchmarks: https://github.com/ben-manes/caffeine/wiki/Benchmarks
官方API说明文档: https://github.com/ben-manes/caffeine/wiki
这里: https://github.com/ben-manes/caffeine/wiki/Guava
HashedWheelTimer时间轮原理分析: https://albenw.github.io/posts/ec8df8c/
TinyLFU论文: https://arxiv.org/abs/1512.00727
Design Of A Modern Cache: http://highscalability.com/blog/2016/1/25/design-of-a-modern-cache.html
Design Of A Modern Cache—Part Deux: http://highscalability.com/blog/2019/2/25/design-of-a-modern-cachepart-deux.html
Caffeine的github: https://github.com/ben-manes/caffeine
https://github.com/axinSoochow/redis-caffeine-cache-starter
https://www.cnblogs.com/liang24/p/14210542.html
https://www.jianshu.com/p/62757d2a592c
https://blog.csdn.net/tongkongyu/article/details/124842847
https://www.163.com/dy/article/FSC51E7G0511FQO9.html
https://blog.csdn.net/Hellowenpan/article/details/121264731
https://www.jianshu.com/p/3c6161e5337b
https://blog.csdn.net/darin1997/article/details/89397862
https://blog.csdn.net/weixin_42297591/article/details/112658262)
https://www.cnblogs.com/liujinhua306/p/9808500.html
https://blog.csdn.net/varyall/article/details/81172725
http://www.cnblogs.com/zhaoxinshanwei/p/8519717.html
https://segmentfault.com/a/1190000016091569?utm_source=tag-newest
https://www.javadevjournal.com/spring-boot/spring-boot-with-caffeine-cache/
https://sunitc.dev/2020/08/27/springboot-implement-caffeine-cache/
https://github.com/ben-manes/caffeine/wiki/Population-zh-CN
https://www.cnblogs.com/Mufasa/p/15994714.html
https://www.cnblogs.com/liujinhua306/p/9808500.html