Warum ergibt (i

Lesezeit: 4 Minuten

Benutzer-Avatar
Kshitij Jain

Ich habe einen Java-Code geschrieben, der in einer Endlosschleife läuft.

Unten ist der Code:

public class TestProgram {
    public static void main(String[] args){
        Integer i = new Integer(0);
        Integer j = new Integer(0);

        while(i<=j && j<=i && i!=j){
            System.out.println(i);
        }
    }
}

Im obigen Code, während Sie die Bedingung in der sehen while Schleife, zunächst sieht es so aus, als würde das Programm nicht in die Schleife gehen while Schleife. Aber eigentlich ist es eine Endlosschleife und druckt den Wert weiter.

Was passiert hier?

  • Einfache Antwort ist i<=j && j<=i && i!=j diese Bedingung wird immer als wahr ausgewertet. Nehmen Sie einfach ein Stück Papier und bewerten Sie, Sie werden es fangen 🙂

    – Pradeep Simha

    14. September 2013 um 17:44 Uhr


  • Die Art und Weise, wie Sie Integer erstellen, ist falsch. Verwenden Sie ‘compareTo’

    – nachokk

    14. September 2013 um 17:44 Uhr


  • Wenn du dich nie änderst i oder jwann würden Sie erwarten, dass die Schleife endet?

    – Fred Larson

    14. September 2013 um 17:44 Uhr

  • @PradeepSimha Für einfache int-Werte würde dies immer ergeben FALSCH. Aus i<=j und j<=i man kann daraus schließen i == j, was dem letzten Term widerspricht. Somit wird der gesamte Ausdruck als falsch ausgewertet und das While würde nicht eingegeben werden. Kernpunkt ist hier die Objektidentität!

    – Sirko

    14. September 2013 um 17:48 Uhr

  • Übrigens ist dies Puzzle 32 im Buch Java Puzzlers: Traps, Pitfalls, and Corner Cases.

    – Cyanfisch

    19. September 2013 um 15:48 Uhr

Benutzer-Avatar
Junid Ahsan

  • i <= j ausgewertet wird trueda das automatische Unboxing für int-Vergleiche und dann für beides erfolgt i und j den Standardwert beibehalten, 0.

  • j <= i ausgewertet wird true aus oben genanntem Grund.

  • i != j ausgewertet wird trueweil beides i und j sind verschiedene Objekte. Und beim Vergleichen von Objekten ist kein automatisches Unboxing erforderlich.

Alle Bedingungen sind wahr, und Sie ändern sich nicht i und j in Schleife, läuft also endlos.

  • können Sie bitte erklären, warum != nach dem Speicherindex von Referenzobjekten sucht und <= nach dem unverpackten Wert von Integer sucht ??.. warum gibt es einen solchen Unterschied zwischen diesen Operatoren?

    – Punith Raj

    14. September 2013 um 18:02 Uhr


  • @PunithRaj < & > Operatoren arbeiten mit Primitiven und nicht mit Objekten, daher erfolgt das automatische Unboxing für diese Operatoren. Aber die Operatoren == und != können auch für den Vergleich von Objekten verwendet werden, sodass hier kein Unboxing erforderlich ist, daher werden Objekte verglichen.

    – Juned Ahsan

    14. September 2013 um 18:05 Uhr


  • Ah, die versteckten Gefahren des impliziten Boxens/Unboxings!!

    – Heiße Licks

    14. September 2013 um 23:13 Uhr

  • Stack Overflow sollte nur ein neues Tag hinzufügen: “Automatisches Unboxing war der größte Fehler, der jemals in Java gemacht wurde”. :-). Außer für Autoren der Java Puzzler-Bücher. Verwenden Sie es, um Fragen wie diese zu markieren.

    – Benutzer949300

    15. September 2013 um 3:30 Uhr


  • beachten Sie, dass Integer.valueOf(0) == Integer.valueOf(0) wird immer als wahr ausgewertet, da in diesem Fall dasselbe Objekt zurückgegeben wird (siehe IntegerCache grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/…)

    – Vitalii Fedorenko

    15. September 2013 um 18:13 Uhr

Benutzer-Avatar
Aschwani

Weil du vergleichst

  • 0 < = 0 (true) // unboxing

  • 0 > = 0 (true) // unboxing

  • reference != secondReference (true) wie Sie Objekte erstellen, kein primitiver Vergleich. Also wertet es aus while(true) { // Never ending loop }.

  • Oh! Versteckter Drache von Auto UNBOXING … Gute Erklärung.

    – HybrisHelp

    8. Oktober 2013 um 14:09 Uhr

Benutzer-Avatar
Oberst Panik

Die Integer-Objekte sind anders. Er unterscheidet sich vom grundlegenden int-Typ.

Siehe diese Antwort: Wie vergleiche ich zwei Ganzzahlen in Java richtig?

Das i != j Teil wahr ist, von dem Sie erwartet hatten, dass er falsch ist.

  • Obwohl es wahr ist, spielt es hier keine Rolle und beantwortet auch nicht die Frage.

    – Kon

    14. September 2013 um 17:45 Uhr

  • @Kon: Tatsächlich ist dies die Antwort. Die Bedingungen Nr. 1 und Nr. 2 werden zu ausgewertet true Wegen Autoboxen. Bei #3 entfällt das Autoboxing und der Vergleich findet auf Objektebene (Speicherort) statt.

    – Heimat

    14. September 2013 um 17:47 Uhr

Benutzer-Avatar
Akhilesh Dhar Dubey

Es gibt zwei verschiedene Fälle, die wir zuerst verstehen müssen,

Fall 1:

        Integer i = new Integer(10);
        Integer j = new Integer(10);

        System.out.println((i<=j && j<=i && i!=j));
        System.out.println(i!=j);

Fall 2:

        Integer i = 10;
        Integer j = 10;

        System.out.println((i<=j && j<=i && i==j));
        System.out.println(i==j);

beide sind unterschiedlich, wie

im Fall 1: i!=j wird sein true weil beide auf zwei verschiedene Objekte im Heap verweisen und nicht gleich sein können. Aber

im Fall 2: i==j wird sein true weil beide 10 Integer-Literale sind und Java beibehält pool for Integer literals die Wert haben (-128 <= X <= 127). In diesem Fall ergibt sich also 10 <= 127 als wahr, sodass beide auf dasselbe Objekt verweisen.

Die Schleife endet nicht, weil Ihre Bedingung wahr ist ( i != j ist wahr, weil es 2 verschiedene Objekte gibt, verwenden Sie stattdessen Integer.valueOf) und innerhalb der Schleife ändern sich die Werte nicht, sodass Ihre Bedingung für immer wahr bleibt.

Benutzer-Avatar
Eric Gopak

Vielleicht liegt der Grund darin, dass sowohl ‘i’ als auch ‘j’ Objekte sind und der Objektvergleich nicht dasselbe ist wie der Objektreferenzvergleich. Bitte erwägen Sie die Verwendung von !i.equals(j) anstelle von i!=j

Benutzer-Avatar
Krichevskoy

Die Integer-Objekte sind anders. Er unterscheidet sich vom grundlegenden int-Typ. also kannst du einfach so machen. Was Sie tun, ist nur das Objekt zu vergleichen und natürlich ist das Ergebnis wahr.

1299330cookie-checkWarum ergibt (i

This website is using cookies to improve the user-friendliness. You agree by using the website further.

Privacy policy