数十万のアイテムを追加/削除することを期待できる不変のマップがある場合（非常に短い期間（数秒など））、標準は悪い考えですか？ある瞬間のマップの最大サイズがわずか256Mbになるように、1Gbのデータを10秒未満でマップに渡したいとしましょう。HashMap
マップはある種の「履歴」を保持しているように見えますが、これは更新/アクセスのみのプライベートメンバー変数であるため、常に最後に更新されたテーブルにアクセスします（つまり、マップを渡しません）。Actor反応の中から。
基本的に、このデータ構造は、短時間で大量のデータを読み取るときにJVMのメモリが不足するという問題について、（部分的に）障害があるのではないかと思います。
別のマップ実装を使用したほうがよいでしょうか。もしそうなら、それは何ですか？
痛い。なぜ不変のマップを使用する必要があるのですか？かわいそうなガベージコレクター！不変マップは通常、（log n）時間に加えて、操作ごとに（log n）新しいオブジェクトを必要とします。または、実際には、可変ハッシュマップとレイヤーチェンジセットを上にラップするだけです（これにより、処理速度が低下し、オブジェクトの作成数が増える可能性があります）。
不変性は素晴らしいですが、これは私にはそれを使用する時間のようには思えません。もし私があなたなら、私は固執するでしょうscala.collection.mutable.HashMap。同時アクセスが必要な場合は、代わりにJavautil.concurrentをラップしてください。
また、JVMの若い世代のサイズを増やすこともできます：-Xmn1Gまたはそれ以上（で実行していると仮定-Xmx3G）。また、スループット（並列）ガベージコレクターを使用します。
それはひどいでしょう。あなたは常に最後に更新されたテーブルにアクセスしたいと言います。つまり、一時的なデータ構造だけが必要であり、永続的なデータ構造のコストを支払う必要はありません。完全に議論の余地のある「スタイルポイント」を獲得するために時間とメモリを交換するようなものです。 "。必要とされていないときに盲目的に永続的な構造を使用してカルマを構築しているのではありません。
また、ハッシュテーブルは永続化するのが特に難しい構造です。言い換えれば、「非常に、非常に遅い」（基本的に、読み取りが書き込みを大幅に上回っている場合に使用できます。多くの書き込みについて話しているようです）。
ちなみに、ConcurrentHashMapマップが1人のアクターからアクセスされることを考えると、この設計では意味がありません（これは説明から理解できます）。
Scalaのいわゆる（*）不変マップは、Scala2.7までの基本的な使用法を超えて壊れています。私を信用しないでください、ただそれのために開いているチケットの数を調べてください。そして、解決策は「Scala 2.8で他のものに置き換えられる」ということです（これはそうしました）。
したがって、Scala 2.7.xの不変のマップが必要な場合は、Scala以外で探すことをお勧めします。または、代わりにTreeHashMapを使用してください。
（*）Scalaの不変マップは実際には不変ではありません。これは内部的に変更可能なデータ構造であり、多くの同期が必要です。