为什么Java空String的hashCode为0？能否设为非零值与null区分？

• 这个改动从根源上就达不到你预期的设计目标
  你想靠把空String的哈希从0改成1，实现和null的哈希值做区隔，但实际上JDK里本来就有大量非空String的哈希计算结果就是0——比如特定长度、特定字符组合的字符串，完全可能触发哈希值为0的结果。哪怕你把空String的哈希硬改成1，这些非空的、哈希为0的String实例，依然会和Objects.hashCode(null)返回的0值产生哈希重叠，根本没法实现“彻底把String类实例和null的哈希做区分”的效果。
• 会打破String类自诞生以来保持的统一哈希计算逻辑
  String的哈希值一直严格遵循统一的多项式计算公式。按照数学上的空和定义，长度为0的字符串所有项求和的结果天然就是加法单位元0，这是整个公式逻辑的自然延伸，不是专门给空字符串做的特殊设计。如果硬给空字符串赋值1的哈希，相当于在通用计算逻辑之外给空字符串加了无意义的特殊分支，后续所有涉及String哈希的性能优化、碰撞概率分析工作，都要单独给空字符串做逻辑适配，平白增加开发和维护的心智负担。
• 跨类型的哈希值对齐没有任何实际收益
  你提到想让空String的哈希和Arrays.hashCode(Object[])的空数组计算结果（也就是1）保持一致，本质是对不同类型对象的哈希规则提了不必要的强求。Java对hashCode的唯一强制要求是：同一个类的两个实例如果equals()返回true，它们的hashCode()必须返回相同值。跨类的哈希值从来没有对齐要求——比如空ArrayList的哈希是1，空数组的哈希是1，但空HashMap的哈希就是0，总不能为了“对齐”把所有空集合类的空实例哈希全改成同一个值吧？这种对齐没有任何功能价值，反而会让各个类的哈希实现失去设计上的自洽性。
  另外要明确：null根本不是Java类体系里的任何对象实例，Objects.hashCode(null)返回的0只是工具方法的容错兜底值，不是什么需要和业务对象对齐的“标准哈希值”。正常的哈希表（比如HashMap）处理null key的时候走的是完全独立的分支逻辑，根本不会调用String类的hashCode()方法，本来就不存在混淆的可能。
• 改动会带来不必要的运行时开销
  结合你贴的JDK 11的String.hashCode()源码就能看出来，现在的哈希缓存逻辑是依托hash字段的默认值0实现的：代码里的判断条件是h == 0 && value.length > 0才会触发实际的哈希计算，空字符串因为底层value数组长度为0，会直接跳过判断分支，返回字段默认值0就行，完全零计算成本。如果要把空字符串的哈希值改成1，就需要在方法逻辑里单独加一个空字符串的分支判断，还要在所有空字符串的创建路径（包括常量池加载、运行时创建的空实例）里显式给每个实例的hash字段赋值为1。别觉得这点开销小，String是JDK中被调用频率最高的类之一，哪怕每次hashCode()调用多一个判断分支、每个空字符串多一次字段赋值，累计下来的性能损失都非常可观，完全得不偿失。

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