透过JVM看Exception本质

IcyFenix

浏览: 362514 次
性别:
来自: 珠海

最近访客更多访客>>

wszt

shuijieshuijie

dongxxx

端木小学士

博主相关

博客

微博

相册

留言

关于我

文章分类

全部博客 (32)

社区版块

存档分类

JVM 多线程软件测试虚拟机 OOP

引子

        异常能不能作为控制流，这个争论其实已经存在了很长时间，最近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指令中虚拟机可能做的事情（只会做其中一部份啦）：

检查栈顶异常对象类型（只检查是不是null，是否referance类型，是否Throwable的子类一般在类验证阶段的数据流分析中做，或者索性不做靠编译器保证了，编译时写到Code属性的StackMapTable中，在加载时仅做类型验证）
把异常对象的引用出栈
搜索异常表，找到匹配的异常handler
重置PC寄存器状态
清理操作栈
把异常对象的引用入栈
把异常方法的栈帧逐个出栈（这里的栈是VM栈）
残忍地终止掉当前线程。
……

        好吧，我勉强认同虚拟机出现异常时要做的事情挺多的，但这要作为直接证据说明它就理所当然的那么慢有点勉强吧？要不，找个具体实现看一下？
        （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的第一张帖子我投过一次隐藏贴，那是觉得其语言太过偏激了，不想争论，但后面他的另外三张帖子中很多评论都有可取、可想之处，变成隐藏扣分似乎不太应该。

分享到：

JE的水真的太深 | Servlet 3.0 实战：异步 Servlet 与 Comet ...

2011-01-02 20:57
浏览 12687
评论(60)
论坛回复 / 浏览 (60 / 42094)
分类:编程语言
查看更多

40 楼 whaosoft 2011-01-04

这个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未介入的前提下。

不太明白为什么这段代码会节省了75%的时间... 求教

39 楼 sdh5724 2011-01-04

william_ai 写道

在mac下又做了一次测试。下面是源码：

import java.util.ArrayList;
import java.util.Iterator;
public class F{
	public static void main(String[] args){
		ArrayList a0=null;
		ArrayList a1=null;
		long t0=0;
		long t1=0;
		long t2=0;
		long t3=0;
		long l=0;
		int[] t={10,100,1000,10000,100000};
		int sum=0;
		int lt=t.length;
		for(int i=0;i<lt;i++){
			l=t[i];
			sum=0;
			for(int j=0;j<l;j++){
				System.out.print("\b\b\b\b\b\b\b\b\b\b"+j);
				a0=new ArrayList();
				for(int k=0;k<j;k++){
					a0.add(""+k);
				}
				a1=new ArrayList();
				Iterator it=a0.iterator();
				t0=System.nanoTime();
				while(it.hasNext()){
					a1.add(it.next());
				}
				t1=System.nanoTime();
				t2=t1-t0;
				a1=new ArrayList();
				it=a0.iterator();
				t0=System.nanoTime();
				try{
					while(true){
						a1.add(it.next());
					}	
				}catch(Exception e){
					t1=System.nanoTime();
				}
				t3=t1-t0;
				if(t2<t3){
					sum++;
				}
			}
			System.out.println("\b\b\b\b\b\b\b\b\b\bStatics="+sum+"/"+l);
		}
	}
}

下面是结果：

Statics=9/10
Statics=82/100
Statics=628/1000
Statics=2608/10000
Statics=11865/100000

很有意思的结果。在10000次循环的时候，hasNext()方式用时少的test有26％，比Exception的方式少，而且少了很多。在100,000次循环的时候，hasNext()方式用时少的test只有不到12％。
在mac下，如果循环次数少（1000左右）的话，hasNext()方式好些，如果循环次数多（10K以上）的循环，Exception方式好些。

猪头啊，性能测试的时候不要在控制台上输出太多，最好只输出结果。
还有，预热部分代码要先跑一些。（jit的问题）
system.nanoTime 不要这么用，一个一个点的统计，这个函数是系统调用，而且很消耗， sys/usr切换是消耗的。
总之你这个测试不是很准。

