Java 分析：java.lang.Object.hashCode 占用一半的 CPU 时间但从未显式调用
我已经使用 -agentlib:hprof=cpu=samples 对我的多线程程序进行了基准测试 并惊讶地在结果中发现以下行：
rank self accum count trace method
1 52.88% 52.88% 8486 300050 java.lang.Object.hashCode
我从未在程序中显式调用 hashCode() 。 这可能是什么原因？如何了解这次“浪费”的根源以及是否正常？
谢谢， 大卫
I have been benchmarked my multihreaded program using -agentlib:hprof=cpu=samples
and was surprised to find the following line in the results:
rank self accum count trace method
1 52.88% 52.88% 8486 300050 java.lang.Object.hashCode
I never explicitly call hashCode() in my program.
What can be the reason for this? How can I understand the source for this time "waste" and whether it is normal or not?
Thanks,
David
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
您很可能非常频繁地使用 Map，例如 HashMap。
HashMap 使用
hashCode来分布对象。如果您使用具有此数据结构的许多对象，则正确实现.equals和.hashCode方法非常重要。请参阅：Effective Java Item 8：当您覆盖 equals 时始终覆盖 hashCode
Most likely you're using very intensively a Map such as a HashMap.
HashMap used the
hashCodeto distribute the objects. If you're using many objects with this data structure, is very important your.equalsand your.hashCodemethod are properly implemented.See: Effective Java Item 8: Always override hashCode when you override equals
您应该做的一件事是检查匹配的堆栈跟踪以查看谁在调用它；变化是它确实是HashMap。
但除此之外，我注意到 hprof 往往会大大高估对 hashCode() 的调用；我真的很想知道如何以及为什么。这是基于实际了解代码的粗略性能概况；我已经看到 50% 的 cpu 使用率（通过采样），几乎可以肯定它绝对不会花那么长时间。 hashCode() 的实现仅返回一个 int 字段，并且方法是最终的（在最终对象上）。
所以它基本上是某种分析器工件......只是不知道如何或为什么，或如何摆脱它。
One thing you should do is to check out matching stack trace to see who is calling it; changes are it is indeed HashMap.
But beyond this, I have noticed that hprof tends to vasty overestimate calls to hashCode(); and I really would like to know how and why. This is based on actually knowing rough performance profile of code; and I have seen 50% percent cpu use (by sampling), where it is all but certain that it absolutely will not take that long. Implementation of hashCode() just returns an int field, and method is final (on final object).
So it is basically a profiler artifact of some sort... just no idea how or why, or how to get rid of it.
HashSet 被实现为将键映射到自身的 HashMap，因此切换到 HashSet 在性能方面不会产生太大差异。
其他替代方案是 TreeSet 或（假设您的应用程序永远不会尝试插入重复项）List 类之一。如果您的应用程序支持 List，那么 ArrayList 或 LinkedList 将比 HashSet 或 TreeSet 更有效。
然而，您的应用程序将 50% 的时间花费在
hashCode方法上，这非常可疑。除非调整哈希表的大小，否则每个 set 或 map 操作只能调用一次 hashCode 方法。因此，要么正在进行大量的地图/集合大小调整，要么您正在执行大量的集合添加操作。 （据我所知，对象哈希码方法很便宜，因此每次调用的成本不应该成为问题。）编辑
不，它并不贵。看一下代码。 Random 类（和 nextInt() 方法）确实使用 AtomicLong 来使其线程安全，如果您编写了非线程安全版本，则可能会节省一些周期。源代码在你的JDK安装目录...看一下。
A HashSet is implemented as a HashMap that maps the key to itself, so switching to a HashSet won't make much difference, performance-wise.
The other alternatives are a TreeSet, or (assuming that your application will never try to insert a duplicate) one of the List classes. If your application is such that a List will work, then an ArrayList or LinkedList will be more efficient than either a HashSet or TreeSet.
However, there is something very fishy about your application spending 50% of its time in
hashCodemethods. Unless the hash tables are resized, the hashCode method should only be called once per set or map operation. So either there is a lot of map/set resizing going on, or you are doing huge numbers of setaddoperations. (AFAIK, the Object hashcode method is cheap, so the cost of each call should not be an issue.)EDIT
No it is not expensive. Take a look at the code. The Random class (and the nextInt() method) does make use of an AtomicLong to make it thread-safe, and you might save a few cycles if you coded a non-thread-safe version. The source code is in your JDK installation directory ... take a look.