Java为什么您的switch语句数据类型不能很长？

这是Sun的Java教程的摘录：

一种开关用的工作原理byte，short，char，和int原始数据类型。它还与枚举类型（在类和继承讨论）和少数特殊类作品是“包装”某些基本类型：Character，Byte，Short，和Integer（在简单的数据对象讨论）。

一定有充分的理由为什么long不允许原始数据类型。有人知道这是什么吗？

我认为在某种程度上，这可能是基于开关的典型用法的任意决定。

切换基本上可以通过两种方式（或原则上是组合）来实现：对于少数情况或值分散的情况，切换本质上等同于临时变量上一系列if的等效项（开启的值仅需评估一次）。对于数量或多或少连续的中等数量的情况，使用切换表（Java中的TABLESWITCH指令），从而在表中有效地查找要跳转到的位置。

这些方法中的任何一种原则上都可以使用长值而不是整数。但是我认为这可能是在实际需要之间平衡指令集和编译器的复杂性的一个实际决定：真正需要长时间切换的情况非常罕见，以至于必须将其重写为系列IF语句，或以其他方式工作（如果所讨论的长值彼此靠近，则可以在Java代码中切换减去最小值的int结果）。

因为他们没有在字节码中实现必要的指令，并且您确实不想编写那么多情况，无论您的代码多么“生产就绪”……

[编辑：摘自对此答案的评论，并在背景中添加了一些内容]

确切地说，2³²是很多情况，任何程序只要其方法足以容纳更多内容，那将是非常可怕的！任何语言。（我在任何语言中的任何代码中最长的功能都超过6k SLOC，是的，这是一个很大的功能switch，而且确实难以管理。）如果您真的long对只能拥有一个int或更少的位置感到困惑，那么您有两个真正的选择。

1. 使用哈希函数主题的一些变体将压缩long为int。仅当类型错误时才使用的最简单方法就是强制转换！更有用的是这样做：

   (int) ((x&0xFFFFFFFF) ^ ((x >>> 32) & 0xFFFFFFFF))
   

   在打开结果之前。您还必须弄清楚如何转换要测试的案例。但是，实际上，这仍然很可怕，因为它没有解决很多案件的真正问题。

2. 如果要处理大量案例，一个更好的解决方案是将设计更改为使用aMap<Long,Runnable>或类似名称，以便您查找如何分配特定值。这样，您就可以将案例分为多个文件，当案例数变大时，管理起来要容易得多，尽管组织涉及的许多实现类的注册确实变得更加复杂（注释可以帮助您自动建立注册码）。

   FWIW，我是在很多年前（在整个项目过程中部分切换到新发布的J2SE 1.2）这样做的，当时，我构建了一个用于模拟大规模并行硬件的自定义字节码引擎（不，由于根本原因，重用JVM是不合适的）涉及不同的价值和执行模型），并且相对于switchC版本的代码正在使用的代码，它大大简化了代码。

重申switch一句，要想带回家，long这表明您在程序中输入了错误的类型，或者您正在构建的系统涉及很多变化，因此应该使用类。无论哪种情况，都需要重新考虑的时间。

因为查找表索引必须为32位。

在32位体系结构中，long由两个词表示。现在，想象一下如果由于同步不充分而发生什么情况，switch语句的执行观察到一个long，一次写入高32位，而另一次写入32低！它可以尝试去....谁知道呢！基本上是随机的。即使两个写入都代表switch语句的有效情况，但它们的滑稽组合可能不会导致第一个或第二个情况发生-甚至更糟的是，它可能导致另一个有效但无关的情况！

至少对于int（或更小的类型）而言，无论您搞砸了多厉害，switch语句至少会读取某人实际写的值，而不是“凭空”的值。

当然，我不知道真正的原因（已经超过15年了，我一直没有关注这么长的时间！），但是如果您意识到这种结构可能多么不安全和不可预测，您将同意这是一个绝对很好的理由不要永远对多头开关（而且只要-pun intended-会有32吨的机器，因此仍然有效）。