jvm底层用int指令处理byte和short运算，本质是因指令集限制（opcode仅1字节）、局部变量表槽位固定32位、以及执行效率优化而做的统一调度折衷，并非类型自动升级。
Java虚拟机底层用 int 指令处理 byte 和 short 运算，不是因为它们“本来就是 int”，而是 JVM 在指令集设计、内存布局和执行效率之间做的务实折衷。这种设计既节省资源，又保持语义正确，但初看容易误解为“类型被自动升级”——其实本质是“统一按 int 规格调度”。
指令数量限制倒逼类型归并
JVM 指令的操作码（opcode）只有 1 个字节，最多支持 256 条指令。如果为 byte、short、char 各自设计全套算术指令（如 badd、sadd、cadd），光加法就要占掉至少 3 条；再叠加减法、乘法、比较等，指令总数会迅速突破上限。于是 JVM 选择：
- 只保留 iadd、isub、imul、iand 等以
i开头的 int 指令族； - 编译期就把 byte/short 值当作 int 加载（如 iload_0），后续所有运算都走 int 指令路径；
- 真正需要窄化结果时（比如存回 byte 变量），才显式插入
i2b或i2s转换指令。
局部变量表天然适配 32 位宽度
局部变量表每个槽位固定占 32 位（4 字节），无论存的是 byte 还是 int：
- 一个
byte a = 10;编译后，实际在局部变量表中仍占满 4 字节； - 读取时直接用
iload_0把这 4 字节当 int 加载到操作数栈； - 没有额外“拆包”或“补位”开销，硬件层面也更友好。
既然存储已按 int 对齐，运算再单独为小类型设指令，反而增加实现复杂度，得不偿失。
运算过程隐含零扩展或符号扩展
byte 和 short 是有符号类型，但 JVM 不会在每条指令里重复判断符号位。它把扩展逻辑前移到加载阶段：
-
bipush 100→ 直接压入 int 值 100（正数，高位补 0）； -
sipush -1→ 压入 int 值 -1（即 0xffffffff），符号位自然延伸； - 后续
iadd对这两个 int 值运算，结果仍是 int； - 若需截断回 byte，
i2b仅取低 8 位，并按补码规则解释——这步才是真正的类型转换。
开发者感知与实际执行存在分层
写代码时 byte a = 1; byte b = 2; byte c = (byte)(a + b); 看似在做 byte 运算，但字节码里实际是：
- iload_0（加载 a，已是 int）
- iload_1（加载 b，已是 int）
- iadd（int 加法）
- i2b（截断为 byte）
- istore_2（存入 c）
所谓“类型提升”只是 Java 语言规范对开发者隐藏了这一层统一调度机制，JVM 底层从未真正运行过独立的 byte 指令。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
