安全な公開のための単体テスト

Question

Javaでの安全な出版の保証をどのように単体テストしますか？

具体的に：

getOrLoad（K key、ObjectLoader loader）メソッドを持つCacheインターフェースがあります。つまり、キャッシュが特定のキーのオブジェクトを見つけることができない場合、ObjectLoaderインスタンスからそれをロードする必要があります。ただし、ローダーは、ローダーからオブジェクトをロードしてキャッシュに入れるという行為が安全なパブリケーションを構成することを保証するために必要です。

現在、このCacheインターフェースの一般的なjunitテストを書いている最中で、Cacheの実装がこの安全な発行保証に準拠していることをどのようにテストするのでしょうか。

アイデアはありますか？実際のコードは、コードリポジトリのtest-systestモジュール部分にあります。実際のファイルを調べたい。

Answer 1

JavaOneプレゼンテーション Bill Pugh、Brian Goetz、Cliffによる並行コードのテストのテーマについて。彼らはこのアプローチを提案した、私が聞いた中で最高だと思う魔女：

多くのプロデューサーは、状態依存hashCode実装を使用して、ステートフルでスレッドセーフでないオブジェクトを作成します。オブジェクトが想定される同期ポイントを介して送信されると、hashCodeが（スレッドローカルに）合計されます。同様に、ゲートの反対側のコンシューマーはhashCodeを合計します。

テストの最後に、生産者と消費者のすべての結果を合計します。 2つの合計が等しい場合、テストは合格です。

sumの代わりにXORを使用することもできます。実際、可換演算はすべて実行されます。テストハーネス自体が追加の同期を導入してはならないことに注意してください。

Answer 2

ConTest を使用して、少なくとももう少し自信を持たせることができますコードは正しいです。

複数のスレッドを同時に実行するいくつかのテストを実装する必要があります。その後、ConTestは、バイトコードをインスツルメントすることにより、並行性のバグが実際に明らかになる可能性を高めます（ヒューリスティックに制御された条件付きスリープとyield命令を追加します）。

Answer 3

安全でない公開によるエラーを実際に取得することは非常に困難です（誰かが方法を知っているなら、私に知らせてください）。静的解析は、自動化ソリューションの最善策です。私はコードレビューに固執し、それを過度に心配することはありません。