|
锁定老帖子 主题：透过JVM看Exception本质
该帖已经被评为良好帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2011-01-02
最后修改：2011-01-02
引子
异常能不能作为控制流，这个争论其实已经存在了很长时间，最近gdpglc同学发的一连四张《验证String是不是整数，用异常作判断怎么了!》的帖子（前三张已经被投为隐藏帖，要看的话可以从第四张进去）令这个争端又一次成为JE主版的话题。 gdpglc同学的语气比较激烈，但发表自己观点是值得肯定的，何况异常可以作为控制流的观点，JavaEye创始人肉饼同学在2003年的时候也提出过，并且也引发了一些讨论，就在这帖子的2楼：http://www.iteye.com/topic/2038。无论是03年还是今天，反方的主流意见都无外乎两点：一是圣经上说不行，列举《Effective Java》等例子。二是从性能上说不行，列举了测试用例，譬如http://www.iteye.com/topic/856221这里，我在二楼发的一个测试用例，有兴趣的话可以看一下，后面被gdpglc吐槽了十几楼那些就不要看了T_T 尽信书不如无书，第一点意见不值得讨论。第二点意见说使用异常很慢，并且测试数据说明了确实很慢，那我们不妨来看看为何使用异常会慢，从深一些的层次来看看异常到底是个神马东西。 异常慢在哪里？ 说用异常慢，首先来看看异常慢在哪里？有多慢？下面的测试用例简单的测试了建立对象、建立异常对象、抛出并接住异常对象三者的耗时对比： package org.fenixsoft.exception;
public class ExceptionTest {
private int testTimes;
public ExceptionTest(int testTimes) {
this.testTimes = testTimes;
}
public void newObject() {
long l = System.nanoTime();
for (int i = 0; i < testTimes; i++) {
new Object();
}
System.out.println("建立对象：" + (System.nanoTime() - l));
}
public void newException() {
long l = System.nanoTime();
for (int i = 0; i < testTimes; i++) {
new Exception();
}
System.out.println("建立异常对象：" + (System.nanoTime() - l));
}
public void catchException() {
long l = System.nanoTime();
for (int i = 0; i < testTimes; i++) {
try {
throw new Exception();
} catch (Exception e) {
}
}
System.out.println("建立、抛出并接住异常对象：" + (System.nanoTime() - l));
}
public static void main(String[] args) {
ExceptionTest test = new ExceptionTest(10000);
test.newObject();
test.newException();
test.catchException();
}
}运行结果：
建立对象：575817 建立异常对象：9589080 建立、抛出并接住异常对象：47394475建立一个异常对象，是建立一个普通Object耗时的约20倍（实际上差距会比这个数字更大一些，因为循环也占用了时间，追求精确的读者可以再测一下空循环的耗时然后在对比前减掉这部分），而抛出、接住一个异常对象，所花费时间大约是建立异常对象的4倍。那我们来看看占用时间的“大头”：抛出、接住异常，系统到底做了什么事情？ 当异常发生的那一刹那 注： RednaxelaFX：用字节码来解释性能问题很抱歉也是比较不靠谱的。字节码用于解释“语义问题”很靠谱，但看字节码是看不出性能问题的——超过它的抽象层次了 IcyFenix：同意RednaxelaFX的观点，但本节中的字节码分解本就不涉及性能，仅想表达“当异常发生那一刹那”时会发生什么事情（准确的说，还要限定为是解释方式执行），这里提及的20%、80%时间是基于前一点测试的结果。 要知道当异常发生的那一刹那系统做了什么事情，先把catchException()方法中循环和时间统计的代码去掉，使得代码变得纯粹一些： public void catchException() {
try {
throw new Exception();
} catch (Exception e) {
}
}然后使用javap -verbose命令输出它的字节码，结果如下：
public void catchException();
Code:
Stack=2, Locals=2, Args_size=1
0: new #58; //class java/lang/Exception
3: dup
4: invokespecial #60; //Method java/lang/Exception."<init>":()V
7: athrow
8: astore_1
9: return
Exception table:
from to target type
0 8 8 Class java/lang/Exception 解释一下这段字节码的运作过程，如果平时看字节码比较多的同学可以直接略过这段。偏移地址为0的new指令首先会在常量池找到第58项常量，此常量现在为CONSTANT_Class_info型的符号引用，类解析阶段被翻译为java.lang.Exception类的直接引用，接着虚拟机会在Java堆中开辟相应大小的实例空间，并将此空间的引用压入操作栈的栈顶。偏移为3的dup指令就简单的把栈顶的值复制了一份，重新压入栈顶，这时候操作栈中有2份刚刚new出来的exception对象的引用。偏移为4的invokespecial指令将第一个exception对象引用出栈，以它为接收者调用了Excepiton类的实例构造器，这句执行完后栈顶还剩下一份exception对象的引用。写了那么多，说白了这3条字节码就是干了“new Exception()”这句Java代码应该做的事情，和创建任何一个Java对象没有任何区别。这一部分耗费的时间在上一节中分析过，创建一个异常对象只占创建、抛出并接住异常的20%时间。
接着是占用80%时间高潮部分，偏移为7的athrow指令，这个指令运作过程大致是首先检查操作栈顶，这时栈顶必须存在一个reference类型的值，并且是java.lang.Throwable的子类（虚拟机规范中要求如果遇到null则当作NPE异常使用），然后暂时先把这个引用出栈，接着搜索本方法的异常表（异常表是什么等写完这段再说），找一下本方法中是否有能处理这个异常的handler，如果能找到合适的handler就会重新初始化PC寄存器指针指向此异常handler的第一个指令的偏移地址。接着把当前栈帧的操作栈清空，再把刚刚出栈的引用重新入栈。如果在当前方法中很悲剧的找不到handler，那只好把当前方法的栈帧出栈（这个栈是VM栈，不要和前面的操作栈搞混了，栈帧出栈就意味着当前方法退出），这个方法的调用者的栈帧就自然在这条线程VM栈的栈顶了，然后再对这个新的当前方法再做一次刚才做过的异常handler搜索，如果还是找不到，继续把这个栈帧踢掉，这样一直到找，要么找到一个能使用的handler，转到这个handler的第一条指令开始继续执行，要么把VM栈的栈帧抛光了都没有找到期望的handler，这样的话这条线程就只好被迫终止、退出了。 刚刚说的异常表，在运行期一般会实现在栈帧当中。在编译器静态角度看，就是上面直接码中看到的这串内容： Exception table:
from to target type
0 8 8 Class java/lang/Exception 上面的异常表只有一个handler记录，它指明了从偏移地址0开始（包含0），到偏移地址8结束（不包含8），如果出现了java.lang.Exception类型的异常，那么就把PC寄存器指针转到8开始继续执行。顺便说一下，对于Java语言中的关键字catch和finally，虚拟机中并没有特殊的字节码指令去支持它们，都是通过编译器生成字节码片段以及不同的异常处理器来实现。
字节码指令还剩下2句，把它们说完。偏移地址为8的astore_1指令，作用是把栈顶的值放到第一个Slot的局部变量表中，刚才说过如果出现异常后，虚拟机找到了handler，会把那个出栈的异常引用重新入栈。因此这句astore_1实现的目的就是让catch块中的代码能访问到“catch (Exception e)”所定义的那个“e”，又顺便提一句，局部变量表从0开始，第0个Slot放的是方法接收者的引用，也就是使用this关键能访问的那个对象。最后的return指令就不必多讲了，是void方法的返回指令，因为我们的catch块里面没有内容，所以立刻就return了。 到此为止，这几句字节码讲完了，我们总结一下athrow指令中虚拟机可能做的事情（只会做其中一部份啦）：
（PS：虚拟机：囧……这人好麻烦……鸭梨很大……） 透过虚拟机实现看athrow指令 下面的讲解基于OpenJDK中HotSpot虚拟机的源代码。有兴趣的话可以去OpenJDK网站（http://download.java.net/openjdk/jdk7/）下载一份，没有兴趣可以略过这节。 被JIT编译之后，异常处理变成神马样子我们就不管了，只看一看虚拟机解释执行时处理异常是如何实现的。因为三大商用虚拟机只有Sun一系的（Sun/Oracle、HP、SAP等）以OpenJDK的形式开源了，这里所指的所指的实现也就仅是HotSpot VM，后面就不再严格区分了。 注：此处有个根本性的错误，见2楼RednaxelaFX的指正 RednaxelaFX：HotSpot并没有使用bytecodeInterpreter.cpp里实现的解释器；在OpenJDK里有一套叫Zero/Shark的解释器/JIT编译器，其中Zero的部分用了这里提到的解释器，但它主要是在HotSpot还没良好移植的平台上使用的。 虚拟机字节码解释器的关键代码在hotspot\src\share\vm\interpreter\bytecodeInterpreter.cpp之中，它使用了while(1)的方式循环swith PC寄存器所指向的opcode指令，处理athrow指令的case中是这样写的： CASE(_athrow): {
oop except_oop = STACK_OBJECT(-1);
CHECK_NULL(except_oop);
// set pending_exception so we use common code
THREAD->set_pending_exception(except_oop, NULL, 0);
goto handle_exception;
} 第一句提取操作栈中引用的异常对象，第二句检查异常是否为空，虚拟机规范中要求的为null就当NPE异常，就是这句实现的：
#define CHECK_NULL(obj_)
if ((obj_) == NULL) {
VM_JAVA_ERROR(vmSymbols::java_lang_NullPointerException(), "");
}
VERIFY_OOP(obj_) 注释中说可以使用“common code”是指handle_return中的代码，每条opcode处理完都会转到这段代码。因为异常不一定来自athrow指令，也就是不一定来自于用户程序直接抛出，虚拟机运作期间也会产生异常，如被0除、空指针，严重一点的OOM神马的。所以出现异常后的方法退出动作在通用的handle_return里面根据pending_exception进行处理，代码太多就不贴了。前面几句没有太特别的动作，看来athrow指令的关键实现还是在handle_exception这节，看看它的代码（为了逻辑清晰，我删除了不必要的代码，譬如支持跟踪调试的语句）：
handle_exception: {
HandleMarkCleaner __hmc(THREAD);
Handle except_oop(THREAD, THREAD->pending_exception());
// Prevent any subsequent HandleMarkCleaner in the VM
// from freeing the except_oop handle.
HandleMark __hm(THREAD);
THREAD->clear_pending_exception();
assert(except_oop(), "No exception to process");
intptr_t continuation_bci;
// expression stack is emptied
topOfStack = istate->stack_base() - Interpreter::stackElementWords;
CALL_VM(continuation_bci = (intptr_t)InterpreterRuntime::exception_handler_for_exception(THREAD, except_oop()),
handle_exception);
except_oop = (oop) THREAD->vm_result();
THREAD->set_vm_result(NULL);
if (continuation_bci >= 0) {
// Place exception on top of stack
SET_STACK_OBJECT(except_oop(), 0);
MORE_STACK(1);
pc = METHOD->code_base() + continuation_bci;
// for AbortVMOnException flag
NOT_PRODUCT(Exceptions::debug_check_abort(except_oop));
goto run;
}
// for AbortVMOnException flag
NOT_PRODUCT(Exceptions::debug_check_abort(except_oop));
// No handler in this activation, unwind and try again
THREAD->set_pending_exception(except_oop(), NULL, 0);
goto handle_return;
}
只看这段代码的关键部分，CALL_VM那句是查找异常表，所执行的InterpreterRuntime::exception_handler_for_exception在同目录下的interpreterRuntime.cpp中，查找的具体过程有点复杂，只看程序的主体脉络，这里的代码就不再牵扯进来了。如果找到，也就是if (continuation_bci >= 0)成立的话，（bci的意思是Bytecode Index，字节码索引），把异常对象重新入栈（SET_STACK_OBJECT(except_oop(), 0)这句），并且重置PC指针为异常handler的起始位置（pc = METHOD->code_base() + continuation_bci这句），然后跳转到run处开始下一轮的循环switch过程。查询异常表没有找到合适的handler，那重新设置上pending_exception，因为前面的时候使用clear_pending_exception()清除掉了。在handle_return中会根据这个标志来决定方法是否出现异常，要不要退出。虚拟机规范中要求的athrow指令的动作这里就写完了，HotSpot VM我们写不出来，看一下还是可以的嘛。
观点与小结 这篇文章的主要目的是探讨虚拟机中底层是如何看待“异常”的，并不打算去争论“异常”能不能作为控制流。对事物运作本质了解越深，就越容易根据当前场景衡量代码清晰、实现简单、性能高低、易于扩展等各方面的因素。“能不能”、“会不会”、“是否应该”这类的疑惑就会相对更少一些，也不需要靠“论”去证明了。 最后稍微说一下引子中提到的那件事情，用异常判断整数能不能用，我的观点还是http://www.iteye.com/topic/856221中二楼的第一句话“这个方法如果调用次数不多，怎么写都无所谓，如果次数多还是不要这样用的好”，请gdpglc同学不同意也不要在这个帖子里面吐槽，多多包涵。gdpglc的第一张帖子我投过一次隐藏贴，那是觉得其语言太过偏激了，不想争论，但后面他的另外三张帖子中很多评论都有可取、可想之处，变成隐藏扣分似乎不太应该。 声明：ITeye文章版权属于作者，受法律保护。没有作者书面许可不得转载。
推荐链接
|
| 返回顶楼 | |
|
发表时间：2011-01-02
看看反应如何，好的话明天再写一篇来小淌一下“C/C++会比Java语言快多少多少倍”这浑水，也是这2天由那几张判断字符串能不能用异常的帖子中看到的观点。
|
| 返回顶楼 | |
|
发表时间：2011-01-02
最后修改：2011-01-02
那个…
楼主对OpenJDK的代码熟悉的话，会知道其实我们平时用的（x86或SPARC上的）HotSpot并没有使用bytecodeInterpreter.cpp里实现的解释器；在OpenJDK里有一套叫Zero/Shark的解释器/JIT编译器，其中Zero的部分用了这里提到的解释器，但它主要是在HotSpot还没良好移植的平台上使用的。 简单介绍一下背景： HotSpot的源码里，平台中立的部分，有两套解释器实现：一个叫模板解释器（template interpreter），平时用的就是这个；另一个叫“C++解释器”，也就是楼主举例用的。平时用的是前者而不是后者主要是历史原因。 Anyway，用“C++解释器”来讲解概念也不是不行，不过它跟常见的一些性能测试的例子没啥关系。另外用字节码来解释性能问题很抱歉也是比较不靠谱的。字节码用于解释“语义问题”很靠谱，但看字节码是看不出性能问题的——超过它的抽象层次了。 楼主应该加一组例子，用一个自定义的异常类型： public class JustForDemoException extends Exception {
@Override
public Throwable fillInStackTrace() {
return this;
}
}
用这个异常类来跑类似的测试看看，相信能发现些别的有趣的结论 ^_^ 顺带简单说点别的： HotSpot的解释器，在server模式上默认会开启profiling而在client模式默认不开。该解释器的profiler会记录某方法里有没有发生过某些类型的异常，或者发生异常的比例如何。这些profile信息接下来会交由JIT编译器作为优化的依据。如果一段代码虽然带有try/catch，但运行过程中实际上一直没发生过异常，那么JIT编译器会有偏向的做优化，使得不发生异常的情况是零开销的，而发生一次异常则可能触发一个很慢的过程——逆向优化（deoptimization），可能因此需要抛弃掉之前编译过的一个方法的代码让它退回到解释器里执行。这些动态特性使得在现代高性能JVM上用很简单的测试代码根本无法反映出我们平时真正写的Java程序在运行时的情况——除非谁的工作内容本身就只是写microbenchmark。另外还有一些类型的异常默认是使用隐式处理的，例如NullPointerException、除以零的ArithmeticException之类。 有兴趣知道更多细节的话欢迎讨论。 就像John Rose，Sun开发JVM的元老级工程师所说，“抛个异常什么的可以很廉价”。当然这是有具体场景在里面的咯。楼主加前面提到的那组测试之前先别读这个链接的文章，会剧透 >_< IcyFenix 写道 bci的意思是Bytecode Instrumentation，字节码指令
首先bytecode instrumentation的意思是字节码测量，意思是在已有代码的基础上插入一些用于测量的字节码来达到获取某些数据的目的。 其次，在解释器里，这里的bci不是bytecode instrumentation，而是bytecode index，字节码索引或者说偏移量的意思。在HotSpot的解释器里除了bci这个缩写很常见之外，还有个类似的，叫bcp，是bytecode pointer，这个基本上可以看作是bci + 方法的字节码在内存中的起始地址（基地址）。 IcyFenix 写道 我们总结一下athrow指令中虚拟机可能做的事情（只会做其中一部份啦）：
是不是Throwable子类这个是在类加载的字节码校验阶段会做一次。对版本号为50.0或更高的Class文件（也就是Java SE 6或更高版本的）做的是类型检查（type checking verification），若失败或者是对50.0以下的版本号的Class文件则做类型推导（type inference verification）。后者是用数据流分析做的，而前者就是为了降低校验成本而做的改进，不需要繁琐的数据流分析算法。 |
| 返回顶楼 | |
|
发表时间：2011-01-02
最后修改：2011-01-02
2011年一开始就不消停。
|
| 返回顶楼 | |
|
发表时间：2011-01-02
RednaxelaFX 写道 那个…
谢谢sajia同学不吝斧正，解释器代码和bci的问题，属于根本性质的错误，为了避免误导别人，已经通过红色字体修正到主贴了。再次感谢！ 解释器的问题，光看代码不debug的问题，这没啥可说的，我得多学习= =# bci那个……我居然一直都以为是“Bytecode Instrumentation”，包括大脑中自动把“Instrumentation”当成“Instruction”来译，囧…… 至于“或者索性不做靠编译器保证了”那个应该属于理解性的问题，靠编译器保证就是java se 6新的类型验证，既然可能产生误解，我在后面补充了一句红字。 你那个例子我待会回帖再补充一下，我也有个自定义异常好玩的问题，待会一起写一些。 |
| 返回顶楼 | |
|
发表时间：2011-01-02
2012年不远了，大家安了安了
|
| 返回顶楼 | |
|
发表时间：2011-01-02
最后修改：2011-01-02
LZ这样熟悉jvm的底层机制很是佩服。只是，这贴实在太专业，我的确云里雾里。估计没有相关知识的人也是够呛。不知LZ从事哪个行业，为何需要对JVM有如此的研究？的确很好奇，开发什么软件，需要这么深入jvm? 楼主不想回答，我也理解。
|
| 返回顶楼 | |
|
发表时间：2011-01-02
RednaxelaFX 写道 楼主应该加一组例子，用一个自定义的异常类型： public class JustForDemoException extends Exception {
@Override
public Throwable fillInStackTrace() {
return this;
}
}
这个Test Case应该能说明问题了: package org.fenixsoft.exception;
public class ExceptionTest2 {
public static class JustForDemoException extends Exception {
@Override
public Throwable fillInStackTrace() {
return this;
}
}
private Exception exception;
public void setException(Exception exception) {
this.exception = exception;
}
public void method1() throws Exception {
method2();
}
public void method2() throws Exception {
method3();
}
public void method3() throws Exception {
method4();
}
public void method4() throws Exception {
throw exception;
}
public static void main(String[] args) {
ExceptionTest2 test = new ExceptionTest2();
try {
test.method1();
} catch (Exception e) {
e.printStackTrace();
}
test.setException(new JustForDemoException());
try {
test.method1();
} catch (Exception e) {
e.printStackTrace();
}
test.setException(new Exception());
try {
test.method1();
} catch (Exception e) {
e.printStackTrace();
}
}
}
上面的testcase是描述使用上的影响，结果不贴了。 关于性能方面，比以前new Exception()节省了75%的时间，只测试了调用栈很短的情况，调用栈更长的话节省时间会更多。 在调用栈不是太长的时候，主要耗时集中在athrow指令上，也就是创建异常不算太慢，抛出异常比较慢（顶楼那个20%、80%的时间），基于这点就不补充到顶楼去了。当然这些都是基于JIT未介入的前提下。 另外，我也发一个“有趣”的自定义异常案例： public static class I_AM_NULL_POINT_Exception extends RuntimeException {
@Override
public String toString() {
return super.getMessage();
}
}
在JDK1.6之前，接住这个异常会，很容易会搞出一个真的“java.lang.NullPointerException”，测试用例我也写好了： public class ExceptionTest3 {
public static class I_AM_NULL_POINT_Exception extends RuntimeException {
@Override
public String toString() {
return super.getMessage();
}
}
public static void main(String[] args) {
try {
throw new I_AM_NULL_POINT_Exception();
} catch (Exception e) {
e.printStackTrace();
}
}
} 输出如下（用1.4、1.5跑，1.6修正了）：
Exception in thread "main" java.lang.NullPointerException 输出结果我只写了头一行，想不明白的同学，运行一下看看堆栈就清楚这个是神马把戏了。如果有不运行光看代码就发现问题的同学可以回个贴，没奖品，不过说明你对JDK的API还是挺了解的。 |
| 返回顶楼 | |
|
发表时间：2011-01-02
gdpglc 写道 LZ这样熟悉jvm的底层机制很是佩服。只是，这贴实在太专业，我的确云里雾里。估计没有相关知识的人也是够呛。不知LZ从事哪个行业，为何需要对JVM有如此的研究？的确很好奇，开发什么软件，需要这么深入jvm? 楼主不想回答，我也理解。
做大型ERP平台的，3楼住着RednaxelaFX，“专业”这2字我表示鸭梨很大。 |
| 返回顶楼 | |
|
发表时间：2011-01-03
看到高手了，这下应该平静了。。。
报这个“Exception in thread "main" java.lang.NullPointerException” 难道是声明异常的时候没有有参的构造方法，一般有参和无参的都重写了吧 所以即使捕捉到了异常也打印不出来啥东西 |
| 返回顶楼 | |
