三目运算符和if_else引发的血案
背景
刚刚入职，在看各种代码。在很多业务逻辑的判读通篇都是用的if-else，思考：程序猿都是爱偷懒的，对于一些简单的逻辑能否该用三目运算符呢，这样整个代码也不会显得十分冗余，在简洁度上面看起来也比较舒服。
既然三目运算符相比与if-else来说，比较简洁，那么他们在性能上又有没差异呢？
结论是：三目运算符的运算速度比if-else的效率高出1～0.5倍左右，当然机器可能也会导致误差和结果波动，百度上有测出2倍多的 ，对着数据表示怀疑- -！！
下文基于三目运算符多效率为什比if-else效率高做了分析
码上告诉你
StopWatch sw = new StopWatch();
sw.start("if-else");
for (int i = 1; i <= size; i++) {
if (a > b) {
temp = a;
} else {
temp = b;
}
}
sw.stop();
sw.start("Tri-");
for (int i = 1; i <= size; i++) {
temp = a > b ? a : b;
}
sw.stop();
System.out.println(sw.prettyPrint());
结果输出
size = 10000;
StopWatch '': running time (millis) = 3
-----------------------------------------
ms % Task name
-----------------------------------------
00002 067% if-else
00001 033% Tri-
size = 10 0000
StopWatch '': running time (millis) = 29
-----------------------------------------
ms % Task name
-----------------------------------------
00016 055% if-else
00013 045% Tri-
size = 100 0000
StopWatch '': running time (millis) = 279
-----------------------------------------
ms % Task name
-----------------------------------------
00150 054% if-else
00129 046% Tri-ps:这里为了直观显示结果，选用stopwatch来计时；时间统计可以用stopwatch或者System.currentTimeMillis，stopWatch对小数做了过滤，如果自己想测试的话，建议用currentTimeMills这个可以更加直观的看到数值末尾的波动
改用：System.currentTimeMillis 的计算得出的结果
max = If-else_time/ Tri_time
size = 100 0000
[ 9 ] max :1.8148148148148149-------- min : 1.0714285714285714
-----max-----: 1.8148148148148149
-----avg-----: 1.292012617012617
-----min-----: 1.0714285714285714现象看本质
问题剖析
解决问题的思路就是根据这个:java–>class字节码–>汇编
字节码层面上剖析问题
首先上查看if-else 和 Tri（三目运算符）生成的字节码文件
linweibodeMacBook-Pro:compare linweibo$ javap -c TriAndIf
[a = 100; b = 500] -----肯定会走 else
void funTri();
Code:
0: bipush 100
2: istore_2
3: sipush 500
6: istore_3
7: iload_2
8: iload_3
9: if_icmple 16
12: iload_2
13: goto 17
16: iload_3
17: istore_1
18: return
void funIF();
Code:
0: bipush 100
2: istore_2
3: sipush 500
6: istore_3
7: iload_2
8: iload_3
9: if_icmple 17
12: iload_2
13: istore_1 ！！！！！
14: goto 19
17: iload_3
18: istore_1
19: return
============分隔符===============================
[a = 100 ; b = 50]----短路判断走不走，else
void funTri();
Code:
0: bipush 100
2: istore_2
3: bipush 50
5: istore_3
6: iload_2
7: iload_3
8: if_icmple 15
11: iload_2
12: goto 16
15: iload_3
16: istore_1
17: return
void funIF();
Code:
0: bipush 100
2: istore_2
3: bipush 50
5: istore_3
6: iload_2
7: iload_3
8: if_icmple 16
11: iload_2
12: istore_1 ！！！！！
13: goto 18
16: iload_3
17: istore_1
18: return
截取一段字节码做分析
void funTri();
Code:
0: bipush 100.
//当int取值-128~127时，JVM采用bipush指令将常量压入栈中
2: istore_2
3: sipush 500
//当int取值-32768~32767时，JVM采用sipush指令将常量压入栈中
6: istore_3
//把引用保存到局部变量表中的索引3的位置，然后引用弹出栈
7: iload_2
//把局部变量表中的索引1处的值压入操作栈
8: iload_3
9: if_icmple 16
／／比较 iload_2 和 iload_3的值，如果 iload_2 <= iload_3 则跳转到第 16 行代码
12: iload_2
13: goto 17
16: iload_3
17: istore_1
18: returniload_2 和 iload_3 两个指令将两个入参压入操作数栈中；if_icmple会比较栈顶的两个值的大小；如果 a 小都等于 b 值的话，会跳转到 第 16 条字节码处执行。
这里需要引进一个概念：java虚拟机字节码执行引擎
jvm字节码执行引擎时jvm最核心的组成部分之一。它做的事情很简单：输入的是字节码文件，处理过程是字节码解析等效过程，输出的是执行结果。
在这里java的跨平台性就得到了很好的解释：java代码通过编译器编译之后便会生成一个字节码文件，字节码事一种二进制的class文件，它的内容是jvm的指令，而不像c／c++经由编译器直接生成机器码（汇编）。在java中不用担心生成的字节码文件的兼容性，因为所有的jvm都遵守java虚拟机规范，也就是说所有的jvm环境都是一样的，这样一来字节码文件可以在不同平台下的jvm上运行，这也就是我们常说的java的跨平台性。再啰嗦一下，有得必有失，虽然保证的跨平台性，代价就是java比c／c++性能低的原因之一就是：语言翻译过程中多了一个解析成字节码的环节
- 回到主题中，三目运算符效率比if_else速度快：在jvm解析class文件这一环节中三目运算符的字节码比if_else少了一个操作指令,这是因为else里头也可以存储
在if_else或者三目运算符外部嵌套高密度for；或者在更加真实的业务场景中可能不需要外加for，里头可能是调用方法或者对象，还有可能递归，那么很有可能持有对象引用太深导致stack区内存泄漏
汇编层面上剖析问题
- 在VC++6.0中c／C++的if_else 和 三目运算符的 汇编代码
37: if(a>b)
00401079 mov ecx,dword ptr [ebp-10h]
0040107C cmp ecx,dword ptr [ebp-14h]
0040107F jle main+79h (00401089)
38: temp=a;
00401081 mov edx,dword ptr [ebp-10h]
00401084 mov dword ptr [ebp-18h],edx
39: else
00401087 jmp main+7Fh (0040108f)
40: temp=b;
00401089 mov eax,dword ptr [ebp-14h]
0040108C mov dword ptr [ebp-18h],eax
51: temp=a>b?a:b;
004010F3 mov edx,dword ptr [ebp-10h]
004010F6 cmp edx,dword ptr [ebp-14h]
004010F9 jle main+0F3h (00401103)
004010FB mov eax,dword ptr [ebp-10h]
004010FE mov dword ptr [ebp-24h],eax
00401101 jmp main+0F9h (00401109)
00401103 mov ecx,dword ptr [ebp-14h]
00401106 mov dword ptr [ebp-24h],ecx
00401109 mov edx,dword ptr [ebp-24h]
0040110C mov dword ptr [ebp-18h],edxIf-else无论在何种情况下（在if中或者else中），都是通过先将需要赋的变量值传给寄存器然后再通过寄存器赋值给temp变量 。即
mov edx,b； mov temp,edx ；
然而，对于三目运算，它其中一步却增加多了一个临时变量。
mov ecx,b；mov NEWTEMP,ecx；
mov edx,NEWTEMP；mov temp；edx
因为三目运算是先运算，再赋值！
例如 ：
temp = a > b ? a : b ;
a > b ? a : b 是运算， temp = （a > b ? a : b ）是赋值。
而if语句是直接赋值，不存在运算，所以快一点；
这也就可以解释为什么有时候，if_else 会比 三目执行的快
但是呢，编译器已经帮我们做了优化，所以在汇编成面上，三木运算符和if_else 在效率低差异化上是比较小的。
针对java语言，java看的是字节码不是汇编总结
- 三木运算符的效率比if_else效率高的原因
1.在java转成字节码指令时，if_else比三目运算符多了一条指令istore指令
2.因为解析字节码是在jvm的字节码执行引擎中所以性能主要是在这里被损耗
- 建议
- 对于简单的业务逻辑尽量替代为三目运算符，就算不为性能，起码看起来也比较爽代码
- 对于一些核心的业务逻辑，可以进行抽取，利用状态设计模式
ps：时间比较仓猝考虑的不太全面和漏洞，感兴趣的一起剥坑，测试代码中还遇到一个问题，就是在运行多组测试数据时后面的数据会出现Infiity ，只有单步调试才不会出现。