カフェインvsグアバキャッシュ
これらの マイクロベンチマーク によると、読み取り操作と書き込み操作の両方で カフェイン は グアバキャッシュ よりも高速であることがわかります。
カフェインの実装の秘密は何ですか？ Guava Cacheとどう違うのですか？
期限切れの場合、カフェインはスケジュールされたエグゼキューターを使用して適切なメンテナンス操作をバックグラウンドで実行することは正しいのでしょうか？
主な違いは、Caffeineがイベントの記録と再生にリングバッファーを使用するのに対し、GuavaはConcurrentLinkedQueueを使用するためです。意図は常にGuavaを移行することであり、簡単に開始することは理にかなっていますが、残念ながらこれらの変更を受け入れることに関心はありませんでした。リングバッファアプローチでは、割り当てが回避され、制限があり（損失が多く）、操作のコストが低くなります。
残りのコストは、設計の不一致が原因です。 MapMakerの最初の作成者は、GCに遅延させることによるキャッシュの問題の解決策として、ソフト参照に熱心でした。残念ながら、それはマイクロベンチマークでは高速に思えるかもしれませんが、Stop-the-world GCスラッシングを引き起こしているため、実際には恐ろしいパフォーマンスを持っています。サイズベースのソリューションはこの作業に適応させる必要があり、それは理想的ではありません。カフェインはサイズベースで最適化され、ハッシュテーブルも改善されますが、Guavaはリファレンスキャッシングをよりエレガントに処理します。
カフェインは、メンテナンスや有効期限のために独自のスレッドを作成しません。コストはcommonPoolに委ねられます。これにより、ユーザーが直面する待ち時間がわずかに改善されますが、スループットは改善されません。将来のバージョンではCompletableFuture.delayedExecutorスレッドを直接作成せずに次の有効期限イベントをスケジュールします（プロンプト削除通知に依存するビジネスロジックを持つユーザー向け）。
ConcurrentLinkedHashMapとMapMakerは同時に書かれており、CLHMはカフェインと同様のパフォーマンスを発揮します。違いは、設計者がどのシナリオを好んで最適化したかによるもので、他の機能の実装方法に影響を与えたと思います。 Guavaに同様のパフォーマンスプロファイルを実現するためのぶら下がっている果物はありますが、それを推進するための内部チャンピオンはありません（さらに好ましいカフェインとしてカフェインを使用すれば、さらに低くなります）。