数组作为switch case替代方案的内存与时间复杂度性能对比

针对你给出的星期映射场景，两者的差异如下：

时间复杂度表现 #

• 数组映射方案：时间复杂度为O(1)。数组是连续内存结构，直接通过下标偏移量就能定位到对应元素，没有任何分支判断逻辑，运行效率稳定，不会出现性能波动。
• switch分支方案：JVM会根据分支值的分布选择不同的编译策略：
  • 如果分支值是连续整数（就像你的示例里0-6的取值），会编译为tableswitch指令，时间复杂度也是O(1)，但需要多执行一次分支跳转操作，还有概率出现CPU分支预测失败的额外损耗，实际运行速度比数组方案慢。
  • 如果分支值是不连续的离散值，会编译为lookupswitch指令，需要通过二分查找匹配对应分支，时间复杂度为O(log n)，n是分支数量，分支越多效率越低。

内存占用表现 #

• 数组映射方案：你示例中用到的所有星期字符串都是字符串常量，类加载时就已经存放在字符串常量池，不会重复创建。数组本身只存储7个字符串引用，64位JVM开启指针压缩的情况下每个引用占4字节，总共只需要28字节的额外内存，开销可以忽略不计。
• switch分支方案：不需要存储数组引用，但编译后的字节码会包含完整的分支跳转表，你的7分支示例生成的字节码体积比数组方案大30%左右，不过运行时的内存差异极小，普通业务场景下基本感知不到。

实际使用建议 #

只要映射的key是从0开始的连续整数，都优先推荐用数组映射方案，不仅代码更简洁，可维护性也更高：后续需要新增/修改映射规则的时候，只需要调整数组内容即可，不用增删case分支，也能避免漏写break导致的逻辑错误。

内容的提问来源于stack exchange，提问作者Punish_me_er