我最近对 Integer.bitCount 做了一些调查。我发现一个有趣的结果是 Integer.bitCount 比我自己的 func 快得多,甚至代码都是一样的。我以为是 JIT 的原因,但我查了文档,发现 JIT 是基于运行时策略的。这让我很困惑。public static void main(String[] args) { long sum = 0; long start, end; start = System.currentTimeMillis(); for (int i = Integer.MIN_VALUE; i != Integer.MAX_VALUE; i++) { sum += bitCount(i); //sum += Integer.bitCount(i); } end = System.currentTimeMillis(); System.out.println(sum); System.out.println(end - start);}private static int bitCount(int i) { i = i - ((i >>> 1) & 0x55555555); i = (i & 0x33333333) + ((i >>> 2) & 0x33333333); i = (i + (i >>> 4)) & 0x0f0f0f0f; i = i + (i >>> 8); i = i + (i >>> 16); return i & 0x3f;}// 对于 bitCount 结果687194767368715// 对于 Integer.bitCount 结果687194767361892
1 回答

慕田峪9158850
TA贡献1794条经验 获得超7个赞
您的基准不准确。但不管这一点,一个原因是因为Integer#bitCount
被标记为@HotSpotIntrinsicCandidate
。这意味着 HotSpot JVM 可以用汇编代码替换方法体来提高性能。从注释的源代码:
@HotSpotIntrinsicCandidate
注释特定于 HotSpot 虚拟机。它表明带注释的方法可能(但不保证)被 HotSpot VM 内在化。如果 HotSpot VM 将带注释的方法替换为手写程序集和/或手写编译器 IR(编译器固有的)以提高性能,则方法被内在化。注释是 Java 库内部的@HotSpotIntrinsicCandidate
,因此不应该与应用程序代码有任何关联。
尝试禁用内在函数并再次运行测试;您应该会看到显着放缓。
添加回答
举报
0/150
提交
取消