Java基本类型直接操作栈中局部变量槽，包装类则通过invokestatic调用valueOf在堆上创建对象并存引用；装箱拆箱是编译器插入的显式方法调用，非JVM隐式转换；instanceof仅支持引用类型，因字节码验证要求操作数必须为常量池中的类引用。
Java 中基本类型与包装类在字节码层面的差异，核心在于 JVM 如何为它们分配内存、生成指令以及处理值传递——这不是语法糖的表面区别，而是运行时行为的根本分野。
栈 vs 堆：字节码直接暴露存储位置
基本类型变量的声明和赋值，字节码使用 局部变量表操作指令（如 istore_1、lconst_1、fstore），所有值直接压入栈帧的局部变量槽中，不涉及对象创建：
-
int x = 42;→ 编译为iconst_42+istore_1 -
double y = 3.14;→ 编译为dconst_3.14+dstore_2
而包装类型（如 Integer）本质是引用类型，字节码必须调用静态工厂方法并分配堆空间：
-
Integer n = 42;→ 编译为iconst_42+invokestatic Integer.valueOf(int)+astore_1 -
Long l = 100L;→ 编译为lconst_100+invokestatic Long.valueOf(long)+astore_2
关键证据：invokestatic 指令明确表明对象创建发生在堆上，栈中仅保存引用（astore 操作的是引用槽，不是数值槽）。
立即学习“Java免费学习笔记（深入）”；
自动装箱/拆箱：字节码里没有“自动”，只有显式方法调用
所谓“自动”只是编译器的语法糖。反编译后可见，所有装箱都等价于 valueOf() 调用，所有拆箱都等价于 xxxValue() 方法调用：
Java Maven Common
下载
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
-
Integer a = 10; int b = a;→ 实际是Integer.valueOf(10)和a.intValue() - 若对 null 的包装类执行拆箱（如
Integer x = null; int y = x;），字节码中invokevirtual Integer.intValue()在运行时抛出NullPointerException
这说明：装箱/拆箱不是 JVM 的隐式转换机制，而是编译器强制插入的、可被调试器单步跟踪的方法调用。
instanceof 限制：字节码验证器拒绝基本类型操作
instanceof 是 JVM 指令（instanceof 字节码），其操作数必须是引用类型常量池项（cp_info 中的 CONSTANT_Class_info）。JVM 规范明确要求：
- 基本类型（
int、byte等）无对应类符号，无法出现在常量池的类引用位置 - 因此编译器在遇到
if (x instanceof int)会直接报错，连字节码都不会生成 - 只有包装类（如
Byte）作为java.lang.Class的实例，才能通过字节码验证
这个限制从字节码校验阶段就已固化，不是运行时逻辑，也非设计疏漏，而是 Java 类型系统在 JVM 层的刚性体现。
性能痕迹：字节码长度与 GC 压力可量化
对比相同逻辑的两种写法：
- 基本类型循环累加：10 条以内字节码，纯栈操作，零对象分配
- 包装类型循环累加：每轮增加至少 3 条字节码（
iconst→invokestatic valueOf→invokevirtual xxxValue），且触发频繁的小对象分配，堆压力显著上升
这些差异在 javap -c 输出中一目了然，无需 profiler 就能判断性能瓶颈来源。
