を使用TreeMapして custom を提供するのは簡単です。したがって、マップに追加されたオブジェクトComparatorによって提供されるセマンティクスをオーバーライドします。ただし、この方法では制御できません。ハッシュ値と等価性チェックを提供する関数は「サイドロード」できません。ComparableHashMap

HashMapインターフェイスを設計し、これを（または新しいクラスに）改造するのは簡単で便利だと思いますか？より良い名前を除いて、このようなもの：

大文字と小文字Mapを区別しない問題には、簡単な解決策があります。

これは実行可能でしょうか、それともこのアプローチに根本的な問題があると思いますか?

このアプローチは、既存の (JRE 以外の) ライブラリで使用されていますか? （グーグルを試してみましたが、うまくいきませんでした。）

編集: hazzen によって提示された素晴らしい回避策ですが、これは私が回避しようとしている回避策です... ;)

編集: タイトルを変更して、「コンパレーター」について触れないようにしました。これは少し混乱したと思います。

編集：パフォーマンスに関連して受け入れられた回答。より具体的な答えが欲しいです！

編集: 実装があります。以下の受け入れられた回答を参照してください。

編集:最初の文を言い換えて、それが私が求めているサイドローディングであることをより明確に示します(順序付けではありません。順序付けは HashMap に属しません)。

Troveコレクションの一部に変更不可能なラッパーを配置したいと思います。Troveのドキュメントを確認しましたが、簡単な方法が見つからないようです（明らかなことを見落としている可能性があります）。

したがって、現時点では、このような変更不可能なラッパーが必要になるたびに、Troveコレクション（TIntLongHashMapなど）を拡張し、すべての読み取り専用呼び出しをTroveラップされたサブジェクトに委任し、コレクションを変更しようとするすべてのメソッドでUnsupportedOperationExceptionをスローします。 。

もっと簡単な方法はありますか？

注：この質問はデフォルトのJavaコレクションに関するものではなく、この場合、デフォルトのJavaコレクションにも他のJavaコレクションにもまったく関心がありません。この質問は特にTroveに関するものです。

私はQuora の問題を解決していましたが、私の特定のソリューションでは、値をキャッシュするためのハッシュテーブル (長いキー、int 値) が必要でした。キーと値のデータ型を知っていて、それらはプリミティブであり、問​​題空間でもあったため、Java HashMap が改善されることを望みました。「array-oflinkedlist」構造を使用して単純なハッシュテーブルを単純に実装することにしました (linkedList でさえ、私が実装した独自の Node クラスでした)。しかし、私自身の単純な実装は、一般的な Java HashMap よりも約 4 倍遅いことに気付きました。また、 Trove の LongToIntMapライブラリを使用して、その機能を確認しようとしました。Java HashMap を大幅に上回るカスタムの Long から Int へのハッシュテーブルを Java で構築するための良い提案はありますか?

GNU trove ライブラリはスレッドセーフですか? 特に TObjectDoubleHashMap に興味があります。彼らのドキュメントを見ましたが、何も言及されていないので、スレッドセーフではないと仮定しますか?

巨大なTroveマップと、複数のスレッドから頻繁に呼び出す必要のあるメソッドがあります。ほとんどの場合、このメソッドはtrueを返します。スレッドは大量の処理を行っており、次の方法が原因で競合が発生していることに気付きました（これは単なる例であり、実際のコードは少し異なります）。

これは「追加のみ」のマップであることに注意してください。キーが追加されると、そこに永久に残ります（これは次に来るものにとって重要だと思います）。

上記を次のように変更することで気づきました。

数の計算が20％高速化されます（多くの実行、長時間の実行などで確認されています）。

この最適化は正しいように見えますか（キーが存在すると、それは永久にそこにとどまるということを知っています）？

このテクニックの名前は何ですか？

編集

マップを更新するコードは、 containsSpecial（）メソッドよりも呼び出される頻度が低く、次のようになります（メソッド全体を同期しました）。

私はトローブの問題に出くわしましたTObjectDoubleHashMap。hashCodeバージョン2.0.2はメソッドをオーバーライドしません。

troveの最新バージョン（3.0.0）には、が含まれていhashCodeます。

equalsメソッドは両方のバージョンでオーバーライドされることに注意してください。

hashCodeバージョン2でメソッドがオーバーライドされなかったのはなぜですか？たぶん、オーバーライドhashCode/の契約equalsは、トローブマップが最初に書かれた後に導入されましたか？それとも、単に契約違反であり、後で修正されたバグですか？それがバグであり、機能ではない場合、私は非常に驚かれることでしょう。なぜなら、ハッシュを主に扱うクラスがhashCode、equals

したがって、Javolution が機能しないため (ここを参照)、単純な使用法で効率的でガベージを生成しない Java Map 実装が必要です。java.util.Mapキーを追加および削除すると、ガベージが生成されます。Trove と Guava を確認しましたが、 Set<E> 実装がないようです。のシンプルで効率的な代替手段はどこにありjava.util.Mapますか?

EJP の編集:

エントリ オブジェクトは、エントリを追加すると割り当てられ、削除すると GC に解放されます。:(

ここから、ColtOpenIntIntHashMapと Trove のTIntIntHashMapほうが、Java の組み込みHashMapまたは Guava のよりもパフォーマンスとメモリ使用量が優れていることがわかりましたHashMultimap。

ColtOpenIntIntHashMapや Trove では、 のTIntIntHashMapように複数の値を持つキーを使用できますHashMultimapか? HashMultimapそうでない場合、Colt や Trove のパフォーマンスとメモリ効率を達成できるを実装する良い方法は何ですか?

注: Guava の をテストしましHashMultimapたが、パフォーマンスとメモリ効率が悪いようです。

プリミティブint(s) の大きなリスト (約 800,000 int)を格納するためのスペース効率の良いコレクションが必要です。これcontains()により、定義された順序での高速操作と反復が可能になります。

contains()int がリストにあるかどうかを確認するためのより高速な操作は、非常に頻繁に行われるため、最優先事項です。

私は、Trove、Guava などの広く使用されている人気のあるサードパーティ ライブラリを使用することにオープンです。

Trove のTIntSetを見てきましたが、とにかく反復の順序を定義できないと思います。

編集：

コレクションのサイズは約 800,000 int になります。コレクションの値の範囲は 0 ～Integer.Max_VALUEです。反復の順序は、実際にはコレクションに値を追加する順序に基づいている必要があります。または、順序付けされた int[] を提供するだけで、同じ順序で反復する必要があります。

Trove のTIntHashSetから要素の反復順序をどうにか定義できますか?

Setまたは、要素の繰り返しの順序を定義できるその他のプリミティブです。セットの構築に使用された配列と同じ順序または挿入順序で要素を反復処理したい。