1. 为什么需要一份能随时翻的字节码指令手册写了几年 Java 之后你迟早会遇到一个分水岭一边是继续停留在“写业务代码、调 API、改配置”的层面另一边是开始好奇“我写的这行 Java 代码到了 JVM 里到底变成了什么”。这个分水岭的标志性事件往往就是第一次认真去看javap -c的输出。我第一次看字节码的时候整个人是懵的。满屏的aload_0、invokespecial、getfield、areturn每个单词都认识连起来完全不知道在干嘛。更让人抓狂的是网上搜到的资料要么是 JVM 规范那种“给编译器作者看”的严谨描述要么是零散的博客只讲三五个指令根本凑不成一套能随时查阅的手册。于是我就萌生了一个想法自己整理一份字节码指令手册按功能分类配上实际例子遇到不认识的指令随时翻。这份手册不是给 JVM 实现者看的而是给像我这样的一线 Java 开发者看的。它的目标很明确当你看到一段javap输出时能快速定位到每个指令属于哪个类别、操作数栈怎么变、局部变量表怎么动、它对应的高级语言写法大概是什么样。掌握了这套东西你排查诡异的编译产物、理解 Lambda 和内部类的实现、分析性能热点、甚至手写字节码做 AOP都会有一个质的飞跃。需要提前说明的是字节码指令有两百多条但真正高频使用的也就五六十条。我的策略是先把这五六十条吃透剩下的按类别建立索引用到再查。下面我就按这个思路把整份手册拆成几个模块来讲每个模块都配上我实际踩过的坑和验证过的例子。2. 从 class 文件结构到指令执行模型先建立正确的坐标系2.1 class 文件里指令到底存在哪很多人一上来就背指令助记符结果背了半天还是不知道这些指令在 class 文件的哪个位置。我建议先花十分钟把 class 文件的整体结构过一遍建立坐标系后面看指令才不会迷路。一个 class 文件大致是这样的顺序魔数、版本号、常量池、访问标志、类索引、父类索引、接口索引集合、字段表集合、方法表集合、属性表集合。字节码指令就藏在方法表里每个方法的Code属性中。Code属性里有一个code_length和紧随其后的code[]数组这个数组就是真正的指令字节流。关键点在于字节码指令是变长的。大部分指令占 1 个字节操作码但有些指令后面会跟操作数占 2 到 5 个字节不等。比如bipush后面跟 1 字节的立即数sipush跟 2 字节invokeinterface后面跟 4 字节。这就是为什么你在javap输出里会看到类似10: invokespecial #5这样的行——前面的数字是指令在 code 数组中的偏移量字节为单位后面的#5是常量池索引。我踩过的第一个坑就是以为偏移量是“第几条指令”。实际上它是字节偏移因为指令变长所以偏移量不连续是常态。看javap输出时左边的数字是字节偏移不是行号这一点一定要记牢。2.2 操作数栈和局部变量表指令操作的两个舞台字节码指令本质上只干两件事在操作数栈上压入/弹出数据以及在局部变量表里读写数据。理解了这两个结构指令的行为就一目了然了。操作数栈是一个后进先出的栈深度在编译期就确定好了写在Code属性的max_stack里。局部变量表则是一个数组max_locals指定了它的容量。对于实例方法局部变量表的第 0 个槽位默认是this对于静态方法第 0 个槽位就是第一个参数。举个最经典的例子int add(int a, int b) { return a b; }编译出来是0: iload_1 1: iload_2 2: iadd 3: ireturniload_1把局部变量表第 1 个槽位也就是参数 a压入操作数栈iload_2把第 2 个槽位参数 b压入此时栈里是[a, b]。iadd弹出栈顶两个 int 相加把结果压回栈栈变成[ab]。ireturn弹出栈顶的 int 作为返回值返回。你看只要盯住“栈怎么变、局部变量表怎么变”再复杂的指令都能拆解。我后来养成一个习惯每学一条新指令就在纸上画一遍栈的变化。画多了之后看javap输出基本就是条件反射。2.3 为什么指令要分这么多类型类型前缀的意义初学者最容易困惑的一点是为什么加法有iadd、ladd、fadd、dadd四种为什么加载有iload、lload、fload、dload、aload这背后是 JVM 的一个核心设计字节码指令在操作码层面就区分了类型。i代表 intl代表 longf代表 floatd代表 doublea代表引用reference。这样做的好处是解释器执行时不需要额外查类型直接根据操作码就能确定操作数栈上数据的宽度和运算方式执行效率高。代价就是指令数量膨胀。但对我们使用者来说这反而降低了记忆负担——你只要记住“前缀决定类型后缀决定操作”就能推导出大部分指令的含义。比如istore是存 int 到局部变量表lstore是存 longastore是存引用。i2l是 int 转 longl2i是 long 转 inti2f是 int 转 float规律非常清晰。有一个例外要特别注意boolean、byte、char、short在字节码层面没有独立的类型前缀它们统一用iint来处理。也就是说boolean的加载用的是iload存储用的是istore。这是因为 JVM 的操作数栈最小单位是 32 位这些小于 32 位的类型在栈上都会被扩展成 int。这个细节在分析数组操作时特别重要后面讲数组指令时会再展开。3. 按功能分类拆解高频指令一份能直接查的速查表3.1 加载与存储指令数据在两个舞台间搬运加载load和存储store指令是出现频率最高的一类它们负责在局部变量表和操作数栈之间搬运数据。加载是“局部变量表 → 操作数栈”存储是“操作数栈 → 局部变量表”。按类型分加载指令有iload、lload、fload、dload、aload存储指令有istore、lstore、fstore、dstore、astore。它们都带一个操作数指定局部变量表的槽位索引。但你会发现javap输出里经常出现iload_0、iload_1、aload_0这种带下划线和数字的形式。这是 JVM 的一个优化对于槽位 0 到 3 的访问提供了专门的单字节指令不需要额外的操作数执行更快。iload_0等价于iload 0但少占一个字节。这个优化叫“隐式操作数”在方法参数少、局部变量少的方法里能显著减小 class 文件体积。我整理了一张对照表方便你快速查阅类型通用加载隐式加载0-3通用存储隐式存储0-3intiloadiload_0 ~ iload_3istoreistore_0 ~ istore_3longlloadlload_0 ~ lload_3lstorelstore_0 ~ lstore_3floatfloadfload_0 ~ fload_3fstorefstore_0 ~ fstore_3doubledloaddload_0 ~ dload_3dstoredstore_0 ~ dstore_3引用aloadaload_0 ~ aload_3astoreastore_0 ~ astore_3还有一个特殊的加载指令ldc它用来把常量池中的常量加载到栈上。ldc只能加载 int、float、String 和 Class 常量ldc_w是它的宽版本索引超过 255 时用ldc2_w用来加载 long 和 double。这个指令在字符串字面量、类字面量场景下非常常见。注意long和double占两个槽位。如果你在局部变量表里看到lload_1那么下一个可用槽位是 3不是 2。这个细节在分析复杂方法的局部变量表时经常让人算错。3.2 算术与逻辑指令栈顶两个数的游戏算术指令全部是“弹出栈顶两个数运算后压回结果”的模式。按类型分int 加法iadd、减法isub、乘法imul、除法idiv、取余irem、取负ineglong 对应ladd、lsub、lmul、ldiv、lrem、lnegfloat 对应fadd、fsub、fmul、fdiv、frem、fnegdouble 对应dadd、dsub、dmul、ddiv、drem、dneg这里有个坑没有frem和drem的隐式版本也没有irem的隐式版本它们都是标准指令。另外iinc是一个很特殊的指令它直接在局部变量表上做自增不经过操作数栈。iinc index, const表示把第 index 个槽位的 int 加上 const。这就是为什么for (int i 0; i n; i)里的i编译出来是iinc而不是iadd——因为不需要把 i 加载到栈上再存回去直接在局部变量表里改效率更高。位运算指令有ishl左移、ishr算术右移、iushr逻辑右移、iand、ior、ixorlong 版本对应lshl、lshr、lushr、land、lor、lxor。注意移位指令的操作数是 int即使被移位的是 long移位量也是 int。比较指令lcmp、fcmpl、fcmpg、dcmpl、dcmpg比较特殊它们弹出两个数压入一个 int 结果-1、0、1。l和g的区别在于遇到 NaN 时的处理fcmpl遇到 NaN 压入 -1fcmpg压入 1。这个区别在实现if (a b)和if (a b)时会被编译器利用。3.3 类型转换指令窄化与宽化的边界类型转换指令负责在不同数值类型之间转换。宽化小类型到大类型通常是安全的窄化大类型到小类型可能丢失精度。int 到 longi2lint 到 floati2fint 到 doublei2dlong 到 intl2ilong 到 floatl2flong 到 doublel2dfloat 到 intf2ifloat 到 longf2lfloat 到 doublef2ddouble 到 intd2idouble 到 longd2ldouble 到 floatd2f还有一个i2b、i2c、i2s分别把 int 窄化成 byte、char、short。这三个指令在数组操作和强制类型转换时会出现。这里有个反直觉的点从 int 到 byte/char/short 的转换在字节码层面是显式指令但从 byte/char/short 到 int 的转换是隐式的。因为它们在栈上本来就是以 int 形式存在的不需要额外指令。所以byte b 1; int i b;编译出来只有bipush 1; istore_1; iload_1; istore_2没有i2b或b2i。但int i 300; byte b (byte) i;就会有i2b。3.4 对象与数组指令new、checkcast 和数组家族对象创建指令主要是new它后面跟一个常量池索引指向要实例化的类。new只负责在堆上分配内存并压入引用真正的构造函数调用要靠后面的invokespecial init。所以new Object()编译出来是new #2; dup; invokespecial #1。dup是为了复制一份引用因为invokespecial会消耗一个引用而new的结果还需要留给后续使用。数组指令有一整套家族newarray创建基本类型数组anewarray创建引用类型数组multianewarray创建多维数组。加载数组元素用iaload、laload、faload、daload、aaload、baload、caload、saload存储用iastore、lastore等。注意baload和bastore同时用于 byte 和 boolean 数组caload和castore用于 char 数组。arraylength指令获取数组长度它弹出数组引用压入 int 长度。checkcast做类型检查instanceof做类型判断并压入 int 结果。athrow抛出异常monitorenter和monitorexit用于同步块。我踩过的一个坑是checkcast和instanceof后面跟的常量池索引指向的是类描述符不是类名。在javap -c输出里看到checkcast #5要配合javap -v看常量池才能知道具体是哪个类。3.5 方法调用指令invoke 家族的四兄弟方法调用是字节码里最复杂也最重要的一类指令有四个成员invokestatic调用静态方法不需要对象引用invokespecial调用实例构造方法、私有方法、父类方法invokevirtual调用普通实例方法支持多态invokeinterface调用接口方法Java 7 之后又加了invokedynamic用于动态语言支持和 Lambda 表达式。Java 8 的 Lambda 就是通过invokedynamic加LambdaMetafactory实现的而不是匿名内部类。这个点我在分析 Lambda 性能时专门验证过确实和匿名内部类走的是完全不同的路径。invokevirtual和invokeinterface的区别在于前者在常量池里存的是方法引用后者存的是接口方法引用并且invokeinterface后面还跟两个字节的操作数参数个数和保留字节。执行时invokevirtual通过虚方法表做动态分派invokeinterface通过接口方法表做分派后者通常稍慢因为接口方法表的结构更复杂。invokedynamic最特殊它后面跟的是一个BootstrapMethods属性的索引第一次执行时会调用引导方法生成CallSite之后就直接调用CallSite的目标方法。这个机制是 Java 实现动态语言支持的核心。3.6 控制转移指令if、goto 和 switch 的实现控制转移指令负责改变程序计数器实现分支和循环。条件分支有ifeq、ifne、iflt、ifge、ifgt、ifle以及if_icmpeq、if_icmpne等比较两个 int 的指令还有if_acmpeq、if_acmpne比较引用。这些指令后面跟一个 2 字节的有符号偏移量表示跳转目标相对于当前指令的偏移。goto是无条件跳转goto_w是宽版本。jsr、ret是早期用于实现 finally 的指令现在已经被编译器用异常表替代了基本可以忽略。tableswitch和lookupswitch用于 switch 语句。tableswitch要求 case 值连续内部用数组直接索引效率高lookupswitch用于稀疏的 case 值内部用二分查找或线性查找。编译器会根据 case 值的分布自动选择用哪个。我实测过一个有 10 个连续 case 的 switch编译出来是tableswitch把 case 值改成 1、100、10000 这种稀疏分布就变成了lookupswitch。tableswitch和lookupswitch的字节码对齐要求比较特殊它们会插入 padding 字节使操作数按 4 字节对齐。这也是为什么在javap输出里看到这两个指令时偏移量有时会跳几个字节。3.7 返回指令与异常处理areturn、athrow 和异常表返回指令按类型分ireturn、lreturn、freturn、dreturn、areturn以及returnvoid 方法。它们都弹出栈顶值void 除外并返回给调用者。异常处理不是靠指令实现的而是靠Code属性里的异常表。异常表是一个数组每项包含start_pc、end_pc、handler_pc、catch_type。当start_pc到end_pc之间抛出catch_type类型的异常时跳转到handler_pc。catch_type为 0 表示捕获所有异常finally 块。athrow指令显式抛出异常它弹出栈顶的异常引用并抛出。如果当前方法没有匹配的异常处理器方法会立即返回并把异常传播给调用者。我分析过一个 try-catch-finally 的字节码发现 finally 块被复制了三份一份在 try 正常结束时执行一份在 catch 块结束时执行一份作为异常处理器捕获所有异常后执行再重新抛出。这个“复制 finally”的策略是早期编译器的做法现在有些编译器会用jsr/ret或者更聪明的跳转来优化但整体思路类似。4. 用真实代码反推字节码三个由浅入深的实战案例4.1 案例一一个简单的 getter 方法藏着多少指令先看最简单的public class Foo { private int value; public int getValue() { return value; } }javap -c输出public int getValue(); Code: 0: aload_0 1: getfield #2 4: ireturn三条指令。aload_0把this压栈getfield #2弹出this读取字段value并压栈ireturn返回。getfield后面跟的#2是常量池索引指向字段引用。这里有个细节getfield占 3 个字节1 字节操作码 2 字节索引所以下一条指令的偏移量是 4不是 2。这就是前面说的变长指令。如果你在分析字节码时按“行号”来算就会对不上。4.2 案例二字符串拼接在 Java 8 和 Java 9 的差异字符串拼接是字节码变化最明显的地方。Java 8 里String s a b c;编译出来是new StringBuilder dup invokespecial StringBuilder.init aload_1 invokevirtual StringBuilder.append aload_2 invokevirtual StringBuilder.append aload_3 invokevirtual StringBuilder.append invokevirtual StringBuilder.toString astore 4Java 9 之后引入了invokedynamic和StringConcatFactory同样的代码编译出来是aload_1 aload_2 aload_3 invokedynamic #7 // makeConcatWithConstants astore 4指令数从十几条降到四条。这个变化我在实际项目中验证过对于大量字符串拼接的场景Java 9 的字节码更短启动时类加载更快运行时StringConcatFactory会生成更高效的拼接策略。但要注意invokedynamic第一次执行有引导开销如果拼接只执行一次可能反而不如 StringBuilder 直接。4.3 案例三Lambda 表达式到底编译成了什么Lambda 是很多人好奇的点。Runnable r () - System.out.println(hi);编译出来invokedynamic #7 // run astore_1就两条。invokedynamic的引导方法会调用LambdaMetafactory.metafactory生成一个实现了Runnable的类这个类在运行时动态生成不会出现在 class 文件里。所以 Lambda 不是匿名内部类不会生成Foo$1.class这样的文件。但这里有个坑如果 Lambda 捕获了外部变量生成的类会持有这些变量的引用行为上和匿名内部类类似。如果没捕获变量生成的类是无状态的可以被缓存复用。我在分析内存占用时发现无捕获的 Lambda 实例在多次调用间是同一个对象而有捕获的每次都会创建新对象。这个差异在高频调用场景下对 GC 有影响。5. 分析字节码时最容易踩的五个坑5.1 偏移量不是行号变长指令让计算变复杂前面提过但值得再强调。javap输出左边的数字是字节偏移不是指令序号。getfield占 3 字节invokeinterface占 5 字节tableswitch还有 padding。如果你要计算跳转目标必须用偏移量不能用行号。我踩过的坑手动计算goto的目标时用行号差乘以平均指令长度结果完全对不上。后来老老实实按字节偏移算才准确。5.2 long 和 double 占两个槽位局部变量表索引会跳long和double在局部变量表里占两个连续槽位。如果第 1 个槽位是 long下一个可用槽位是 3。这个规则在分析参数和方法体时经常让人算错。比如void foo(long a, int b)a在槽位 1-2b在槽位 3。iload_3加载的是b不是a。我第一次分析时以为b在槽位 2结果完全对不上。5.3 常量池索引需要配合 javap -v 才能看懂javap -c只显示指令和常量池索引不显示常量池内容。要看到#2到底是什么需要javap -v。-v会输出常量池、字段描述符、方法描述符等详细信息。我的习惯是先用-c看指令流遇到不认识的索引再用-v查常量池。两个命令配合使用效率最高。5.4 编译器优化会改变指令序列同一个逻辑不同编译器、不同优化级别可能生成不同的字节码。比如int x 1 2;可能被常量折叠成iconst_3也可能保留iconst_1; iconst_2; iadd。final字段的读取可能被内联String常量可能被合并。所以分析字节码时不要假设“源码怎么写字节码就怎么生成”。要以实际javap输出为准。我一般会写一个最小复现的类单独编译单独分析避免其他代码干扰。5.5 异常表和行号表不在指令流里异常处理和调试信息不在code[]数组里而在Code属性的其他字段中。javap -c默认不显示异常表需要-v才能看到。行号表LineNumberTable和局部变量表LocalVariableTable也是-v才显示。分析异常处理逻辑时一定要看异常表不能只看指令流。athrow只是抛出真正的捕获逻辑在异常表里。6. 把指令手册用起来我的日常分析流程和工具链6.1 我的标准分析流程遇到需要分析字节码的场景我一般按这个流程走写一个最小复现类只包含要分析的代码javac -g编译-g保留调试信息javap -c -p看指令流-p显示私有成员遇到不认识的常量池索引javap -v查常量池在纸上画操作数栈和局部变量表的变化对照本文的分类表确认每条指令的类别和作用这个流程看起来笨但最可靠。我试过用各种字节码分析工具最后还是觉得javap加手画最踏实。6.2 值得收藏的几个辅助工具除了javap还有几个工具我偶尔会用ASM字节码操作框架适合做字节码生成和转换但学习曲线陡Byte Buddy更友好的字节码生成库API 设计得很好JBEJava Bytecode Editor图形化字节码编辑器适合直观查看IDEA 的 bytecode viewer 插件直接在 IDE 里看字节码方便快捷但工具只是辅助核心还是理解指令本身。我见过有人用 ASM 生成了错误的字节码排查了半天最后还是靠javap对比正确输出才找到问题。6.3 从指令手册到实际能力的跃迁整理这份手册的过程中我最大的收获不是记住了多少指令而是建立了一种“从字节码反推源码意图”的思维。看到invokedynamic就知道可能有 Lambda 或字符串拼接看到tableswitch就知道是密集 switch看到checkcast就知道有强制类型转换。这种思维在实际工作中有很多应用场景分析性能热点时能看出哪些操作在字节码层面更昂贵排查诡异 bug 时能确认编译器是否做了预期之外的优化做 AOP 或字节码增强时能准确知道要插入指令的位置。我个人的体会是字节码指令手册不是用来背的而是用来查的。你不需要记住两百多条指令但需要知道遇到问题时去哪里查、怎么查、查到了怎么用。这份手册就是按这个思路整理的希望对你也有用。最后分享一个小技巧如果你在分析一个复杂方法的字节码可以先只看方法调用的指令invoke家族把方法的骨架理出来再回头看数据加载和存储指令。这样分层分析比从头到尾逐条看要高效得多。