Java性能测试的困惑：switch和map的性能比较

原文地址： http://agilejava.blogbus.com/logs/39858996.html

最近一直有个问题困扰着我，今天研究了一个晚上，结果从表面上看上说得通，但是也不能确认就是正确的。

事件的起因是近期在搞一个消息处理的功能，要定义大量的消息型，这些消息都是整形的，需要根据消息来判断应该采用哪种处理器进行处理。类似下面的代码:

        boolean v = false;
        switch (i) {
        case 1:
            v = true;
            break;
        case 2:
            v = true;
            break;

         }

这种消息类型有很多，类型数值是连续定义的，可以保证编译生成的jvm指令是tableswitch,这种形式的swtich语句检索效率很高(相应的另一种是lookupswitch,检索使用二分查找，效率要差一些).

因为消息类型很多，要在同一个大方法里写很多的case语句，维护起来不方便，后来就想用Map<Integer,Handler>这种形式来达到同样的目的。

但是我担心使用map的检索效率会比switch低，写了个测试进行验证，结果让我很意外，使用map的测试数据总是比switch这种做法要快一些。

测试环境:

JDK1.6 Linux2.6 2G内存

测试数据:

从1~1000个整数中进行查找，即在map中放入从1~1000的整数,而switch方法中相应有1000个case语句,每个case语句对应一个数值.

测试方法:

每轮测试分别查找1~1000，测试100000次，取每轮测试的平均值，结果如下:

$ java -server -Xms512m -Xmx512m  -cp . SwitchMapTest

tableswith:56743ns
map:26333ns

这个测试结果很不解，switch语句被编译后，对应得是jvm的tableswitch指令，执行起来也就几条指令就完成了;而HashMap的get操作，下面是jdk的源代码:

 public V get(Object key) {
        if (key == null)
            return getForNullKey();
        int hash = hash(key.hashCode());
        for (Entry<K,V> e = table[indexFor(hash, table.length)];
             e != null;
             e = e.next) {
            Object k;
            if (e.hash == hash && ((k = e.key) == key || key.equals(k)))
                return e.value;
        }
        return null;
    }

map.get所执行的jvm指令肯定是要比tableswitch要多的。

但是测试的情况是map反而比switch要快。

到了这一步，我越来越想不通了。

测试了一下在禁用JIT的情况:

$ java -server -Xms512m -Xmx512m -Xint -cp . SwitchMapTest

tableswith:53036ns
map:533155ns

在禁用JIT以后，map的执行效率大大地下降了，因为我怀疑JIT的优化在这里起到了很重要的作用。

我需要看到JVM在执行的过程中JIT进行优化的情况，上网搜索了一下，http://weblogs.java.net/blog/kohsuke/archive/2008/03/deep_dive_into.html这里有详细的介绍，下载jdk-6u14-ea-bin-b06-linux-amd64-debug-06_may_2009.jar后安装，

使用下面的命令查看JIT优化的日志:

java -server  -XX:+PrintOptoAssembly  -Xms512m -Xmx512m SwitchMapTest

输出的日志中有详细的优化日志,下面是HashMap.get方法在其中的一部分，

{method} 
 - klass: {other class}
 - method holder:     'java/util/HashMap'
 - constants:         0x00007f4e5ece70cf{constant pool}
 - access:            0xc1000001  public 
 - name:              'get'
 - signature:         '(Ljava/lang/Object;)Ljava/lang/Object;'
 - max stack:         3
 - max locals:        5
 - size of params:    2
 - method size:       15
 - vtable index:      5
 - code size:         79
 - code start:        0x00007f4e34c1ff30
 - code end (excl):   0x00007f4e34c1ff7f
 - method data:       0x00007f4e34dfdd40
 - checked ex length: 0
 - linenumber start:  0x00007f4e34c1ff7f
 - localvar length:   5
 - localvar start:    0x00007f4e34c1ff92

因为输出的日志很大，就不在这里贴出来了。

