我一直在看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)是可变的.
原文地址:https://www.jb51.cc/java/124729.html
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。