在这个专栏的第一期，我们讨论了抛出异常的开销。这个月，我们换一个角度再来看这个主题 —— JVM 如何处理所抛出的异常 —— 并且我们要考虑，最理想的异常编码应该看成是早期的优化还是最优方法？
编码的艰难决择：应该这样做还是那样做？
性能讨论组中充斥着类似于这样的问题“我应该像大多数人那样编写代码，还是为了得到更好的性能那样编写代码？”一般专家会建议应该避免早期的优化，并且直到性能测试显示需要优化的时候才使用最优方法，但实际情况是我们每写一行代码都在做出会影响到性能的决定。
JavaRanch 上的一项讨论调查了确保类型安全的两种选择，一种是抛出异常，另一种是用 instanceof，并提出了“哪种方法更好”的问题。清单 1 和 2 显示了这两种方法。
清单 1. 使用 instanceof 来分支
Listing 1: using instanceof to branch
for (int i = 0; i < max; i++)
{
Object obj = myVector.elementAt(i);
if (obj instanceof MySpecialClass)
{
// do this
}
}
清单 2. 抛出异常来分支
for (int i = 0; i < max; i++) {
try {
MySpecialClass myClass = (MySpecialClass)myVector.elementAt(i);
// do this
} catch (ClassCastException cce) {
continue; // for loop
}
}
提这种问题的危险之一是，当您想把问题浓缩成一个简单例子时可能会失去很多上下文。没有充分的上下文通常会把讨论弄得长而混乱，因为每一个阅读了问题的回答者都会用他们自己的上下文来联系问题。所有这种额外的上下文都会增添含义，这会把我们从问题的出发点转移出来。头脑里有了这些东西之后，就让我们来看能否从这一思路中找到的消息线索中筛选出某些真理来。
异常的特征
提起异常大多数开发者首先要说的就是它们很昂贵。假如您继续追问为什么它们很昂贵，最普遍的答案是我们需要捕捉异常堆栈的当前状态。尽管这是开销的很大一部分，但通过列出异常的一些特征，我们可以知道这只是故事的开始。下面是异常的一些特征：
☆ 可以被抛出。
☆ 可以被捕捉。
☆ 可以被程序化地创建。
☆ 可以被 JVM 创建。
☆ 被表示为第一级对象。
☆ 继续的深度从 3 开始。
☆ 由 String（和来自 1.4 的 StackTraceElements）组成。
☆ 依靠本机方法 fillInStackTrace()。
异常与其他对象的主要区别是异常可以被抛出和捕捉。让我们从调查当异常被抛出时所触发的事件过程来开始我们的研究。
处理异常的开销
为了抛出异常，JVM 发出 athrow 字节码指令。athrow 指令引起 JVM 将异常对象弹出执行堆栈。然后 JVM 搜索当前执行堆栈帧来寻找第一个 catch 子句，这个子句可以处理该类的一个异常或者其超类的一个异常。假如在当前的堆栈帧里没有找到 catch block，那么当前堆栈帧就被释放，异常在下一个堆栈帧的上下文中被重新抛出，如此这般，直到找到包含匹配的 catch 子句的堆栈帧，或者是到了执行堆栈的底部。最后，假如没找到适当的 catch 块，所有的堆栈帧都会被释放，线程在 ThreadGroup 对象有了处理异常的机会后被终止（参考 ThreadGroup.uncaughtException）。假如找到了适当的 catch 块，程序计数器会重置到那一块代码的第一行。
从这个描述中我们可以了解到处理一个抛出的异常是一个非常昂贵的主张。再看一看上面的异常特征清单。注重到除了 JVM 可以“本能地”创建一个异常外，其余剩下的开销与在任何其他第一级对象的生命周期中所引起的开销没有什么区别。