查看优化日志之后发现，使用switch实现的方法并没有被优化，优化全部是针对Map,Integer等进行的，也就是说在使用map的实现中，大量地利用了JIT的本地优化代码；而switch的实现以jvm指令的形式执行，这样解释了为什么在这个测试中map在启用JIT的情况下，会比switch快一倍左右;而禁用JIT以后，会慢10倍左右。

虽然是由于JIT引起的性能差别，但是为什么JIT没有对swtich的实现进行优化？

我能想到的解释就是那个方法太大了，有1000个case语句，JIT忽略了？

下面的测试，我把1000个case语句分解成10个小方法，每个方法有100个case语句，类似下面的代码:

public static void tableswitch(int i) {
        boolean v = false;

        v = tableswitch_1(i);
        if (v)
            return;
        v = tableswitch_101(i);
        if (v)
            return;
        v = tableswitch_201(i);
        if (v)
            return;
        v = tableswitch_301(i);
        if (v)
            return;
        v = tableswitch_401(i);
        if (v)
            return;
        v = tableswitch_501(i);
        if (v)
            return;
        v = tableswitch_601(i);
        if (v)
            return;
        v = tableswitch_701(i);
        if (v)
            return;
        v = tableswitch_801(i);
        if (v)
            return;
        v = tableswitch_901(i);
        if (v)
            return;
    }

 

private static boolean tableswitch_1(int i) {
        boolean v = false;
        switch (i) {
        case 1:
            v = true;
            break;
        case 2:
            v = true;
            break;
        case 3:

        .....

        case 100:

           v = true;

           break;

}

return v;

}

执行测试:

$ java -server   -Xms512m -Xmx512m SwitchMapTest
tableswith:22288ns
map:29169ns

这时switch的实现要比map快一些了，打开优化日志再看:

$ java -server  -XX:+PrintOptoAssembly  -Xms512m -Xmx512m SwitchMapTest

在输出的日志中可以发现类似下面的内容:

{method}
 - klass: {other class}
 - method holder:     'SwitchTest'
 - constants:         0x00007fc069f040cf{constant pool}
 - access:            0x8100000a  private static
 - name:              'tableswitch_1'
 - signature:         '(I)Z'
 - max stack:         1
 - max locals:        2
 - size of params:    1
 - method size:       15
 - vtable index:      -2
 - code size:         915
 - code start:        0x00007fc04000ac30
 - code end (excl):   0x00007fc04000afc3
 - method data:       0x00007fc04000fdd0
 - checked ex length: 0
 - linenumber start:  0x00007fc04000afc3
 - localvar length:   2
 - localvar start:    0x00007fc04000b096
#

所有的10个tableswitch_方法全部被优化了，从而导致switch实现的性能超过了map实现。

到此，我的困惑基本上解开了，从中得到了什么呢？总结如下:

1.Java的性能测试受环境的影响很大

Java性能测试是比较像物理学中的“测不准”。

在测试的时候，-server和-client的表现很可能不一样，而我们的开发机一般默认是client的，如果是在做server上的应用，建议在IDE的jvm配置中默认加上-server的选项。

相同的实现，在server模式中的性能可能就好，而在client中的性能可能就要差一些，所以我们要确定程序是部署在哪种环境下的，从开始就在那个环境中测试并确定解决方案。

2.JIT对性能的提升太恐怖了

JIT在不到万不得已的时候不要禁用。

以前遇到过问题，就是JVM的compiler线程总崩溃，后来不得已禁止了JIT的优化，才正常了，当时是全部给禁了，现在想来可以把引起那个问题的类禁止优化就可以了，否则打击面太大了，性能的损失太大了。

3.Java的方法还是要小一些的好

Java中的方法，尽量避免超级大方法，很多代码在一起。

小方法一是可以使逻辑更清楚，修改、维护起来很方便；另一方面是它有利于JIT的优化，提升性能。第二点我是猜得，记得以前也在网上见到过类似的文章，暂且先相信我吧，呵呵。

写了这么多，也许这个问题不值得这么费劲地去论证，在真实的应用中1000左右的case语句还是很少见的，不过既然研究了，就写在这里，供以后参考也是好的，也不知道得出的结论的对不对，如有错误请指正，谢谢 :)