かつのりの日記２

2chのJavaネタ

[Java SE 7] 次世代Javaの動向 5 [dolphin]

JDK7が開発中ですが、色々と面白い議論があるスレッドです。この中で面白かったのが、ライトウェイトな例外。例外処理は重いので軽い例外が欲しいという話です。発端としてはInteger.parseIntなんですが、「数値化できないときに非チェック例外をスローするのはどうよ？例外って重いし。」ってところからです。

例外処理は一般的に重い処理といわれていますが、実際にどのフェーズが重いのかはっきりと分かっている人が少ないと思います。そこで検証してみました。自分の中ではthrowが重いと思っていたのですが、実際には違いました。

public class Test { private static class LightWeightException extends RuntimeException { @Override public synchronized Throwable fillInStackTrace() { return this; } } private static class NormalException extends RuntimeException { } public static void main(String[] args) { System.out.println(System.currentTimeMillis()); for (int i = 0; i < 10000000; i++) { try { test0(); } catch (Exception e) { } } System.out.println(System.currentTimeMillis()); for (int i = 0; i < 10000000; i++) { try { test1(); } catch (Exception e) { } } System.out.println(System.currentTimeMillis()); for (int i = 0; i < 10000000; i++) { try { test2(); } catch (Exception e) { } } System.out.println(System.currentTimeMillis()); } public static void test0() { } public static void test1() { throw new LightWeightException(); } public static void test2() { throw new NormalException(); } }

10,000,000回ループでそれぞれstaticメソッドコールのみ、軽い例外のスロー、通常の例外のスローの時間を計測しました。5回試した平均からいうと、それぞれ9ms、1675ms、9815msでした。throwが決して軽い処理ではありませんが、明らかに比重として重いのは例外のスローよりも例外の生成です。

上記コードでも分かると思いますが、fillInStackTraceが重いわけですが、このメソッドは必ずコンストラクタで呼ばれるのです。new Throwable()だけで現在のスタックが取得できるのはこのためです。これが重いといわれる原因なのです。

クリティカルで速度が要求される場面での数値チェックは、例外を使わないのが無難っぽいです。

投稿日時 : 2007年9月7日 0:46