重载Throwable.fillInStackTrace方法已提高Java性能这样的做法对法？
总有哪么些人拿Java异常的性能问题说事，做法是为自定义异常重载Throwable.fillInStackTrace方法，让其返回this。这样做，在测试时确实会快很多，但有什么不妥的地方吗?
关注者
41
被浏览
3022
5 个回答
只要那个自定义异常类型是真的不需要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。
IT
可以。但是最主要的是取决于你怎么使用Exception。
有种观点认为，业务失败异常流程应该基于Exception控制，在这样的项目里就会看到大量的基于业务定义的Exception类，比如UserNotFoundException，LoginFailException什么的。或者把Service层所有的异常分支都包装成一个ServiceException什么的。这种情况下，throw Exception 就成为一个很常见的事件，这时重载fillInStackTrace 是可以有效益的。
但是我看到的大多数情况，大家还是把Exception作为技术上的异常而不是业务上的异常。所以，理论上要用到异常的时候不多。要真是发生了Exception，由于超出预期，反而恰恰需要stack trace。
有种观点认为，业务失败异常流程应该基于Exception控制，在这样的项目里就会看到大量的基于业务定义的Exception类，比如UserNotFoundException，LoginFailException什么的。或者把Service层所有的异常分支都包装成一个ServiceException什么的。这种情况下，throw Exception 就成为一个很常见的事件，这时重载fillInStackTrace 是可以有效益的。
但是我看到的大多数情况，大家还是把Exception作为技术上的异常而不是业务上的异常。所以，理论上要用到异常的时候不多。要真是发生了Exception，由于超出预期，反而恰恰需要stack trace。
喜欢java
重载fillInStackTrace在业务异常中很常见，但是如果一定要说弊端的话，如果想要stack的时候反而没有办法了，屏蔽异常栈主要是为了不执行private native Throwable fillInStackTrace(int dummy);这个方法而提高效率，出于这个目的考虑的话有更好的方案，动态决定需不需要异常栈——新增业务异常增加构造函数，用参数决定是否需要异常栈。调用Throwable的构造函数：
protected Throwable(String message, Throwable cause,
boolean enableSuppression,
boolean writableStackTrace);
参数writableStackTrace直接可以决定需不需要执行fillInStackTrace来提高性能。
protected Throwable(String message, Throwable cause,
boolean enableSuppression,
boolean writableStackTrace);
参数writableStackTrace直接可以决定需不需要执行fillInStackTrace来提高性能。
知乎用户
曾经的码农，现独立投资人
如果楼主做的是业务系统的话，建议避免使用这种做法来提高性能，从其他方面考虑吧。像R大说的，不需要stacktrace信息的时候，可以覆盖这个方法达到提高异常性能的目的。不过，业务系统变化太快，今天不需要异常信息，说不定明天就需要了。我自己就遇见过这样的case。
258
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
