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

最新推荐文章于 2024-07-08 07:30:00 发布

谁谁谁是我

最新推荐文章于 2024-07-08 07:30:00 发布

阅读量7.4k

点赞数 15

分类专栏： java

java 专栏收录该内容

5 篇文章 0 订阅

订阅专栏

原文地址： 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
#