你好呀，我是why。
你猜这次我又要写个啥没有卵用的知识点呢？
不好意思，问的稍微有点早了，啥提示都没给，咋猜呢，对吧？
先给你上个代码：
public class ExceptionTest {public static void main(String[] args) {String msg = null;for (int i = 0; i < 500000; i++) {try {msg.toString();} catch (Exception e) {e.printStackTrace();}}}
}
来，就这代码，你猜猜写出个什么花儿来？
当然了，有猜到的朋友，也有没猜到的朋友。
很好，那么请猜出来了的同学迅速拉到文末，完成一键三连的任务后，就可以出去了。
没有猜出来的同学，我把代码一跑起来，你就知道我要说啥了：
一瞬间的事儿，瞅见了吗？神奇吗？产生疑问了吗？
没关系，你要没看清楚，我还能给你截个图：
在抛出一定次数的空指针异常后，异常堆栈没了。
这就是我标题说的：太扯了吧？异常信息突然就没了。
你说为啥？
为啥？
这事就得从 2004 年讲起了。
那一年，SUN 公司于 9 月 30 日 18 点发布了 JDK 5。
在其 release-notes 中有这样一段话：
https://www.oracle.com/java/technologies/javase/release-notes-introduction.html
主要是框起来的这句话，看不明白没关系，我用我八级半的英语给你翻译一下。
我们一句句的来：
The compiler in the server VM now provides correct stack backtraces for all “cold” built-in exceptions.
对于所有的内置异常，编译器都可以提供正确的异常堆栈的回溯。
For performance purposes, when such an exception is thrown a few times, the method may be recompiled.
出于性能的考虑，当一个异常被抛出若干次后，该方法可能会被重新编译。（重要）
After recompilation, the compiler may choose a faster tactic using preallocated exceptions that do not provide a stack trace.
在重新编译之后，编译器可能会选择一种更快的策略，即不提供异常堆栈跟踪的预分配异常。（重要）
To disable completely the use of preallocated exceptions, use this new flag: -XX:-OmitStackTraceInFastThrow.
如果要禁止使用预分配的异常，请使用这个新参数：-XX:-OmitStackTraceInFastThrow。
这几句话先不管理解没有。但是至少知道它这里描述的场景不就是刚刚代码演示的场景吗？
它最后提到了一个参数 -XX:-OmitStackTraceInFastThrow，二话不说，先拿来用了，看看效果再说：
同样的代码，加入该启动参数后，异常堆栈确实会从头到尾一直打印。
不知道你感觉到没有，加入该启动参数后，程序运行时间明显慢了很多。
在我的机器上没加该参数，程序运行时间是 2826 ms，加上该参数运行时间是 5885 ms。
说明确实是有提升性能的功能。
到底是咋提升的，下一节说。
先说个其他的。
这里都提到 JVM 参数了，我顺便再分享一个网站：
https://club.perfma.com/topic/OmitStackTraceInFastThrow
该网站提供了很多功能，这是其中的几个功能：
JVM 参数查询功能那必须得有：
很好用的，你以后遇到不知道是干啥用的 JVM 参数，可以在这个网站上查询一下。
到底为啥？
前面讲了是出于性能原因，从 JDK 5 开始会出现异常堆栈丢失的现象。
那么性能问题到底在哪？
来，我们一起看一下最常见的空指针异常。
以本文为例，看一下异常抛出的时候调用路径：
最终会走到这个 native 方法：
java.lang.Throwable#fillInStackTrace(int)
fill In Stack Trace，顾名思义，填入堆栈跟踪。
这个方法会去爬堆栈，而这个过程就是一个相对比较消耗性能的过程。
为啥比较耗时呢？
给你看个比较直观的：
这类的异常堆栈才是我们比较常见的，这么长的堆栈信息，可不消耗性能吗。
现在，我们现在再回去看这句话：
For performance purposes, when such an exception is thrown a few times, the method may be recompiled. After recompilation, the compiler may choose a faster tactic using preallocated exceptions that do not provide a stack trace.
出于性能的考虑，当一个异常被抛出若干次后，该方法可能会被重新编译。在重新编译之后，编译器可能会选择一种更快的策略，即不提供异常堆栈跟踪的预分配异常。
所以，你能明白，这个“出于性能的考虑”这句话，具体指的就是节约 fillInStackTrace（爬堆栈）的这个性能消耗。
更加深入一点的研究对比，你可以看看这个链接：
http://java-performance.info/throwing-an-exception-in-java-is-very-slow
我这里贴一下结论：
关于消除异常的性能消耗，他提出了三个解决方案：
重构你的代码不使用它们。
缓存异常实例。
重写 fillInStackTrace 方法。
通过小日…小日子过的还不错的日本的站点，输入关键信息后，知乎的这个链接排在第二个：
https://www.zhihu.com/question/21405047
这个问题下面，有一个R大的回答，粘贴给你看看：
大家都不约而同的提到了重写 fillInStackTrace 方法，这个性能优化小技巧，也就是我们可以这样去自定义异常：
用一个不严谨的方式测试一下，你就看这个意思就行：
重写了 fillInStackTrace 方法，直接返回 this 的对象，比调用了爬栈方法的原始方法，快了不是一星半点儿。
其实除了重写 fillInStackTrace 方法之外，JDK 7 之后还提供了这样的一个方法：
java.lang.Throwable#Throwable(java.lang.String, java.lang.Throwable, boolean, boolean)
可以通过 writableStackTrace 入参来控制是否需要去爬栈。
那么到底什么时候才应该去用这样的一个性能优化手段呢？
其实R大的回答里面说的很清楚了：
其实我们写业务代码的，异常信息打印还是非常有必要的。
但是对于一些追求性能的框架，就可以利用这个优势。
比如我在 disruptor 和 kafka 的源码里面都找到了这样的优化落地源码。
先看 disruptor 的：
com.lmax.disruptor.AlertException
- Overridden so the stack trace is not filled in for this exception for performance reasons.
- 由于性能的原因，重载后的堆栈跟踪不会被填入这个异常。
再看 kafka 的：
org.apache.kafka.common.errors.ApiException
- avoid the expensive and useless stack trace for api exceptions
- 避免对api异常进行昂贵而无用的堆栈跟踪
而且你注意到了吗，上面着两个框架中，直接把 synchronized 都干掉了。如果你也打算重写，那么也可以分析一下你的场景中是否可以去掉 synchronized，性能又可以来一点提升。
另外，R大的回答里面还提到了这个优化是 C2 的优化。
我们可以简单的证明一下。
分层编译
前面提到的 C2，其实还有一个对应的 C1。这里说的 C1、C2 都是即时编译器。
你要是不熟悉 C1、C2，那我换个说法。
C1 其实就是 Client Compiler，即客户端编译器，特点是编译时间较短但输出代码优化程度较低。
C2 其实就是 Server Compiler，即服务端编译器，特点是编译耗时长但输出代码优化质量也更高。
大家常常提到的 JVM 帮我们做的很多“激进”的为了提升性能的优化，比如内联、快慢速路径分析、窥孔优化，包括本文说的“不显示异常堆栈”，都是 C2 搞的事情。
多说一句，在 JDK 10 的时候呢，又推出了 Graal 编译器，其目的是为了替代 C2。
至于为什么要替换 C2，额，原因之一是这样的…
http://icyfenix.cn/tricks/2020/graalvm/graal-compiler.html
C2 的历史已经非常长了，可以追溯到 Cliff Click 大神读博士期间的作品，这个由 C++ 写成的编译器尽管目前依然效果拔群，但已经复杂到连 Cliff Click 本人都不愿意继续维护的程度。
你看前面我说的 C1、C1 的特点，刚好是互补的。
所以为了在程序启动、响应速度和程序运行效率之间找到一个平衡点，在 JDK 6 之后，JVM 又支持了一种叫做分层编译的模式。
也是为什么大家会说：“Java 代码运行起来会越来越快、Java 代码需要预热”的根本原因和理论支撑。
在这里，我引用《深入理解Java虚拟机HotSpot》一书中 7.2.1 小节[分层编译]的内容，让大家简单了解一下这是个啥玩意。
首先，我们可以使用 -XX:+TieredCompilation 开启分层编译，它额外引入了四个编译层级。
- 第 0 级：解释执行。
- 第 1 级：C1 编译，开启所有优化（不带 Profiling）。Profiling 即剖析。
- 第 2 级：C1 编译，带调用计数和回边计数的 Profiling 信息（受限 Profiling).
- 第 3 级：C1 编译，带所有Profiling信息（完全Profiling).
- 第 4 级：C2 编译。
常见的分层编译层级转换路径如下图所示：
- 0→3→4：常见层级转换。用 C1 完全编译，如果后续方法执行足够频繁再转入 4 级。
- 0→2→3→4：C2 编译器繁忙。先以 2 级快速编译，等收集到足够的 Profiling 信息后再转为3级，最终当 C2 不再繁忙时再转到 4 级。
- 0→3→1/0→2→1：2/3级编译后因为方法不太重要转为 1 级。如果 C2 无法编译也会转到 1 级。
- 0→(3→2)→4：C1 编译器繁忙，编译任务既可以等待 C1 也可以快速转到 2 级，然后由 2 级转向 4 级。
如果你之前不知道分层编译这回事，没关系，现在有这样的一个概念就行了。面试不会考的，放心。
接下来，就要提到一个参数了：
-XX:TieredStopAtLevel=___
看名字你也知道了，这个参数的作用是让分层编译停在某一层，默认值为 4，也就是到 C2 编译。
那我把该值修改为 3，岂不是就只能用 C1 了，那就不能利用 C2 帮我优化异常啦？
实验一波：
果然如此，R大诚不欺我。