为毛你的mac比我的跑的快不少？

38 楼 javacoreSZ 2011-01-04

IcyFenix 写道

看看反应如何，好的话明天再写一篇来小淌一下“C/C++会比Java语言快多少多少倍”这浑水，也是这2天由那几张判断字符串能不能用异常的帖子中看到的观点。

这个最好还是别写，坑太大了。
而且他们性能之间的差距并不是由c++ 或 java语言本身所带来的，而是由于他们的实际编译器/虚拟机在做代码生成的时候，对代码优化的程度所带来的。

所以你要写的话，也是要深入各主流cpp编译器来写，写得不好就口水战了。

37 楼 william_ai 2011-01-04

meiyoudao 写道

云里雾里....... JVM 归根还是C ... 汇编....

机器码。

36 楼 gdpglc 2011-01-04

skzr.org 写道

呵呵，抛个问题给大家：
1 String判断是不是能转换为合法的Integer这么纠结
2 String判断是不是能转换为合法的json是不是也要争论下
3 String判断是不是能转换为合法的xml document是不是也要争论下
4 String判断是不是能转换为合法的your bean是不是更加要纠结下！
。。。
X String判断是不是能转换为合法的Application是不是更加要纠结下！

相信大家思索后各有定论！

引申的很棒。不能用僵化的思维来理解软件的各个方面。拿着死的规则生般硬套，什么都是非对即错。最终会发现，软件中不能付合规则的地方多了，可是却是合理的。达不到这个思维水平，如何在软件设计时选择恰当的解决方案？

对于性能问题，最忌拍脑门。如若没有量化的数字，说性能问题，那就是扯蛋。我遇过几次性能瓶颈的排查，没有一次是能通过看代码找到问题的。我不是说代码对软件性能没影响，只是很多人都在这上想多了。软件中一段，一年只会运行一次的代码(我是指一般的业务逻缉，比如更新个字段、生成个报表什么的...)，只要不是顾意是很难写出性能问题的...

而软件中被频繁执行的代码，才有出现性能问题的可能。

所以，软件要追求的是可读。因为可读，意味着可改，如果真在哪个味预料的位置出现了性能瓶颈，即可重构之...

有人看了我那6行代码，说这样的话：“我只在赶进度时，才用异常做判断”。这想法很有意思，为什么没人思考，我这样用了，但为什么软件没有出问题...

35 楼 lvjinhua 2011-01-03

该用就用。

34 楼 lujiawu12 2011-01-03

楼主分析的很透彻，个人感觉exception在控制程序结构好点，性能没出现瓶颈不在乎那点

33 楼 rmn190 2011-01-03

新的一年里看到分析的这么有深度的帖子，平静地拜读。

32 楼 meiyoudao 2011-01-03

云里雾里....... JVM 归根还是C ... 汇编....

31 楼 william_ai 2011-01-03

在mac下又做了一次测试。下面是源码：

import java.util.ArrayList;
import java.util.Iterator;
public class F{
	public static void main(String[] args){
		ArrayList a0=null;
		ArrayList a1=null;
		long t0=0;
		long t1=0;
		long t2=0;
		long t3=0;
		long l=0;
		int[] t={10,100,1000,10000,100000};
		int sum=0;
		int lt=t.length;
		for(int i=0;i<lt;i++){
			l=t[i];
			sum=0;
			for(int j=0;j<l;j++){
				System.out.print("\b\b\b\b\b\b\b\b\b\b"+j);
				a0=new ArrayList();
				for(int k=0;k<j;k++){
					a0.add(""+k);
				}
				a1=new ArrayList();
				Iterator it=a0.iterator();
				t0=System.nanoTime();
				while(it.hasNext()){
					a1.add(it.next());
				}
				t1=System.nanoTime();
				t2=t1-t0;
				a1=new ArrayList();
				it=a0.iterator();
				t0=System.nanoTime();
				try{
					while(true){
						a1.add(it.next());
					}	
				}catch(Exception e){
					t1=System.nanoTime();
				}
				t3=t1-t0;
				if(t2<t3){
					sum++;
				}
			}
			System.out.println("\b\b\b\b\b\b\b\b\b\bStatics="+sum+"/"+l);
		}
	}
}

