hashmap.put()
特定のスタックでコストがかかることが証明されていることを示唆しているように見えるいくつかの yourkit スナップショットについて混乱しています。
このマップのキーが、オーバーライドされていない非常に複雑なオブジェクトであるとしますequals()
。hashCode()
特定の状況でコストがかかる、HashMap.hash()
またはコストがかかる可能性は本当にありますか?Object.hashCode()
HashMap に入れるのにコストがかかるオブジェクトを作成することは確かに可能です。
class Awful {
@Override
public int hashCode() {
try {
Thread.sleep(10000000);
} catch (InterruptedException e) {
Thread.currentThread().interrupt();
}
return 1;
}
}
明らかにこれは不自然な例ですが、Hibernate でサポートされ、遅延ロードされたオブジェクトでメソッドを呼び出す実装を見てきました。このオブジェクトをリストに入れると、多数の非常にコストのかかるデータベース ルックアップが発生しました。
オーバーライドhashCode()
しないと、メソッドが呼び出された時点で JVM がすでに持っているオブジェクトのアドレスから値が導出されるため、(同様に) インスタントです。
put
ハッシュコードの計算ではなく、プロファイラーがホットスポットとして示したとあなたは言いました。put
ハッシュコードの決定だけではありません。特に、マップが非常に大きい場合、多くのハウスキーピング作業が行われます。put
そして、コードが他にほとんど何もせず、膨大な回数の呼び出しを行う場合、当然、これがプロファイラーにホット スポットとして表示されます。ただし、そのパフォーマンスには何の問題もないかもしれません。
理論的には可能ですが、可能性は非常に低いです。
実際に使用している場合Object.hashcode()
、そのデリゲートSystem.identityHashCode(Object)
は比較的安価です。さらに、ID ハッシュコードによって衝突のホットスポットが発生することはありません...本当に運が悪い場合を除きます。
HashMap.hash()
およびでパフォーマンスのホットスポットが見られる場合Object.hashCode()
、その理由はおそらく、多くのHashMap
ルックアップを行っていることです。