静的分析に依存して並行性バグを確実に「再現」することは安全ですか？

データをクエリするスレッドと同じデータを更新するIOイベントを同期するときに、いくつかの同時実行バグが潜んでいると思われるJavaコードを継承しました。ThreadSafeと呼ばれる静的分析ツールを試しています。これは、さまざまな同時実行性の問題（つまり、非同期に呼び出されたメソッドから同期されていないフィールドにアクセスしたフィールドと、コレクションへのアクセスの一貫性のない同期）を実際に検出します。

単体テストを作成してデータの競合を確実に再現することがどれほど難しいかを発見した後、バグを確実に「再現」するためにThreadSafeに依存することが賢明かどうか疑問に思いましたか？私が求めているのは、バグをいつ修正したかを静的分析ツールに頼って教えても安全ですか？（もちろん、バグを修正するには、状況に応じてそれぞれを理解する必要があります）。

最初の質問に答える：

http://www.contemplateltd.com/threadsafe/faq#non-checkers

「ThreadSafeは、どのような種類の同時実行性の欠陥を検出しませんか？

• java.util.concurrentのすべてのサポートはまだ含まれていません。具体的には、ThreadSafeは、java.util.concurrent.atomicパッケージなど、java.util.concurrentによって提供される高度な同期機能の誤用をチェックしません。現在、Fork-Joinフレームワークを使用して並列プログラムを作成するときに発生する可能性のある誤りのチェッカーも含まれていません。

• 複雑なロックフリーアルゴリズムのバグを見つけるには、適切に拡張できない分析技術が必要です。このようなアルゴリズムは、専門の並行処理の専門家に任されるべきです。ThreadSafeは、そのようなアルゴリズムを含むライブラリを使用するアプリケーションの欠陥を見つけるように構成できます。

• ThreadSafeの新しいリリースにどの分析を含めるかは、使用可能な製品への統合に十分成熟した分析テクノロジーを使用して可能なこと、および「平均的な」Javaプログラムでよく見られる機能と同時実行性の欠陥の両方によって決まります。

• 現在ThreadSafeでカバーされていないJava並行性の問題がある場合、ContemplateのJava並行性スペシャリストは、カスタム構成をThreadSafeに追加するか、またはThreadSafeへの統合にまだ十分に成熟していない高度な分析テクノロジーを使用することで支援できる場合があります。 」

私の経験では、決定的で意味のある、しかし無知な開発者は、同時実行のバグを十分に難読化して、分析ツールがそれを見逃す可能性があります。

ツールがバグがあると判断した場合は、別の方法で証明するまでそれが正しいと考えます。それがツールの価値です。ツールでバグが見つからない場合は、ツールが存在しないふりをすることをお勧めします。

信頼できる並行コード（任意の言語）が必要な場合は、目標に以下を含める必要があります。

1. 重要なセクションは小さくてシンプルでなければならないため、理解するのは簡単です。
2. クリティカルセクションは、ソースレベルで他のコードから完全に分離する必要があります。
3. 並行コードに関係する関数/メソッド/サブルーチンは、1つのことだけを行う必要があります。同期プリミティブ（ロック、セマフォなど）を操作する場合は、共有リソースをいじらないでください。ループや条件付きコードを含めることはできません。「実際の作業」を別の関数に移動します。これはアイテム1をサポートします。
4. ロックの種類がある場合、開発者はコードを読み取って、ロックが30秒以内に保護するリソースを正確に判断できる必要があります。それがあなたに明らかでない場合、それは次の人には明らかではありません。そして、それはおそらくコードを書いた仲間には明らかではありませんでした。だからそれはおそらく壊れています。
5. 保護しているリソースの可視性は、それを保護する同期プリミティブの可視性を超えてはなりません。どちらのコンポーネントも、コードのより大きな本体から見えるべきではありません。
6. リストの残りの部分は、実際にはアイテム1と2を再表現するさまざまな方法にすぎません。

コードが正しく設計および構成されている場合は、コードのごく一部を見て、同時実行性を理解して信頼できるはずです。あなたはその目標に到達すると、その後、静的解析ツールにコードを供給し、それが同意するかどうかを確認します。

そして、コードをレビューのためにグル以外の他の開発者に渡します。並行性がどのように機能するか、なぜそれが正しいのかを説明してもらいます。彼らがそれを説明できない場合、それはまだあまりにも複雑です。

有用な静的分析ツールの作成には、少なくとも以下を含む、多数の矛盾する懸念のバランスをとることが含まれます。

• 誤検知（誤警報）率
• 偽陰性（捕捉されていないバグ）率
• 実行時間とスケーラビリティ

誤検知は開発者の時間を浪費するため、バグ検出ツールの重大な問題です。偽陰性を排除することは可能ですが、同時実行性のバグを含む多くのタイプのバグでは、これは偽陽性率の許容できない増加を伴います。実行時間の増加を犠牲にして、誤検知と誤検知の両方の割合を減らすことができますが、最も正確な分析手法は、小規模なアプリケーションを超えてスケ​​ーリングすることはなく、いずれにしても、両方をゼロに減らすことはできません。

多くの場合、動的分析ツールは0％の誤検知率を主張しますが、それは実際にバグが見つかって初めて発見されるためです。ブルームーンで1回だけ発生する競合状態またはデッドロックの場合、それほど役に立ちません。

これらの理由により、ThreadSafeはすべての同時実行バグを検出することを約束していません。誤検出率が低く、最も重要なバグを検出することを目的としています。一部のユーザーは、数日かけて発見した同時実行バグのあるコードでThreadSafeを試してみましたが、数分以内に誤検出なしに、そのバグ（そして多くの場合、知らない他の本物のバグ）を見つけました。

ThreadSafeについての情報を始めるのに適した場所は、このInfoQ記事です。詳細については、無料トライアルにサインアップできるThreadSafe Webサイトを参照してください。

（開示：ThreadSafeは商用ツールであり、私はそれを製造する企業であるContemplateの共同創設者です。）