Java8-13新特性中的Lambda表達式為什麼運行效率低

準備

我為什麼說Lambda表達式運行效率低


先準備一個list:

<code>List<integer> list = new ArrayList<>();
for (int i = 0; i < 10000; i++) {
list.add(i);
}/<integer>/<code>


先用Lambda表達式的方式來循環一下這個list:

<code>long lambdaStart = System.currentTimeMillis();
list.forEach(i -> {
// 不用做事情,循環就夠了
});
long lambdaEnd = System.currentTimeMillis();
System.out.println("lambda循環運行毫秒數===" + (lambdaEnd - lambdaStart));/<code>

運行時間大概為110ms


再用普通方式來循環一下這個list:

<code>long normalStart = System.currentTimeMillis();
for (int i = 0; i < list.size(); i++) {
// 不用做事情,循環就夠了
}
long normalEnd = System.currentTimeMillis();
System.out.println("普通循環運行毫秒數===" + (normalEnd - normalStart));/<code>

運行時間大概為0ms或1ms


你們沒看錯,運行時間差別就是這麼大,不相信的話大家可以自己去試一下,並且這並不是只有在循環時使用Lambda表達式才會導致運行效率低,而是Lambda表達式在運行時就是會需要額外的時間,我們繼續來分析。


分析

如果我們要研究Lambda表達式,最正確、最直接的方法就是查看它所對應的字節碼指令。


使用以下命令查看class文件對應的字節碼指令:

<code>javap -v -p Test.class/<code>


上述命令解析出來的指令非常多,我這裡提取比較重要的部分來給大家分析:


使用Lambda表達式所對應的字節碼指令如下:

<code>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/<code>


不使用Lambda表達式所對應的字節碼指令如下:

<code>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/<code>


從上面兩種方式所對應的字節碼指令可以看出,兩種方式的執行方式確實不太一樣。


不使用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表達式執行循環流程

我們再來看一下對應的字節碼指令:


<code>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/<code>


字節碼指令執行步驟:

  • 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指令:

<code>invokedynamic #7,  0    // InvokeDynamic #0:accept:()Ljava/util/function/Consumer;/<code>


Java中調用函數有四大指令:invokevirtual、invokespecial、invokestatic、invokeinterface,在JSR 292 添加了一個新的指令invokedynamic,這個指令表示執行動態語言,也就是Lambda表達式。


該指令註釋中的#0表示的是BootstrapMethods中的第0個方法:

<code>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/<code>


所以invokedynamic執行時,實際上就是執行BootstrapMethods中的方法,比如本例中的:java/lang/invoke/LambdaMetafactory.metafactory。


代碼如下:

<code>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();
}/<code>


這個方法中用到了一個特別明顯且易懂的類:InnerClassLambdaMetafactory。


這個類是一個針對Lambda表達式生成內部類的工廠類。當調用buildCallSite方法是會生成一個內部類並且生成該類的一個實例。


那麼現在要生成一個內部類,需要一些什麼條件呢:

  1. 類名:可按一些規則生成
  2. 類需要實現的接口:編譯時就已知了,本例中就是Consumer接口
  3. 實現接口裡面的方法:本例中就是Consumer接口的void accept(T t)方法。


那麼內部類該怎麼實現void accept(T t)方法呢?


我們再來看一下javap -v -p Test.class的結果中除開我們自己實現的方法外還多了一個方法:


<code>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;/<code>


很明顯,這個靜態的lambda$main$0方法代表的就是我們寫的Lambda表達式,只是因為我們例子中Lambda表達式沒寫什麼邏輯,所以這段字節碼指令Code部分也沒有什麼內容。


那麼,我們現在在實現內部類中的void accept(T t)方法時,只要調用一個這個lambda$main$0靜態方法即可。


所以到此,一個內部類就可以被正常的實現出來了,內部類有了之後,Lambda表達式就是可以被轉換成這個內部類的對象,就可以進行循環了。


Java8-13新特性中的Lambda表達式為什麼運行效率低

創作不易,覺得寫的不錯的,還請多多轉發


分享到:


相關文章: