感谢同事 ｛空蒙｝的投稿
最近碰到个场景，还蛮有普遍性的，如mtop的请求入口非常多，有api2，api3，api4，h5，h5update，cdn_cache,bigpipe等，而Mtop需要依据其具体的入口，选择不同的业务逻辑进行对应的处理。
马上想到两个方案：
- 方案一：采用map存放对应入口的处理方法，然后请求进来后经过get就行，map.get(et);
- 方案二：采用switch语句。
1 |
switch (et) { |
2 |
case API3: |
3 |
return api3service; |
4 |
case API4: |
5 |
return api4service; |
6 |
case API2: |
7 |
return api2service; |
8 |
…… |
if else这种就不予考虑了，明显采用map显的更优雅，代码更具可维护性，目前mtop存在6个入口，api4还未上，如果用switch每次需要硬编码那性能呢？
但用map，也可以做些优化处理，比如我发现api3、h5、cdn_cache在map默认大小为16下，其桶位置发生了碰撞，这样每次get的时候就需要遍历了，这是不好，当然有两种方案，一是改key值避免碰撞，二是改map大小，让其不发生碰撞，我采用map大小为64，避免碰撞，当然后面如要继续添加时候，需要关注经测试，性能可以提升44%，（本机场景，并且这个key在桶的最尾部，也就是需要全部遍历桶全部数据的场景，并且全部预先执行1w次，摒弃了jit对结果的影响）
但map的get操作，每次需要进行hash，位移操作，&操作，再比较操作，想想就需要很多的指令要执行完才能拿到
如果是switch呢？Switch在编译后，有LookupSwitch 和 TableSwitch，其中TableSwitch是O(1)的，LookupSwitch是 O(log n)，TableSwitch情况如下：
1 |
int chooseNear(int i) { |
2 |
switch (i) { |
3 |
case 0: return 0; |
4 |
case 1: return 1; |
5 |
case 2: return 2; |
6 |
default: return -1; |
7 |
} |
8 |
} |
编译后结果
01 |
Method int chooseNear(int) |
02 |
0 iload_1 // Push local variable 1 (argument i) |
03 |
1 tableswitch 0 to 2: // Valid indices are 0 through 2 |
04 |
0: 28 // If i is 0, continue at 28 |
05 |
1: 30 // If i is 1, continue at 30 |
06 |
2: 32 // If i is 2, continue at 32 |
07 |
default:34 // Otherwise, continue at 34 |
08 |
28 iconst_0 // i was 0; push int constant 0... |
09 |
29 ireturn // ...and return it |
10 |
30 iconst_1 // i was 1; push int constant 1... |
11 |
31 ireturn // ...and return it |
12 |
32 iconst_2 // i was 2; push int constant 2... |
13 |
33 ireturn // ...and return it |
14 |
34 iconst_m1 // otherwise push int constant -1... |
15 |
35 ireturn // ...and return it |
也就是TableSwitch只要计算一次偏移量，立即就能到case执行，其时间复杂度为O(1)
1 |
LookupSwitch |
2 |
int chooseFar(int i) { |
3 |
switch (i) { |
4 |
case -100: return -1; |
5 |
case 0: return 0; |
6 |
case 100: return 1; |
7 |
default: return -1; |
8 |
} |
9 |
} |
编译后：
01 |
Method int chooseFar(int) |
02 |
0 iload_1 |
03 |
1 lookupswitch 3: |
04 |
-100: 36 |
05 |
0: 38 |
06 |
100: 40 |
07 |
default: 42 |
08 |
36 iconst_m1 |
09 |
37 ireturn |
10 |
38 iconst_0 |
11 |
39 ireturn |
12 |
40 iconst_1 |
13 |
41 ireturn |
14 |
42 iconst_m1 |
15 |
43 ireturn |
也就是LookupSwitch编译后会保证其顺序，并采用二分法查找对应的case，其时间复杂度为O(log n)
本机，全部预先执行1w次跳过jit的影响，采用map与switch各执行1亿次，执行时间是两位数的差距，map为400多ms，switch为5ms
当然测试的场景case都比较少，如果达到1k多个case条件呢？ Jit还会把jvm指令缓存吗？，如果不缓存又是另外的情况了
大家可以把eclipse设置Xint，看看屏蔽jit后大量运行的效果
还有switch在什么场景下编译后会是TableSwitch，什么下会是LookupSwitch，毕竟两者的时间复杂度还是有差距
Java应用的性能，还是要详细分析其场景，至于要性能还是代码更优雅，要自己权衡了，呵呵，有更好的方案，还请分享哦
