通过JVM看Exception本质(转载)

透过JVM看Exception本质(转载)

转载自 ---- http://icyfenix.iteye.com/blog/857722

?

引子

??????? 异常能不能作为控制流，这个争论其实已经存在了很长时间，最近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
??????? 尽信书不如无书，第一点意见不值得讨论。第二点意见说使用异常很慢，并且测试数据说明了确实很慢，那我们不妨来看看为何使用异常会慢，从深一些的层次来看看异常到底是个神马东西。

异常慢在哪里？

??????? 说用异常慢，首先来看看异常慢在哪里？有多慢？下面的测试用例简单的测试了建立对象、建立异常对象、抛出并接住异常对象三者的耗时对比：

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的第一张帖子我投过一次隐藏贴，那是觉得其语言太过偏激了，不想争论，但后面他的另外三张帖子中很多评论都有可取、可想之处，变成隐藏扣分似乎不太应该。