Java异常的内部结构

openjdk中的原生方法fillInStackTrace调用JVM\u fillInStackTrace（env，throwable）是否未提供此方法的源

throw是一条jvm指令。类似于在组装中跳转的东西 Jvm本身是本机代码，所以Jvm中实现的任何东西都是本机代码。throw也是本机代码吗？ 换句话说，对fillInStackTrace的内在调用不会产生通常JNI调用的成本？（而成本是填充堆栈跟踪）

是否保证缓存异常的try-catch有效？如何填写异常表。对于同一异常，将有多个匹配的catch块

它们在web应用程序（或任何具有类似延迟的应用程序）中真的很昂贵吗？ 假设web服务get/employee/{invalid_id}抛出 javax.ws.rs NotFoundException，而不是使用if/else返回404响应。

---

考虑到http请求、响应和对象Json序列化/反序列化的成本，异常的成本并不高。

创建异常对象时，需要捕获stacktrace。JVM通过遍历java堆栈来查找调用链中指向这一点的所有方法来实现这一点

fillInStackTrace方法的成本与调用该方法时java堆栈的深度成正比。与此成本相比，JNI的内部开销较低

异常捕获独立于使用缓存的异常或新创建的异常。当执行athrow字节码时，JVM遍历java堆栈并寻找一个方法，该方法可以具有一个能够处理当前异常类型的catch块

异常用于异常事件，不应用于控制流。

实际上，异常用于非本地控制流。例如，jruby和scala（可能还有其他基于JVM的语言）使用它们来打断函数循环体或从闭包返回外部函数

但它们使用优化的异常，不填充堆栈跟踪和/或使用预先分配的异常，如果JVM可以内联这些异常，则将这些异常优化为goto。但这些都是特殊情况，没有其他选择

在一般情况下，异常仅用于表示异常行为。

---

异常仍然意味着预期的但不常见的情况，在这种情况下，可以认为是一个缓慢的代码路径，在这种情况下，异常恢复的成本是如此之高，以至于与之相比，生成异常的成本可以忽略不计。各种与网络相关的异常就是一个例子，因为网络从来都不是100%可靠的，但错误也不会主导大部分操作。

一般来说，填充堆栈跟踪相对昂贵。对于在实践中应该很少出现的情况，这可能是可以容忍的，但是简单的

if

/

else

逻辑在可用的情况下会快得多。IIRC，这大约是抛出新异常成本的95%。“它们真的很昂贵吗”-没有通用的答案，对您的用例进行基准测试。hotspot没有优化某些异常吗？

try{Integer.parseInt（“one”）；}catch（NumberFormatException e）{}

变体？