下面是结果：

statistics=9/10
statistics=82/100
statistics=628/1000
statistics=2608/10000
statistics=11865/100000

statistics=10/10  
statistics=89/100  
statistics=89/1000  
statistics=115/10000  
statistics=1233/100000

30 楼 gdpglc 2011-01-03

IcyFenix 写道

望有深入解读！

29 楼 peterwei 2011-01-03

agapple 写道

其实LZ可以再往下细扣一下，为啥new Exception会慢，profile一看主要就是慢在一个native方法调用上fillInStackTrace。

该方法的主要作用就是获取当前线程执行栈，用于日志记录和以后分析所用

一般针对业务逻辑，其实可以不太关注具体的线程调用栈，我们大家应该关注的是业务异常message和code

所以我还是比较喜欢用异常来进行逻辑控制和返回，首先代码风格上会比较清晰

可以参考下：复写了RumtimeException的一个native方法，在测试过程中性能几乎就和if..else一样了

public static class ServiceException extends RumtimeException {

@Override
public Throwable fillInStackTrace() {
     return this;
}
}

具体的测试分析，可以看下我同事的测试文档： http://www.blogjava.net/stone2083/archive/2010/07/09/325649.html

+1 我也认为大多数的业务系统：应该关注的是业务异常message和code

28 楼 ZHH2009 2011-01-03

学下牛人们怎么用try catch来控制流程:

这里是Netty3.2的真实例子，
在解析http1.1协议时用到了，见:
org.jboss.netty.handler.codec.replay.ReplayingDecoder类的callDecode方法:

while (cumulation.readable()) {
	...
	try {
		...
	} catch (ReplayError replay) {
		...
	}
}

借用Trustin Lee的话:

引用

throw的是Error，别throw出来Exception，
每次throw出来的都是同一个Error实例。

如果你认为Trustin Lee的话没道理，
亲自去测一下Netty3.2的http1.1实现是否真的慢。

我是认为Netty的http1.1协议解析做得比Tomcat、Jetty都来得简单明了，程序结构清晰。

27 楼 agapple 2011-01-03

yangyi 写道

agapple 写道

public static class ServiceException extends RumtimeException {

@Override
public Throwable fillInStackTrace() {
     return this;
}
}

具体的测试分析，可以看下我同事的测试文档： http://www.blogjava.net/stone2083/archive/2010/07/09/325649.html

撇开性能不谈，异常机制当然是有优点，也有缺点的。从编码的角度，异常机制可以产生多种不同的返回值。其产生的负效应便是，函数的职责不单一，函数调用和被调用之间除了传参和返回值又产生了基于异常的耦合关系。
"Never say never" “中庸之道” 告诉我们，任何事情都是有它适用的一面的，关键要找到适用的场合，不能生搬硬套，也很难给出什么指导原则。如果再多举一个例子就是goto语句的使用。
鉴于开发人员水平参差不齐，个人建议有争议的东西尽量少用，除非没有替代办法。

只能说不同的应用场景适不适用异常了，针对异常网上也讨论了很多次
但我的看法就是明确自己公司或者部门的业务，比如就是一个创建会员的方法，可能会有同名，地址为空等等一些列的业务异常，这类用业务异常代码结构上会比较清晰。同样针对于一个util方法，判断是否是一个整数，返回异常就意义不大，这时明确方法签名就很有意义。

针对开发人员水平参差不齐，有争议的问题提前摆上桌面说，只要达成了一致的结论，该咋干就咋干。现在我的想法也不要求所有开发都能认同异常的使用，但至少在和自己一起工作的小部门同事观点至少是一致的就可以了。

26 楼 yangyi 2011-01-03

IcyFenix 写道

我的用的是jdk 6u21_x64,在我机器上默认是-server模式，使用了-Client和-Xint测试过，没有太大差距。你测试到的2129125ns是不是被JIT优化了？加个-Xint试试看？

