纳尼？？？我JVM优化过头了，直接把异常信息优化没了？怎么办

客官°小女子只卖身不卖艺 2022-09-14 13:26 80阅读 0赞

你好呀，我是why。

你猜这次我又要写个啥没有卵用的知识点呢？

![image][]

不好意思，问的稍微有点早了，啥提示都没给，咋猜呢，对吧？

先给你上个代码：

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();
                }
            }
        }
    }

来，就这代码，你猜猜写出个什么花儿来？

当然了，有猜到的朋友，也有没猜到的朋友。

很好，那么请猜出来了的同学迅速拉到文末，完成一键三连的任务后，就可以出去了。

没有猜出来的同学，我把代码一跑起来，你就知道我要说啥了：

![image][image 1]

一瞬间的事儿，瞅见了吗？神奇吗？产生疑问了吗？

![image][image 2]

没关系，你要没看清楚，我还能给你截个图：

![image][image 3]

在抛出一定次数的空指针异常后，异常堆栈没了。

这就是我标题说的：太扯了吧？异常信息突然就没了。

![image][image 4]

你说为啥？

## 为啥？ ##

这事就得从 2004 年讲起了。

那一年，SUN 公司于 9 月 30 日 18 点发布了 JDK 5。

在其 release-notes 中有这样一段话：

> https://www.oracle.com/java/technologies/javase/release-notes-introduction.html

![image][image 5]

主要是框起来的这句话，看不明白没关系，我用我八级半的英语给你翻译一下。

我们一句句的来：

> 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`，二话不说，先拿来用了，看看效果再说：

![image][image 6]

同样的代码，加入该启动参数后，异常堆栈确实会从头到尾一直打印。

不知道你感觉到没有，加入该启动参数后，程序运行时间明显慢了很多。

在我的机器上没加该参数，程序运行时间是 2826 ms，加上该参数运行时间是 5885 ms。

说明确实是有提升性能的功能。

到底是咋提升的，下一节说。

先说个其他的。

这里都提到 JVM 参数了，我顺便再分享一个网站：

> https://club.perfma.com/topic/OmitStackTraceInFastThrow

该网站提供了很多功能，这是其中的几个功能：

![image][image 7]

JVM 参数查询功能那必须得有：

![image][image 8]

![image][image 9]

很好用的，你以后遇到不知道是干啥用的 JVM 参数，可以在这个网站上查询一下。

## 到底为啥？ ##

前面讲了是出于性能原因，从 JDK 5 开始会出现异常堆栈丢失的现象。

那么性能问题到底在哪？

来，我们一起看一下最常见的空指针异常。

以本文为例，看一下异常抛出的时候调用路径：

![image][image 10]

最终会走到这个 native 方法：

> java.lang.Throwable\#fillInStackTrace(int)

fill In Stack Trace，顾名思义，填入堆栈跟踪。

这个方法会去爬堆栈，而这个过程就是一个相对比较消耗性能的过程。

为啥比较耗时呢？

给你看个比较直观的：

![image][image 11]

这类的异常堆栈才是我们比较常见的，这么长的堆栈信息，可不消耗性能吗。

现在，我们现在再回去看这句话：

> 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

![image][image 12]

我这里贴一下结论：

![image][image 13]

关于消除异常的性能消耗，他提出了三个解决方案：

> 重构你的代码不使用它们。  
> 缓存异常实例。  
> 重写 fillInStackTrace 方法。

通过小日…小日子过的还不错的日本的站点，输入关键信息后，知乎的这个链接排在第二个：

![image][image 14]

> https://www.zhihu.com/question/21405047

![image][image 15]

这个问题下面，有一个R大的回答，粘贴给你看看：

![image][image 16]

大家都不约而同的提到了重写 fillInStackTrace 方法，这个性能优化小技巧，也就是我们可以这样去自定义异常：

![image][image 17]

用一个不严谨的方式测试一下，你就看这个意思就行：

![image][image 18]

重写了 fillInStackTrace 方法，直接返回 this 的对象，比调用了爬栈方法的原始方法，快了不是一星半点儿。

其实除了重写 fillInStackTrace 方法之外，JDK 7 之后还提供了这样的一个方法：

> java.lang.Throwable\#Throwable(java.lang.String, java.lang.Throwable, boolean, boolean)

![image][image 19]

可以通过 writableStackTrace 入参来控制是否需要去爬栈。

那么到底什么时候才应该去用这样的一个性能优化手段呢？

其实R大的回答里面说的很清楚了：

![image][image 20]

其实我们写业务代码的，异常信息打印还是非常有必要的。

但是对于一些追求性能的框架，就可以利用这个优势。

比如我在 disruptor 和 kafka 的源码里面都找到了这样的优化落地源码。

先看 disruptor 的：

> com.lmax.disruptor.AlertException

![image][image 21]

>  *  Overridden so the stack trace is not filled in for this exception for performance reasons.
>  *  由于性能的原因，重载后的堆栈跟踪不会被填入这个异常。

再看 kafka 的：

> org.apache.kafka.common.errors.ApiException

![image][image 22]

>  *  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 编译。

常见的分层编译层级转换路径如下图所示：

![image][image 23]

>  *  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=\_\_\_

![image][image 24]

看名字你也知道了，这个参数的作用是让分层编译停在某一层，默认值为 4，也就是到 C2 编译。

那我把该值修改为 3，岂不是就只能用 C1 了，那就不能利用 C2 帮我优化异常啦？

实验一波：

![image][image 25]

果然如此，R大诚不欺我。

![image][image 26]

[image]: /images/20220828/719d5643cf2349b3827f6e0546feb822.png
[image 1]: /images/20220828/c8e6275d1f8145cdad10a938692d2257.png
[image 2]: /images/20220828/29a8a8b0c96144d9b4530e4028ed197a.png
[image 3]: /images/20220828/c535865fda1f47c5bef75ae94e1df7fa.png
[image 4]: /images/20220828/65df0540a80b41e7b2e251b73177d857.png
[image 5]: /images/20220828/57035e22a12049d48f6d849adfd36e3c.png
[image 6]: /images/20220828/525cfa51d62b45b0a890bfa69fcf177b.png
[image 7]: /images/20220828/7876b931b92b4797b9aa3664b3c1c273.png
[image 8]: /images/20220828/054273c1a74e480fb00b57689b0d2edc.png
[image 9]: /images/20220828/af4b9468f8494ce58ee4275ab7fa9f84.png
[image 10]: /images/20220828/70f48ab831fe455f80f9d8c5807b432c.png
[image 11]: /images/20220828/287fa1c52d3649658acc8431c21320f6.png
[image 12]: /images/20220828/e03035136c10467cbae118774032cb57.png
[image 13]: /images/20220828/17e4e4c1a00e49ea9bb0896d8d0e7018.png
[image 14]: /images/20220828/9f293b5f3a57499c92a4b1a15f53f2a0.png
[image 15]: /images/20220828/3e6bd16963ee42938d4beb6785ae73ea.png
[image 16]: /images/20220828/167c268053cb44b79c01603de642827c.png
[image 17]: /images/20220828/352c973383934ae9a84c39b8792f14f4.png
[image 18]: /images/20220828/c7120b1b02484a77ad5e4352e1462b40.png
[image 19]: /images/20220828/69b56eb83fc64953938140d5a6958e32.png
[image 20]: /images/20220828/8976d77033734f22a31a22b357e6b99b.png
[image 21]: /images/20220828/06c9025e0d6448f99a19641328bcdafd.png
[image 22]: /images/20220828/5e9d75a7a4384150b11a287b0497eeee.png
[image 23]: /images/20220828/51dd00fb772a42808f0888cfb55edfc2.png
[image 24]: /images/20220828/b9f4ddeff6f84c93b572c036d0cc9066.png
[image 25]: /images/20220828/1763a352c23f44c18931fcf8ca35820e.png
[image 26]: /images/20220828/d5a02c80e3ee4167a09e29fc169b9bee.png