我一直在看JDK中ThreadLocal的实现,出于好奇,我发现这一点：
/**
* Increment i modulo len.
*/
private static int nextIndex(int i,int len) {
return ((i + 1 < len) ? i + 1 : 0);
}
看起来很明显,这可以用简单的回报(i 1)％len实现,但我认为这些人知道他们的东西.任何想法为什么他们这样做？
此代码高度针对性能,具有用于持有线程本地映射的自定义映射,弱引用以帮助GC变得聪明等等,因此我猜这是一个性能问题. Java中的模数慢吗？
解决方法
在本例中出于性能原因避免了％.
即使在cpu架构级别,div / rem操作也较慢;不仅在Java中例如,Haswell上的idiv指令的最小延迟大约是10个周期,但是只有1个循环.
让我们用JMH进行基准测试.
import org.openjdk.jmh.annotations.*;
@State(Scope.Benchmark)
public class Modulo {
@Param("16")
int len;
int i;
@Benchmark
public int baseline() {
return i;
}
@Benchmark
public int conditional() {
return i = (i + 1 < len) ? i + 1 : 0;
}
@Benchmark
public int mask() {
return i = (i + 1) & (len - 1);
}
@Benchmark
public int mod() {
return i = (i + 1) % len;
}
}
结果：
Benchmark (len) Mode Cnt score Error Units Modulo.baseline 16 avgt 10 2,951 ± 0,038 ns/op Modulo.conditional 16 avgt 10 3,517 ± 0,051 ns/op Modulo.mask 16 avgt 10 3,765 ± 0,016 ns/op Modulo.mod 16 avgt 10 9,125 ± 0,023 ns/op
你可以看到,使用％比条件表达式慢〜2.6倍. JIT无法在讨论的ThreadLocal代码中自动优化,因为除数(table.length)是可变的.
