點擊上方“朱小廝的博客”，選擇“設為星標”

后臺回復"書"，獲取

后臺回復“k8s”，可領取k8s資料

來源：r6d.cn/ZxLw

這是Java字節碼上針對字節碼大小的一個早期優化。從現在的角度看它可能算是一種過早優化（premature optimization）了。

Java字節碼指令集里，大部分跟局部變量打交道的指令（例如<type>load、<type>store）都有完整版：

<type>load?n

例如iload 5，以及針對頭4個局部變量/參數的縮寫版：

<type>load_<n>

例如iload_0，這樣兩個版本。其中，縮寫版，正如標題所說，只有0~3的范圍。

它們的區別是，前者有顯式的“操作數”（operand），而后者是把操作數融合到了操作碼（opcode）里面。看iload與iload_<n>的例子就很清楚：

iload的指令格式是：Chapter 6. The Java Virtual Machine Instruction Set^[1]

iload?index

其中"iload"是opcode，其值為21（0x15），而后面跟著一個unsigned byte作為index來指定局部變量的下標。另外還有wide版，如果在iload前面帶有wide前綴的話，則格式為：

wide?iload?index1?index2

其中wide、iload、index1、index2各自為一個字節，而 (index1 << 8) | index2 構成指令局部變量下標的操作數。

iload_的指令格式則是：Chapter 6. The Java Virtual Machine Instruction Set^[2]

iload_<n>

其中iload_<n>自身就是opcode，它可能的取值為：iload_0 = 26 (0x1a)iload_1 = 27 (0x1b)iload_2 = 28 (0x1c)iload_3 = 29 (0x1d)這樣的話，針對頭4個局部變量，iload_<n>就可以只用一個字節的opcode來表達整條指令，比使用完整版的iload要少一個字節。使用縮寫版指令不但可以讓字節碼的大小減少，還可以讓解釋器（注意！只是解釋器）的性能提升。因為解釋器通常都會有這樣的結構：

while?(true)?{opcode?=?*program_counter++;????//?fetch?opcode://???1?memory?read,?1?memory?writeswitch?(opcode)?{???????????????//?dispatch?opcodecase?some_instruction:operands?=?decode_operands();?//?decode?operands://???1~n?memory?readsperform_operation(operands);??//?actual?operationprogram_counter?+=?size_of_some_instruction;?//?1?memory?read,?1?memory?writebreak;} }

（解釋器有各種優化方式，上面的形式是最簡單的switch-threading，但 fetch-dispatch/decode-execute 的組成部分總是存在的）當使用縮寫版指令時，decode_operands()就不需要做任何額外的內存讀，因為operand已經隱藏在opcode里了，于是就會比完整版指令要快一些。

至于為啥選擇0~3的范圍來做縮短版，我不知道當初JVM原始設計的過程中具體發生了怎樣的討論和設計取舍，但一種可以想像的可能性是：最初的JVM的解釋器已經寫好了，看看1個字節的opcode能表達的256個opcode中已經用了多少個，然后再想想剩下的空余的那些可以用來做怎樣的局部優化。

大概是正好發現，如果用0~3的話可以基本上把opcode范圍用滿（JVM規范里使用了的opcode范圍比Sun最初的JVM內部所使用的opcode范圍要小一些，因為Sun JVM使用了一些quick_系字節碼并沒有作為規范的一部分，而是在第一版JVM規范里作為額外的講解說剩余的編碼空間可以用來做quick_系指令的優化），如果用例如說0~4的話就把1字節opcode編碼空間用超了，而0~2的話則用不滿。

就這樣而已。

于是早期的坊間傳說的Java程序性能優化指引中，有一條是說：Java方法應該盡量只使用不超過4個參數+局部變量，最頻繁使用的局部變量應該放在前面，來想辦法使用上Java字節碼的這個縮寫版指令優化。

然而后來JIT編譯器成為主流后，這種優化指引就完全沒有用了。JIT編譯器根本不在乎輸入的字節碼是完整版還是縮寫版，都一樣對待。

參考資料

[1]

Chapter 6. The Java Virtual Machine Instruction Set: https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-6.html#jvms-6.5.iload

[2]

Chapter 6. The Java Virtual Machine Instruction Set: https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-6.html#jvms-6.5.iload_n

想知道更多？掃描下面的二維碼關注我

后臺回復"技術"，加入技術群

后臺回復“k8s”，可領取k8s資料

【精彩推薦】

• 原創|OpenAPI標準規范

• 中臺不是萬能藥，關于中臺的思考和嘗試
  

• ClickHouse到底是什么？為什么如此牛逼！

• 原來ElasticSearch還可以這么理解

• 面試官：InnoDB中一棵B+樹可以存放多少行數據？

• 微服務下如何解耦？對于已經緊耦合下如何重構？

• 如何構建一套高性能、高可用、低成本的視頻處理系統？

• 架構之道：分離業務邏輯和技術細節

• 星巴克不使用兩階段提交
  

點個贊+在看，少個 bug?????

總結

以上是生活随笔為你收集整理的JAVA字节码指令iload_n为什么只有0到3？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。