Javaの無限ループ

whileJavaで次の無限ループを見てください。その下のステートメントでコンパイル時エラーが発生します。

while(true) {
    System.out.println("inside while");
}

System.out.println("while terminated"); //Unreachable statement - compiler-error.

whileただし、次の同じ無限ループは正常に機能し、条件をブール変数に置き換えただけのエラーは発生しません。

boolean b=true;

while(b) {
    System.out.println("inside while");
}

System.out.println("while terminated"); //No error here.

2番目のケースでも、ブール変数bがtrueであるにもかかわらず、コンパイラーがまったく文句を言わないため、ループの後のステートメントは明らかに到達できません。どうして？

編集：次のバージョンはwhile明らかなように無限ループにif陥りますが、ループ内の条件が常にfalse、したがってループが戻ることはなく、コンパイラによって決定される場合でも、その下のステートメントに対してコンパイラエラーは発行されません。コンパイル時自体。

while(true) {

    if(false) {
        break;
    }

    System.out.println("inside while");
}

System.out.println("while terminated"); //No error here.

while(true) {

    if(false)  { //if true then also
        return;  //Replacing return with break fixes the following error.
    }

    System.out.println("inside while");
}

System.out.println("while terminated"); //Compiler-error - unreachable statement.

while(true) {

    if(true) {
        System.out.println("inside if");
        return;
    }

    System.out.println("inside while"); //No error here.
}

System.out.println("while terminated"); //Compiler-error - unreachable statement.

編集：とifと同じことwhile。

if(false) {
    System.out.println("inside if"); //No error here.
}

while(false) {
    System.out.println("inside while");
    // Compiler's complain - unreachable statement.
}

while(true) {

    if(true) {
        System.out.println("inside if");
        break;
    }

    System.out.println("inside while"); //No error here.
}      

次のバージョンのwhileも無限ループに陥ります。

while(true) {

    try {
        System.out.println("inside while");
        return;   //Replacing return with break makes no difference here.
    } finally {
        continue;
    }
}

これはfinally、returnステートメントがtryブロック自体の前にある場合でも、ブロックが常に実行されるためです。

コンパイラーは、最初の式が常に無限ループになることを簡単かつ明確に証明できますが、2番目の式ほど簡単ではありません。おもちゃの例では簡単ですが、次の場合はどうでしょうか。

• 変数の内容はファイルから読み取られましたか？
• 変数はローカルではなく、別のスレッドで変更できますか？
• 変数はユーザー入力に依存していましたか？

コンパイラーは、その道を完全に放棄しているため、明らかに単純なケースをチェックしていません。どうして？仕様で禁止されているのははるかに難しいからです。セクション14.21を参照してください。

• http://docs.oracle.com/javase/specs/jls/se7/html/jls-14.html#jls-14.21-300-M

（ちなみに、私のコンパイラは変数が宣言されたときに文句を言いますfinal。）

仕様によると、whileステートメントについて次のように述べられています。

whileステートメントは、次の少なくとも1つが当てはまる場合に正常に完了することができます。

• whileステートメントは到達可能であり、条件式は値がtrueの定数式ではありません。
• whileステートメントを終了する到達可能なbreakステートメントがあります。\

したがって、コンパイラーは、while条件が真の値を持つ定数であるか、while内にbreakステートメントがある場合にのみ、whileステートメントに続くコードに到達できないと言います。2番目のケースでは、bの値が定数ではないため、それに続くコードが到達不能であるとは見なされません。そのリンクの背後には、到達不能と見なされるものと見なされないものについての詳細を提供するための、はるかに多くの情報があります。

trueは定数であり、bはループ内で変更できるためです。

変数の状態を分析するのは難しいので、コンパイラーはほとんどあきらめて、あなたが望むことをすることができます。さらに、Java言語仕様には、コンパイラが到達不能コードを検出する方法に関する明確なルールがあります。

コンパイラをだます方法はたくさんあります-別の一般的な例は

public void test()
{
    return;
    System.out.println("Hello");
}

コンパイラはその領域が到達不能であることに気付くため、これは機能しません。代わりに、あなたはすることができます

public void test()
{
    if (2 > 1) return;
    System.out.println("Hello");
}

コンパイラは式が偽になることは決してないことを認識できないため、これは機能します。

後者は到達不能ではありません。ブールbは、ループ内のどこかでfalseに変更されて、終了条件を引き起こす可能性があります。

私の推測では、変数「b」はその値を変更する可能性があるため、コンパイラーはSystem.out.println("while terminated"); 到達できると考えています 。

コンパイラは完璧ではありません-また、完璧であるべきではありません

コンパイラの責任は構文を確認することであり、実行を確認することではありません。コンパイラーは最終的に、強く型付けされた言語で多くの実行時の問題をキャッチして防止できますが、そのようなエラーをすべてキャッチすることはできません。

