具体的には：
メソッド getOrLoad(K key, ObjectLoader loader) を持つ Cache インターフェイスがあります。つまり、キャッシュが指定されたキーのオブジェクトを見つけられない場合、それを ObjectLoader インスタンスからロードする必要があります。ただし、キャッシュは、オブジェクトをローダーからロードしてキャッシュに入れるという行為が安全なパブリケーションを構成することを保証する必要があります。
私は現在、この Cache インターフェースの一般的な junit テストを書いている最中であり、Cache の実装がこの安全な公開の保証に準拠していることをどのようにテストするのだろうかと考えています。
何か案は？実際のコードは、実際のファイルを調べたい場合に備えて、コード リポジトリの test-systest モジュール部分にあります。
Bill Pugh、Brian Goetz、および Cliff Click による同時実行コードのテストに関するJavaOne プレゼンテーションを見つけました。彼らはこのアプローチを提案しました.魔女は私が聞いた中で最高だと思います:
多くのプロデューサは、状態依存の hashCode 実装を使用して、ステートフルでスレッドセーフでないオブジェクトを作成します。オブジェクトが想定される同期ポイントを介して送信されると、hashCode が (スレッドローカルに) 合計されます。同様に、ゲートの反対側のコンシューマーは hashCode を合計します。
テストの最後に、プロデューサーとコンシューマーのすべての結果をそれぞれ合計します。2 つの合計が等しい場合、テストは合格です。
合計の代わりに XOR を使用することもできます。実際、任意の可換演算で実行できます。テスト ハーネス自体が追加の同期を導入してはならないことに注意してください。
おそらく、 ConTestを使用して、少なくともコードが正しいことをもう少し確信できるようにすることができます。
複数のスレッドを同時に実行するいくつかのテストを実装する必要があります。次に ConTest は、バイトコードをインストルメント化する (ヒューリスティックに制御された条件付きスリープと yield 命令を追加する) ことによって、並行性のバグが実際に明らかになる可能性を高めます。
安全でない公開によるエラーを実際に取得することは非常に困難です (方法を知っている人がいれば教えてください)。自動化されたソリューションには、静的分析が最適です。私はコードレビューに固執し、過度に心配することはありません.