得不出这样的数据，即使加上-Xint也一样。从您的分析看，肯定是要比if else慢的。
至少在我这里，抛出异常的开销并不大，您给的文章链接也有同样的结论：

引用

The most costly part of exception processing on the JVM is creating the exception, not throwing it. Exception creation involves a native method named Throwable.fillInStackTrace, which looks down the stack (before the actual throw) and puts a whole backtrace into the exception object. It’s great for debugging, but a terrible waste if all you want to do is pop a frame or two.

文中给出的预先建立Exception，抛出多次的方法，就是我们之前讨论的内容，虽然有点bt，但是基本我没有异议。
再讨论下去恐怕要跑题了，您的分析当然还是有价值的，只是不太适合用来描述为什么建立-抛出-接受异常慢这个话题。
如有错误请指教。

D:\>java -version
java version "1.6.0_23"
Java(TM) SE Runtime Environment (build 1.6.0_23-b05)
Java HotSpot(TM) Client VM (build 19.0-b09, mixed mode, sharing)

25 楼 william_ai 2011-01-03

skzr.org 写道

异常相对于加减乘除和方法调用确实是重量级，这一点毋庸置疑。

命题有了，论据呢？

24 楼 yangyi 2011-01-03

agapple 写道

public static class ServiceException extends RumtimeException {

@Override
public Throwable fillInStackTrace() {
     return this;
}
}

具体的测试分析，可以看下我同事的测试文档： http://www.blogjava.net/stone2083/archive/2010/07/09/325649.html

23 楼 IcyFenix 2011-01-03

yangyi 写道

lz, 感觉你的测试用例有点问题，我修改了一下：

    public void catchException() {  
        long l = System.nanoTime();
        Exception e = new Exception();
        for (int i = 0; i < testTimes; i++) {  
            try {  
            	throw e;
            } catch (Exception e1) {  
            }  
        }  
        System.out.println("建立、抛出并接住异常对象：" + (System.nanoTime() - l));  
    }

这是我改正后得到的结果：
建立对象：865088
建立异常对象：12278747
建立、抛出并接住异常对象：2129125

看得出逻辑部分速度还不算慢，最慢的是建立异常对象的时间。
通过比较，和普通对象相比，多出了一个fillInStackTrace的过程，看来这个地方是性能瓶颈

通过修改方法:

    public void newException() {  
        Exception e = new Exception(); 
        long l = System.nanoTime();  
        for (int i = 0; i < testTimes; i++) {
        	e.fillInStackTrace();
        }  
        System.out.println("建立异常对象：" + (System.nanoTime() - l));  
    }

可以验证我们的结论。fillInStackTrace是一个native方法，javadoc:
Fills in the execution stack trace. This method records within this Throwable object information about the current state of the stack frames for the current thread.
显然需要和当前虚拟机执行线程的执行环境交互，导致了性能较差

fillInStackTrace的问题，看3楼RednaxelaFX的JustForDemoException，以及http://blogs.sun.com/jrose/entry/longjumps_considered_inexpensive。

我按照你的建议，把建立异常部分从时间统计中去掉，加了一个TestCase，结果如下：上面的是去掉异常建立时间的，下面是原来的例子。

引用

抛出并接住异常对象：42489313
抛出并接住异常对象：51125640

我的用的是jdk 6u21_x64,在我机器上默认是-server模式，使用了-Client和-Xint测试过，没有太大差距。你测试到的2129125ns是不是被JIT优化了？加个-Xint试试看？

22 楼 skzr.org 2011-01-03

除开第一点，相对于后面的，如果gdpglc采用异常，没有这么多争论了

举一反三，gdpglc先要用String转json和xml或者其他的为例子，最后引出Integer的验证讨论就。。。（后面的不说了）

异常相对于加减乘除和方法调用确实是重量级，这一点毋庸置疑。

21 楼 skzr.org 2011-01-03

发表评论

您还没有登录,请您登录后再发表评论

最近访客更多访客>>

博主相关

文章分类

社区版块

存档分类

最新评论