実用的な解決策は、コンパイラのチェックを補完する単体テストのバッテリーを用意するか、プリミティブ変数や停止条件に依存するのではなく、堅牢であることがわかっているロジックを実装するためにオブジェクト指向コンポーネントを使用することです。

強いタイピングとOO：コンパイラの有効性を高める

一部のエラーは本質的に構文的なものです。Javaでは、強い型付けにより、多くの実行時例外がキャッチ可能になります。ただし、より適切な型を使用することで、コンパイラーがより適切なロジックを適用できるようになります。

コンパイラにロジックをより効果的に適用させたい場合、Javaでの解決策は、そのようなロジックを適用できる堅牢で必要なオブジェクトを構築し、それらのオブジェクトを使用して、プリミティブではなくアプリケーションを構築することです。

この典型的な例は、イテレータパターンの使用であり、Javaのforeachループと組み合わせて、この構造は、単純なwhileループよりも説明するタイプのバグに対する脆弱性が低くなっています。

コンパイラーは、b含まれている可能性のある値を実行するほど高度ではありません（ただし、割り当てるのは1回だけです）。最初の例は、条件が可変ではないため、コンパイラーが無限ループになることを簡単に確認できます。

あなたのコンパイラが最初のケースのコンパイルを拒否したことに驚いています。それは私には奇妙に思えます。

ただし、（a）別のスレッドがb（b）呼び出された関数の値をb副作用として変更する可能性があるため、2番目のケースは最初のケースに最適化されていません。

実際、私は誰もそれをかなり正しく理解したとは思いません（少なくとも元の質問者の意味では）。OQは次のように述べ続けています。

正しいが、bはループ内で変更されていないため、無関係

しかし、最後の行に到達できるので、それは問題ではありません。そのコードを取得してクラスファイルにコンパイルし、クラスファイルを他の誰か（たとえばライブラリとして）に渡すと、コンパイルされたクラスを、リフレクションによって「b」を変更するコードにリンクし、ループを終了して最後の原因となる可能性があります。実行する行。

これは、定数ではない変数（または、使用されている場所で定数にコンパイルされるfinal-を参照するクラスではなく、finalを使用してクラスを再コンパイルすると、奇妙なエラーが発生する場合があります）に当てはまります。クラスはエラーなしで古い値を保持します）

リフレクション機能を使用して、別のクラスの非最終プライベート変数を変更し、購入したライブラリのクラスにモンキーパッチを適用しました。これにより、ベンダーからの公式パッチを待つ間、開発を続行できるようにバグが修正されました。

ちなみに、これは最近実際には機能しない可能性があります-私は以前にそれを行いましたが、そのような小さなループがCPUキャッシュにキャッシュされる可能性があり、変数が揮発性としてマークされていないため、キャッシュされたコードは決して機能しない可能性があります新しい値を取得します。私はこれが実際に行われているのを見たことがありませんが、理論的には正しいと思います。

それは可能ですが、コンパイラがベビーシッターの仕事をあまりしすぎないからです。

示されている例は、コンパイラーが無限ループを検出するための単純で合理的なものです。しかし、変数とは関係なく、1000行のコードを挿入するのはどうbでしょうか。そして、それらのステートメントはすべてb = true;どうですか？コンパイラーは間違いなく結果を評価し、最終的にはwhileループで真であると言うことができますが、実際のプロジェクトをコンパイルするのはどれくらい遅くなりますか？

PS、lintツールは間違いなくあなたのためにそれを行う必要があります。

コンパイラの観点からは、binwhile(b)はどこかでfalseに変わる可能性があります。コンパイラはチェックを気にしません。

楽しみのためにwhile(1 < 2)、for(int i = 0; i < 1; i--)などを試してみてください。

式は実行時に評価されるため、スカラー値「true」をブール変数のようなものに置き換える場合、スカラー値をブール式に変更したため、コンパイラーはコンパイル時にそれを知る方法がありません。

コンパイラがブール値がtrue実行時に評価されると決定的に決定できる場合、そのエラーがスローされます。コンパイラーは、宣言した変数が変更可能であると想定しています（ただし、ここでは人間としては変更できません）。

この事実を強調するために、変数がfinalJavaのように宣言されている場合、ほとんどのコンパイラーは、値を代入した場合と同じエラーをスローします。これは、変数がコンパイル時に定義され（実行時に変更できない）、したがってコンパイラーが、式がtrue実行時に評価されることを最終的に決定できるためです。

最初のステートメントは、whileループの条件で定数を指定しているため、常に無限ループになります。2番目の場合のように、コンパイラーは、ループ内でbの値が変更される可能性があると想定しています。