字节码指令 tableswitch 与 lookupswitch：分析 switch-case 在索引连续与离散场景下的转换逻辑

Ja va编译器在处理switch-case结构时，并不会简单地把代码原样编译。它内部有一套精密的判断机制——根据case值的分布密度，自动决定生成tableswitch还是lookupswitch指令。这两条指令，本质上都是JVM为跳转优化准备的“翻跟斗”，但各自的适用场景、空间和时间成本，可是泾渭分明。

说白了，这就是编译器在“空间换时间”和“时间换空间”之间做的一个智能权衡。

tableswitch：专为“连续或紧凑”的case值设计

如果你的case常量凑成了一个跨度小、基本连续的整数区间，比如 0、1、2、4、5（最大最小值差仅为5），那么编译器会毫不犹豫地选择tableswitch指令。

它的工作逻辑非常直接：

• JVM会先算出两个关键值——low（最小case值）和high（最大case值）。
• 然后，它会为从low到high之间的每一个整数，都预分配一个跳转偏移量的“槽位”。注意，这包括那些你没有显式声明case的“空缺值”。
• 运行时，程序直接用switch表达式的值减去low，当作索引去查这个跳转表。命中，就跳转；没命中，就跳转到default。
• 这种查表操作的时间复杂度是O(1)，非常快。但代价是，内存占用与high - low + 1成正比。如果跨度太大，即使只有几个case，也会造成大量内存浪费。

lookupswitch：为“稀疏或跨度大”的case值而生

当case值分布得很分散、间隔很大，或者数量相对较少时（比如 100、1000、99999），编译器就会转向lookupswitch指令。

它的工作方式更像个精明的“档案管理员”：

• 内部维护着一张已按case值升序排列的键值对列表：match: offset。
• 运行时，对这个有序列表进行二分查找。找到匹配的case，就跳转到对应分支；找不到，同样跳到default。
• 它的优点很明显：只存储实际出现的case条目，再加上一个default条目，空间占用极小。
• 代价是时间复杂度变成了O(log n)，其中n是case的数量。不过，当case数量n很小时，这个性能差异几乎可以忽略不计。

如何验证你的代码走了哪条路？

想知道你的switch-case到底被编译成了哪条指令？很简单，编译Ja va源码后，用ja vap -c命令去反编译一下class文件，一切都会真相大白：

• 如果你看到tableswitch关键字，后面跟着low、high和一长串的offset列表，恭喜，编译器给你的case值启用了跳转表。
• 如果你看到的是lookupswitch关键字，后面是npairs（键值对总数），以及成对的match: offset，说明你的case值太分散，走了二分查找的路线。
• 顺便提一句，即便是String类型或枚举类型的switch，底层也会先被转换成整数运算，最终还是会落入这两种指令之一。

编译器究竟看什么来决策？

这个判断逻辑其实很有意思——ja vac并不依赖case数量的绝对值，而是非常关注“密度”这个指标。

• 哪怕你只有3个case，但如果分别是1、100、10000，那基本会选lookupswitch。
• 反过来，哪怕你有10个case，但它们的值恰好是0~9或者100~109这种密集连续的区间，那几乎肯定触发tableswitch。
• 另外，default分支是否存在，或者它放在哪里，都不会影响指令类型的选择。它仅仅是一个兜底的跳转目标。