透过JVM看Exception本质

这个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%的时间... 求教

System.out.print("\b\b\b\b\b\b\b\b\b\b"+j);

这个的原因：
一是跑100000次的时候，时间比较久，看这个空白的屏幕太无聊了。O(∩_∩)O哈！
二是它没有包含在两次nanoTime的调用中间。

System.out.println("\b\b\b\b\b\b\b\b\b\bStatics="+sum+"/"+l);

这个一共执行了5次。

System.nanoTime();

这个的调用确实是比较耗时的（500ns左右）。
对于这个测试而言，都是用的java语言，相同的jdk，相同的jre，相同的vm参数。两种方式都用的是同一个方法，这样做是比较公平的事情。不公平的就是一个在前，一个在后了（调换位置后的测试结果一样）。
也是因为这一点，这个测试的结果只做了量上的比较。没有打印出具体的时间。
这样可以看出数量上的比例。
总时间的的比较测试，以后补上（谢谢sdh5724的提醒）。

这个测试在两台机器上做过测试。前一篇的测试里有。

Statics=6005/10000（在mac的机器上跑的结果是2608／10000）

不是机器配置的问题，前一篇测试的机器的配置比mac好很多，测试结果却没有mac下的好。
找了台稍微好点的机器，配置：44CPU（双核1.6G），264G内存

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

/opt/java1.5/bin/javac F.java
/opt/java1.5/bin/java -server -Xms512m -Xmx512m F

看到这个帖子感到压力很大，这是为什么呢

有人研究机制
有人研究实现
有人研究测试
你只看帖子！

哈哈

无聊的争论，我赞成IcyFenix的说法。即什么时候用什么方法。这个没有固定的界定。
用异常，思路简单明了，代码简单，不管什么样的虚拟机效率都底下，适合初学者。
自己写代码判断，思路也不复杂，代码多一点，效率很高（写得很烂的除外）。适合有一定开发水平的人员。
    其实，效率的提升是需要多方面的。你仅仅一个字符串是不是数字的判断写得再快，但是程序的整个时序中有很多奇慢的代码。结果也是不言而喻的。
    所以，我认为，与其把时间花在单段代码效率的提升上，还不如把时间用在整体的优化上。

愚见，请各位指教！

但是，如果是讨论基础，那就跟"花在单段代码效率的提升上" 不太一样，你讨论完了，甚至测试出结论了，然后下次直接套用，或者说avoid某种错误，那是很有意义的。

100,000的测试结果出来了。

statistics=10/10
statistics=92/100
statistics=99/1000
statistics=119/10000
statistics=1233/100000

Statics是静力学，statistics是统计。之前的有误，希望谅解。

不想打酱油的被打酱油- -

小白提问：需要看懂javap -verbose命令输出它的字节码
要看哪方面东西呀

呵呵，自从sajia同学带头发了一篇又一篇包含字节码的帖子以后，许多同学在看不懂的情况下怒了，也开始学习底层。本来大部分同学好好的做着应用开发，倒也相安无事。
我预计接下来这样的人会越来越多。标准配置如下：
vm spec+Java Lanaguage Specicification(jls)
hotspot源码(用于粘帖cpp源码）

要任何问题，首先都得贴上vm规范和语言规范里的相关定义，以及生成的字节码和hotspot的cpp源码。如果还不够，其它同学会补充其它jvm实现的源码甚至cpp语言在某个编译器（如gcc）编译以后产生的机器码（比如x86）。

长此以往，大家水平越来越高，菜鸟全部自动远走他乡。

显然，即使到了机器码这一层，有些同学还是不爽的。接下来得研究OS，硬件，总线，南桥/北桥，尤其是指令集，
现在cpu种类这么多，加上无比强大的GPU，到底intel的快还是ARM的快？
c编译器肯定得优化。