在Java中默认的Long.hashCode实现下有什么假设？

Question

我们知道在Java中用long值创建哈希码的推荐方法是

(int) (this.longValue()^(this.longValue()>>>32))

然而，用long值创建哈希码的另一种可能方法就是

(int) this.longValue() 

如果我们一起考虑从Long.MIN_VALUE到Long.MAX_VALUE的所有长篇，那么函数

(int) this.longValue()

基本上会生成以下值：

1. 范围为[Integer.MIN_VALUE; Integer.MAX_VALUE]

2. 我不确定100％，但值可能会均匀分布

因此，如果我们不是在谈论特殊情况，例如在一个long中存储两个int并分别处理高位和低位字节 - 为什么我们最终使用按位运算而不是简单地使用int部分？

有指导方针吗？或者也许有一些潜在的理论？

类似的问题已在Bit-shifting in Effective Java hashCode() implementation中提出，但引用自那里：

  

你可以采用底部的32位 - 但这意味着只会忽略前32位的变化，这不会使它成为一个非常好的散列。

所以我特别感兴趣的是，为什么选择最后32位并不会使它成为一个非常好的哈希值。