Lambda表達式為什么運行效率低
准備
我為什么說Lambda表達式運行效率低。
先准備一個list：
List<Integer> list = new ArrayList<>(); for (int i = 0; i < 10000; i++) { list.add(i); }
先用Lambda表達式的方式來循環一下這個list：
long lambdaStart = System.currentTimeMillis(); list.forEach(i -> { // 不用做事情，循環就夠了 }); long lambdaEnd = System.currentTimeMillis(); System.out.println("lambda循環運行毫秒數===" + (lambdaEnd - lambdaStart));
運行時間大概為110ms
再用普通方式來循環一下這個list：
long normalStart = System.currentTimeMillis(); for (int i = 0; i < list.size(); i++) { list.get(i); } long normalEnd = System.currentTimeMillis(); System.out.println("普通循環運行毫秒數===" + (normalEnd - normalStart));
運行時間大概為0ms或1ms
你們沒看錯，運行時間差別就是這么大，不相信的話大家可以自己去試一下，並且這並不是只有在循環時使用Lambda表達式才會導致運行效率低，而是Lambda表達式在運行時就是會需要額外的時間，我們繼續來分析。
分析
如果我們要研究Lambda表達式，最正確、最直接的方法就是查看它所對應的字節碼指令。
使用以下命令查看class文件對應的字節碼指令：
javap -v -p Test.class
上述命令解析出來的指令非常多，我這里提取比較重要的部分來給大家分析：
使用Lambda表達式所對應的字節碼指令如下：
34: invokestatic #6 // Method java/lang/System.currentTimeMillis:()J 37: lstore_2 38: aload_1 39: invokedynamic #7, 0 // InvokeDynamic #0:accept:()Ljava/util/function/Consumer; 44: invokeinterface #8, 2 // InterfaceMethod java/util/List.forEach:(Ljava/util/function/Consumer;)V 49: invokestatic #6 // Method java/lang/System.currentTimeMillis:()J
不使用Lambda表達式所對應的字節碼指令如下：
82: invokestatic #6 // Method java/lang/System.currentTimeMillis:()J 85: lstore 6 87: iconst_0 88: istore 8 90: iload 8 92: aload_1 93: invokeinterface #17, 1 // InterfaceMethod java/util/List.size:()I 98: if_icmpge 107 101: iinc 8, 1 104: goto 90 107: invokestatic #6 // Method java/lang/System.currentTimeMillis:()J
從上面兩種方式所對應的字節碼指令可以看出，兩種方式的執行方式確實不太一樣。
不使用Lambda表達式執行循環流程
字節碼指令執行步驟：
- 82:invokestatic： 執行靜態方法，java/lang/System.currentTimeMillis:();
- 85-92: 簡單來說就是初始化數據，int i = 0;
- 93:invokeinterface：執行接口方法，接口為List，所以真正執行的是就是ArrayList.size方法;
- 98:if_icmpge： 比較，相當於執行i < list.size();
- 101:iinc： i++;
- 104:goto： 進行下一次循環;
- 107:invokestatic： 執行靜態方法;
那么這個流程大家應該問題不大，是一個很正常的循環邏輯。
使用Lambda表達式執行循環流程
我們再來看一下對應的字節碼指令：
34: invokestatic #6 // Method java/lang/System.currentTimeMillis:()J 37: lstore_2 38: aload_1 39: invokedynamic #7, 0 // InvokeDynamic #0:accept:()Ljava/util/function/Consumer; 44: invokeinterface #8, 2 // InterfaceMethod java/util/List.forEach:(Ljava/util/function/Consumer;)V 49: invokestatic #6 // Method java/lang/System.currentTimeMillis:()J
字節碼指令執行步驟：
- 34: invokestatic： 執行靜態方法，java/lang/System.currentTimeMillis:();
- 37-38： 初始化數據
- 39: invokedynamic： 這是在干什么？
- 44: invokeinterface： 執行java/util/List.forEach()方法
- 49: invokestatic： 執行靜態方法，java/lang/System.currentTimeMillis:();
和上面正常循環的方式的字節碼指令不太一樣，我們認真的看一下這個字節碼指令，這個流程並不像是一個循環的流程，而是一個方法順序執行的流程：
- 先初始化一些數據
- 執行invokedynamic指令（暫時這個指令是做什么的）
- 然后執行java/util/List.forEach()方法，所以真正的循環邏輯在這里
所以我們可以發現，使用Lambda表達式循環時，在循環前會做一些其他事情，所以導致執行時間要更長一點。
那么invokedynamic指令到底做了什么事情呢？
java/util/List.forEach方法接收一個參數Consumer<? super T> action，Consumer是一個接口，所以如果要調用這個方法，就要傳遞該接口類型的對象。
而我們在代碼里實際上是傳遞的一個Lambda表達式，那么我們這里可以假設：需要將Lambda表達式轉換成對象，且該對象的類型需要根據該Lambda表達式所使用的地方在編譯時期進行反推。
這里在解釋一下反推：一個Lambda表達式是可以被多個方法使用的，而且這個方法所接收的參數類型，也就是函數式接口，是可以不一樣的，只要函數式接口符合該Lambda表達式的定義即可。
本例中，編譯器在編譯時可以反推出，Lambda表達式對應一個Cosumer接口類型的對象。
那么如果要將Lambda表達式轉換成一個對象，就需要有一個類實現Consumer接口。
所以，現在的問題就是這個類是什么時候生成的，並且生成在哪里了？
所以，我們慢慢的應該能夠想到，invokedynamic指令，它是不是就是先將Lambda表達式轉換成某個類，然后生成一個實例以便提供給forEach方法調用呢？
我們回頭再看一下invokedynamic指令：
invokedynamic #7, 0 // InvokeDynamic #0:accept:()Ljava/util/function/Consumer;
Java中調用函數有四大指令：invokevirtual、invokespecial、invokestatic、invokeinterface，在JSR 292 添加了一個新的指令invokedynamic，這個指令表示執行動態語言，也就是Lambda表達式。
該指令注釋中的#0表示的是BootstrapMethods中的第0個方法：
BootstrapMethods: 0: #60 invokestatic java/lang/invoke/LambdaMetafactory.metafactory:(Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/MethodType;Ljava/lang/invoke/MethodType;Ljava/lang/invoke/MethodHandle;Ljava/lang/invoke/MethodType;)Ljava/lang/invoke/CallSite; Method arguments: #61 (Ljava/lang/Object;)V #62 invokestatic com/luban/Test.lambda$main$0:(Ljava/lang/Integer;)V #63 (Ljava/lang/Integer;)V
所以invokedynamic執行時，實際上就是執行BootstrapMethods中的方法，比如本例中的：java/lang/invoke/LambdaMetafactory.metafactory。
代碼如下：
public static CallSite metafactory(MethodHandles.Lookup caller, String invokedName, MethodType invokedType, MethodType samMethodType, MethodHandle implMethod, MethodType instantiatedMethodType) throws LambdaConversionException { AbstractValidatingLambdaMetafactory mf; mf = new InnerClassLambdaMetafactory(caller, invokedType, invokedName, samMethodType, implMethod, instantiatedMethodType, false, EMPTY_CLASS_ARRAY, EMPTY_MT_ARRAY); mf.validateMetafactoryArgs(); return mf.buildCallSite(); }
這個方法中用到了一個特別明顯且易懂的類：InnerClassLambdaMetafactory。
這個類是一個針對Lambda表達式生成內部類的工廠類。當調用buildCallSite方法是會生成一個內部類並且生成該類的一個實例。
那么現在要生成一個內部類，需要一些什么條件呢：
- 類名：可按一些規則生成
- 類需要實現的接口：編譯時就已知了，本例中就是Consumer接口
- 實現接口里面的方法：本例中就是Consumer接口的
void accept(T t)方法。
那么內部類該怎么實現void accept(T t)方法呢？
我們再來看一下javap -v -p Test.class的結果中除開我們自己實現的方法外還多了一個方法：
private static void lambda$main$0(java.lang.Integer); descriptor: (Ljava/lang/Integer;)V flags: ACC_PRIVATE, ACC_STATIC, ACC_SYNTHETIC Code: stack=0, locals=1, args_size=1 0: return LineNumberTable: line 25: 0 LocalVariableTable: Start Length Slot Name Signature 0 1 0 i Ljava/lang/Integer;
很明顯，這個靜態的lambda$main$0方法代表的就是我們寫的Lambda表達式，只是因為我們例子中Lambda表達式沒寫什么邏輯，所以這段字節碼指令Code部分也沒有什么內容。
那么，我們現在在實現內部類中的void accept(T t)方法時，只要調用一個這個lambda$main$0靜態方法即可。
所以到此，一個內部類就可以被正常的實現出來了，內部類有了之后，Lambda表達式就是可以被轉換成這個內部類的對象，就可以進行循環了。