TERASOLUNA Framework

まず、ハッシュ衝突や配列拡張のモニタを行うことで、少なからず Map の性能は低下するものと考えます。

一方でハッシュ衝突が必ずしも性能劣化のボトルネックとなりえないケースもあります。
ハッシュ関数のみならず、ハッシュテーブル領域作成のメモリアロケートと
rehash にかかるコストについても考慮が必要となります。
(HashMap.Entryの初期サイズは、コンストラクタで指定可能な初期容量 * 負荷係数
のバイトサイズ配列として確保されます。)

そのため、以下の2点につきましては何をもって最適解とするかで、
Map の実装は大きく異なってくるものと考えます。

1. ハッシュ関数の算出
2. ハッシュテーブルの管理

Java SE APIでも、ConcurrentHashMap や、LinkedHashMap、
IdentityHashMap などの Map 実装が複数用意されており、機能として
重視したいものに応じて利用するのが一般的と考えます。

一方で、内部のモニタリングにつきましては Bug Database でも RFE が提出されています。

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6654502


HashMap を用いたハッシュ値算出の検証については、Object#hashCode()
が利用されるため、Map内のエントリとなりうるオブジェクトに対して
このメソッドをオーバライドすることで、
必要に応じて衝突しづらくしたり、HashMap のソースコードから実際の
ハッシュ値をモニタすることは可能であると考えます。

参考：
http://www.asp-edita.jp/doda/one/doda7204_118.html

# 一方で Java SE 6 現在、上記記事によると、Object#hashCode() を
# 常に1とすることで内部ハッシュ値も1となり、
# 必ず衝突が発生するため、これを用いた性能比較も可能だと考えます。