Java'da sonsuz döngüler

whileJava'da aşağıdaki sonsuz döngüye bakın. Altındaki ifade için derleme zamanı hatasına neden olur.

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

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

Aşağıdaki aynı sonsuz whiledöngü, ancak iyi çalışıyor ve koşulu bir boole değişkeniyle değiştirdiğim herhangi bir hata vermiyor.

boolean b=true;

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

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

İkinci durumda da, döngüden sonraki ifadeye açıkça ulaşılamaz çünkü boolean değişkeni bdoğrudur, yine de derleyici hiç şikayet etmez. Neden?

Düzenleme: Aşağıdaki sürüm, whileaçık olduğu gibi sonsuz bir döngüye sıkışmış olur, ancak ifdöngü içindeki koşul her zaman falseve sonuç olarak, döngü hiçbir zaman geri dönemez ve derleyici tarafından belirlenebilir. derleme zamanının kendisi.

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.

Düzenleme:if ve ile aynı şey 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.
}      

Aşağıdaki sürüm whilede sonsuz bir döngüye sıkışmış durumda.

while(true) {

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

Bunun nedeni, ifade kendisinden önce bloğun içinde karşılaşsa finallybile bloğun her zaman yürütülmesidir .returntry

Derleyici, ilk ifadenin her zaman sonsuz bir döngü ile sonuçlandığını kolayca ve kesin olarak kanıtlayabilir , ancak ikincisi için o kadar kolay değildir. Oyuncak örneğinizde basit, ama ya eğer:

• değişkenin içeriği bir dosyadan okundu mu?
• değişken yerel değildi ve başka bir iş parçacığı tarafından değiştirilebilir mi?
• değişken bazı kullanıcı girdilerine dayanıyor mu?

Derleyici açıkça basit durumunuzu kontrol etmiyor çünkü o yoldan tamamen ayrılıyor. Neden? Çünkü şartnameye göre çok daha zor . Bölüm 14.21'e bakınız :

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

(Bu arada, benim derleyici gelmez değişken ilan edildiğinde şikayet final.)

Spesifikasyonlara göre while ifadeleri hakkında şu söyleniyor.

Bir while ifadesi, aşağıdakilerden en az biri doğruysa normal olarak tamamlayabilir:

• While ifadesi ulaşılabilirdir ve koşul ifadesi true değerine sahip sabit bir ifade değildir.
• While ifadesinden çıkan ulaşılabilir bir break ifadesi vardır. \

Bu nedenle, derleyici yalnızca while ifadesini izleyen kodun, while koşulu gerçek bir değere sahip bir sabitse veya while içinde bir break ifadesi varsa erişilemez olduğunu söyleyecektir. İkinci durumda, b'nin değeri sabit olmadığından, onu takip eden kodu erişilemez olarak kabul etmez. Neyin ulaşılamaz olduğu ve neyin ulaşılamayacağı hakkında size daha fazla ayrıntı vermek için bu bağlantının arkasında çok daha fazla bilgi var.

Çünkü true sabittir ve döngüde b değiştirilebilir.

Değişken durumu analiz etmek zor olduğundan, derleyici hemen hemen pes etti ve dilediğinizi yapmanıza izin verdi. Ek olarak, Java Dil Spesifikasyonu, derleyicinin erişilemez kodu tespit etmesine nasıl izin verildiği konusunda açık kurallara sahiptir .

Derleyiciyi kandırmanın birçok yolu vardır - başka bir yaygın örnek de

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

bu da işe yaramazdı, çünkü derleyici bölgenin ulaşılamaz olduğunu fark edecekti. Bunun yerine yapabilirsin

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

Derleyici ifadenin asla yanlış olmayacağını anlayamadığı için bu işe yarar.

İkincisi ulaşılamaz değil. Boolean b, döngü içinde bir yerde bitiş durumuna neden olacak şekilde yanlış olarak değiştirilme olasılığına sahiptir.

Benim tahminim "b" değişkeninin değerini değiştirme olasılığı var, bu yüzden derleyiciye System.out.println("while terminated"); ulaşılabileceğini düşünüyorum .

Derleyiciler mükemmel değiller de olmamalılar

Derleyicinin sorumluluğu sözdizimini onaylamaktır - yürütmeyi onaylamak değildir. Derleyiciler, kesin olarak yazılmış bir dildeki birçok çalışma zamanı problemini nihayetinde yakalayabilir ve önleyebilir - ancak bu tür hataları yakalayamazlar.

Pratik çözüm, derleyicilerinizin kontrollerini tamamlayacak birim testleri pillerine sahip olmak VEYA ilkel değişkenlere ve durdurma koşullarına dayanmak yerine sağlam olduğu bilinen mantığı uygulamak için nesneye yönelik bileşenleri kullanmaktır.

Güçlü Yazma ve OO: derleyicinin etkinliğini artırma

Bazı hatalar doğası gereği sözdizimseldir ve Java'da güçlü yazım, birçok çalışma zamanı istisnasını yakalanabilir hale getirir. Ancak, daha iyi türleri kullanarak, derleyicinizin daha iyi bir mantık yürütmesine yardımcı olabilirsiniz.

Derleyicinin mantığı daha etkili bir şekilde zorlamasını istiyorsanız, Java'da çözüm, bu tür mantığı uygulayabilen sağlam, gerekli nesneler oluşturmak ve bu nesneleri ilkel öğeler yerine uygulamanızı oluşturmak için kullanmaktır.

Bunun klasik bir örneği, Java'nın foreach döngüsü ile birlikte yineleyici modelinin kullanılmasıdır. Bu yapı, basit bir while döngüsüne göre, gösterdiğiniz hata türüne karşı daha az savunmasızdır.

Derleyici, biçerebilecek değerlerin üzerinden geçecek kadar karmaşık değildir (ancak bunu yalnızca bir kez atarsınız). İlk örnek, derleyicinin sonsuz bir döngü olacağını görmesi kolaydır çünkü koşul değişken değildir.

Derleyicinizin ilk vakayı derlemeyi reddetmesine şaşırdım. Bu bana garip geliyor.

Ancak ikinci durum birinci durum için optimize edilmemiştir çünkü (a) başka bir iş parçacığı b(b) 'nin değerini güncelleyebilir , çağrılan işlevin değerini bbir yan etki olarak değiştirebilir .

Aslında kimsenin bunu ÇOK doğru anladığını sanmıyorum (en azından orijinal sorgulayıcı anlamında değil). OQ şunları söylemeye devam ediyor:

Doğru, ancak ilgisiz, çünkü b döngüde DEĞİŞTİRİLMİYOR

Ama önemli değil çünkü son satıra ulaşılabilir. Bu kodu aldıysanız, bir sınıf dosyasına derlediyseniz ve sınıf dosyasını başka birine (örneğin bir kitaplık olarak) verdiyseniz, derlenmiş sınıfı yansıtma yoluyla "b" yi değiştiren, döngüden çıkıp sonuncu yürütmek için satır.

Bu, sabit olmayan (veya kullanıldığı konumda bir sabite derleyen son) herhangi bir değişken için geçerlidir - bazen sınıfı son ile yeniden derlerseniz ve ona başvuran bir sınıfla değil, tuhaf hatalara neden olur, referanslama sınıf yine de herhangi bir hata olmadan eski değeri tutacaktır)

