问为什么您的switch语句数据类型不能是long，Java？

EN

我认为在某种程度上，这可能是基于switch的典型用法而做出的武断决定。

开关基本上可以通过两种方式(或原则上，一种组合)来实现:对于少数情况，或者值广泛分散的情况，开关本质上等同于临时变量上的一系列if(打开的值只能计算一次)。对于值或多或少连续的中等数量的情况，使用切换表(Java中的TABLESWITCH指令)，从而在表中有效地查找要跳转到的位置。

原则上，这两种方法都可以使用长值而不是整数。但我认为这可能只是为了平衡指令集和编译器的复杂性与实际需要的实际决定:您确实需要切换到长值的情况非常罕见，因此可以接受将其重写为一系列IF语句，或者以其他方式变通(如果所讨论的长值很接近，则可以在Java代码中切换为减去最低值后的int结果)。

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

编辑:摘自对此答案的评论，并在背景上添加了一些内容

准确地说，2³²是一个lot的案例和任何程序的方法足够长，以容纳更多将是完全可怕的！任何一种语言。(据我所知，在任何语言的代码中，最长的函数是略高于6k的SLOC -是的，它是一个很大的switch -而且它真的很难管理。)如果您真的坚持只有一个int或更少的long，那么您有两个真正的选择。

1. 使用散列函数主题的一些变体来将long压缩为int。最简单的方法就是强制转换，只有在类型错误的时候才会使用！更有用的做法是：

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

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

• 如果你处理大量的情况，一个更好的解决方案是将你的设计更改为使用Map<Long,Runnable>或类似的东西，这样你就可以查找如何分派一个特定值。这允许您将案例分离到多个文件中，当案例数量变大时，这将更容易管理，尽管组织所涉及的实现类主机的注册会变得更加复杂(注释可能会通过允许您自动构建注册代码来帮助您)。

顺便说一下，我在很多年前就这样做了(我们在项目中途切换到了新发布的JVM1.2)，当时我构建了一个用于模拟大规模并行硬件的自定义字节码引擎(不，重用J2SE并不适合，因为涉及的值和执行模型完全不同)，并且相对于C版本代码使用的大switch，它极大地简化了代码。

为了重申这一要点，想要在long上执行switch，这表明您要么在程序中搞错了类型，要么您正在构建的系统中包含了如此多的变体，因此您应该使用类。无论是哪种情况，都是时候重新考虑了。

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