局部變量的范圍如何影響Java上的加載/存儲性能？

Question

環境：JDK1.8 Windows 10

范例1：

String msg=null;
for (int i=0;i<10;i++){
     msg="Hello";
 }

和example2：

for(int =0;i<10;i++){
      String msg = "hello";
}

誰能告訴我這兩個示例之間的區別以及哪種代碼更有效

Answer 1

在第一個示例中， msg在所示的最外部作用域內是作用域內的，而在第二個示例中， msg僅在循環體中處於作用域內。 在繼續之前，我會提醒讀者，過早的優化（尤其是此處所見的微優化）通常不適當或沒有用，因此人們應該首先爭取清晰，可讀和可維護的代碼。

我現在繼續為好奇的讀者。 通過使用javac 1.8.0_171編譯代碼並使用javap -c反匯編，我得到以下字節碼：

第一種方法：

    Code:
       0: aconst_null
       1: astore_1
       2: iconst_0
       3: istore_2
       4: iload_2
       5: bipush        10
       7: if_icmpge     19
      10: ldc           #2                  // String f
      12: astore_1
      13: iinc          2, 1
      16: goto          4
      19: return

第二種方法：

    Code:
       0: iconst_0
       1: istore_1
       2: iload_1
       3: bipush        10
       5: if_icmpge     17
       8: ldc           #2                  // String f
      10: astore_2
      11: iinc          1, 1
      14: goto          2
      17: return

如您所見，這兩個編譯結果在本質上非常相似。 兩者都具有循環結構，循環的主體由加載常數（ldc）和后跟astore_<n>的局部變量插槽組成。 插槽的變量分配有所不同（第一個將i分配給插槽2， msg分配給1，第二個相反），但這不會產生明顯的影響。 第一個確實包含兩個額外的字節碼，以便在第一次迭代之前將null存儲到msg 。 但是，這種影響非常微小，以至於無法嘗試對此進行優化。

我目前沒有工具集來查看JIT優化產生的機器代碼，但我強烈懷疑任何有能力的JIT編譯器都會優化整個循環。