重载 Throwable.fillInStackTrace() 方法以提高Java性能这样的做法对吗？ 第1页

只要那个自定义异常类型是真的不需要stack trace的，我也会推荐覆写fillInStackTrace()为直接返回this。

爬栈是抛异常开销大的主要原因之一。

<- 但注意好前提就是了——要确定真的肯定绝对不需要stack trace的话。

一个简单的例子是，“滥用”异常来实现某些特殊控制流结构的场景，此时stack trace肯定是没用的，那个异常对象本身其实也没用，只有它的类型和抛出它带来的控制流跳转才有用，那就应该覆写fillInStackTrace()。

=======================================

然后从反面举个例子。HotSpot VM有个许多人觉得“匪夷所思”的优化，叫做fast throw：有些特定的隐式异常类型（NullPointerException、ArithmeticException（ / 0）之类）如果在代码里某个特定位置被抛出过多次的话，HotSpot Server Compiler（C2）会透明的决定用fast throw来优化这个抛出异常的地方——直接抛出一个事先分配好的、类型匹配的异常对象。这个对象的message和stack trace都被清空。抛出这个异常的速度是非常快，不但不用额外分配内存，而且也不用爬栈；但反面就是可能正好是需要知道哪里出问题的时候看不到stack trace了。

从Sun JDK5开始要避免C2做这个优化还得额外传个VM参数：-XX:-OmitStackTraceInFastThrow。

覆写fillInStackTrace()为直接返回this就像是人肉做C2所做的那种优化…的一部分效果。反正肯定会有人抱怨这样不好的啦，是不是要顶住压力硬上就看到底在特定场景里带来的性能好处是不是真的那么重要了。