相关疑难解决方法(0)

类Enum中的方法hashCode()是final,定义为super.hashCode(),这意味着它根据实例的地址返回一个数字,该数字是来自程序员POV的随机数.

将其定义为例如ordinal() ^ getClass().getName().hashCode()跨不同JVM的确定性.它甚至可以更好地工作,因为最低有效位会"尽可能地改变",例如,对于包含多达16个元素的枚举和大小为16的HashMap,肯定没有碰撞(当然,使用EnumMap更好,但有时不可能,例如没有ConcurrentEnumMap).根据目前的定义,你没有这样的保证,对吗？

答案摘要

使用Object.hashCode()比较如上所述的更好的hashCode,如下所示:

• PROS
  • 简单
• CONTRAS
  • 速度
  • 更多冲突(对于任何大小的HashMap)
  • 非确定性,传播到其他对象,使其无法使用
    • 确定性模拟
    • ETag计算
    • 根据例如HashSet迭代顺序搜寻错误

我个人更喜欢更好的hashCode,但恕我直言,没有理由权重,可能除了速度.

UPDATE

我对速度感到好奇并写了一个令人惊讶的结果的基准.对于每个类的单个字段的价格,您可以使用确定性哈希码,其速度快近四倍.将哈希码存储在每个字段中会更快,尽管可以忽略不计.

标准哈希码不快得多的原因是它不能成为对象的地址,因为对象被GC移动了.

更新2

一般来说,表演会有一些奇怪的事情发生hashCode.当我理解它们时,仍然存在未解决的问题,为什么System.identityHashCode(从对象标题读取)比访问普通对象字段慢.

我对Java的String.indexOf(String subString)的性能有疑问.

我编写了一个类来比较调用String.indexOf(String subString)的性能与从String的源内部复制源并使用完全相同的参数调用内部indexOf().

尽管调用堆栈的深度为2帧,但直接调用String.indexOf()时性能似乎提高了约4倍.

我的JVM是JDK1.7.0_40 64bit(windows hotspot).我的机器运行Windows,配备i7-4600U CPU,16GB内存.

这是代码:

import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
import java.util.concurrent.atomic.AtomicBoolean;
import java.util.concurrent.atomic.AtomicLong;

public class TestIndexOf implements Runnable {

  final static String s0 = "This is my search string, it is pretty long so can test the speed of the search";
  final static String s1 = "speed of the search";
  final static char[] c0 = s0.toCharArray();
  final static char[] c1 = s1.toCharArray();
  final static byte[] b0 = s0.getBytes();
  final static byte[] b1 = s1.getBytes();

  static …