Satın alınan bir kitaplıktaki bir sınıfa maymunla yama uygulamak için başka bir sınıfın nihai olmayan özel değişkenlerini değiştirmek için yansıtma yeteneğini kullandım - bir hatayı düzelterek satıcının resmi yamalarını beklerken geliştirmeye devam edebildik.

Bu arada, bu bugünlerde gerçekten işe yaramayabilir - daha önce yapmış olsam da, bu kadar küçük bir döngünün CPU önbelleğinde önbelleğe alınması ihtimali var ve değişken geçici olarak işaretlenmediğinden önbelleğe alınan kod asla yeni değeri al. Bunu eylemde hiç görmedim ama teorik olarak doğru olduğuna inanıyorum.

Bunun nedeni, derleyicinin mümkün olsa da çok fazla bebek bakıcılığı çalışması yapmamasıdır.

Gösterilen örnek, derleyicinin sonsuz döngüyü algılaması için basit ve mantıklıdır. Ama değişkenle herhangi bir ilişkisi olmadan 1000 satırlık kod eklemeye ne dersiniz b? Peki ya tüm bu ifadeler b = true;? Derleyici sonucu kesinlikle değerlendirebilir ve sonunda whiledöngüde doğru olduğunu söyleyebilir , ancak gerçek bir projeyi derlemek ne kadar yavaş olur?

Not: tüy bırakmayan araç kesinlikle sizin için yapmalı.

Derleyicinin bakış açısından, bin bir while(b)yerde yanlışa dönüşebilir. Derleyici kontrol etme zahmetine girmez.

Eğlenmek için deneyin while(1 < 2), for(int i = 0; i < 1; i--)vb.

İfadeler çalışma zamanında değerlendirilir, bu nedenle, "true" skaler değerini boolean değişkeni gibi bir şeyle değiştirirken, skaler bir değeri boole ifadesine değiştirmişsinizdir ve bu nedenle derleyicinin bunu derleme zamanında bilmesinin bir yolu yoktur.

Derleyici, mantıksal değerin trueçalışma zamanında değerlendirileceğini kesin olarak belirleyebilirse, bu hatayı atar. Derleyici bildirilen değişken olduğunu varsayar olabilir (biz insanlarda böyle olmaz burada biliyorum olsa) değiştirilmelidir.

Bu gerçeği vurgulamak için, değişkenler finalJava'da olduğu gibi bildirilirse , çoğu derleyici, değerin yerini almışsınız gibi aynı hatayı atar. Bunun nedeni, değişkenin derleme zamanında tanımlanması (ve çalışma zamanında değiştirilememesi) ve bu nedenle derleyicinin, ifadenin trueçalışma zamanında değerlendirileceğini kesin olarak belirleyebilmesidir .

İlk İfade her zaman sonsuz bir döngü ile sonuçlanır, çünkü while döngüsü koşulunda bir sabit belirledik, burada ikinci durumda derleyici, döngü içindeki b'nin değerinin değişme olasılığı olduğunu varsayar.