Java switch编译后根据case值连续性选择tableswitch（O(1)查表）或lookupswitch（O(log n)二分），非语法决定快慢；连续小范围用tableswitch，稀疏大跨度用lookupswitch。
Java 中的 switch 语句在编译后不总是生成统一的字节码指令，而是根据 case 值的分布特征，由 javac 编译器自动选择 tableswitch 或 lookupswitch 指令。这种选择直接影响运行时跳转性能——不是语法写法决定快慢，而是整型常量的“连续性”和“稀疏度”起关键作用。
tableswitch：适用于紧凑、连续的整数范围
当 switch 的所有 case 值构成一个较密集的区间（例如 case 1 到 case 10，中间最多缺少数个值），且最小值与最大值之差不太大（通常不超过约 256，具体阈值由 javac 实现策略决定），编译器会生成 tableswitch 指令。
它底层采用“查表跳转”方式：
- 构建一张跳转地址表，索引为从
low到high的每个整数（含空位） - 运行时直接用表达式结果减去
low作为数组下标，O(1) 时间完成分支定位 - 若结果超出范围，跳转到 default 分支（表中已预留）
例如：switch(n) { case 5: ... case 6: ... case 7: ... } 很可能生成 tableswitch low=5, high=7，仅需一次减法 + 一次查表。
lookupswitch：适用于稀疏、跨度大的整数集合
当 case 值分散（如 case 1、case 100、case 1000）、或数量少但跨度极大（如最小值 0、最大值 100000），编译器会选用 lookupswitch。
它本质是**有序键值对二分查找**：
- 字节码中内嵌一组升序排列的
(key, offset)对 - 运行时对输入值在该列表中执行二分搜索，找到匹配 key 后跳转到对应 offset
- 时间复杂度为 O(log n)，n 是 case 数量
虽然比 tableswitch 多几次比较，但避免了为大量空值分配内存，空间效率更高。
编译器如何决策？看实际字节码最准
javac 不公开精确阈值，但可通过 javap -v 观察生成结果：
- 若看到
tableswitch，说明编译器判断“值够密、范围够小” - 若看到
lookupswitch，说明它认为建表不划算（要么太稀疏，要么范围爆炸） - 即使你写了连续的 case，若中间有大量未使用的 int（比如只用
case 1和case 1000000），仍会走lookupswitch
注意：String、enum 的 switch 会被编译为先调用 hashCode() 再套一层 switch(int)，最终仍落入上述两种指令之一。
对开发者的实际启示
不必手动优化 switch 写法去“讨好”编译器，但可借助规律做合理预期：
- 枚举状态码、状态机序号等天然连续的小整数集，大概率触发
tableswitch，性能稳定 - 协议字段、错误码若编号跳跃严重（如 0x01, 0x10, 0xFF），更倾向
lookupswitch，但 log n 仍远快于链式 if-else - 极端稀疏场景（如仅 3 个 case，跨度超百万），
lookupswitch的二分开销几乎可忽略，无需担忧 - 若真遇到热点分支性能瓶颈，优先考虑是否该用查表（HashMap）或状态模式替代，而非调整 case 排列
理解这两种指令，不是为了手写字节码，而是看清 Java “语法糖”之下真实的时间/空间权衡逻辑。
