1. So verwenden Sie den ==-Operator
Sehen Sie sich zunächst einen interessanten Code an
Integer a = 1000,b=1000;
Integer c = 100,d=100; public void mRun (final String name){ new Runnable() { public void run() { System.out.println(name) }
System.out.println(a==b); out.println (c==d);
Wenn Sie die richtige Antwort auf diese Frage bekommen und das Prinzip verstehen können. Das bedeutet, dass Ihre Grundlagen in Ordnung sind. Wenn Ihre Antworten wahr und wahr sind, fehlt Ihr Fundament.
Kündigen Sie zuerst die Antwort an, führen Sie den Code aus, wir erhalten false true. Wir wissen, dass == die Referenzen zweier Objekte vergleicht. Das abcd hier sind alle neu erstellten Objekte. Logischerweise sollte false eingegeben werden. Das ist das Interessante an dieser Frage, egal ob es sich um eine Interviewfrage oder einen Diskussionsbereich im Forum handelt, diese Frage taucht häufig auf. Das Prinzip ist eigentlich ganz einfach. Werfen wir einen Blick auf die Klasse Integer.java und es wird klar.
public static Integer valueOf(int i) { return i >= 128 || -128 new Integer(i) : SMALL_VALUES[i + 128]; {@link Integer#valueOf(int)} und Auto-Boxing */ private static final Integer[] SMALL_VALUES = new Integer[256] { for (int i = -128; i < 128; i++) { SMALL_VALUES[ i + 128] = new Integer(i); } }
Wenn wir eine Ganzzahl c = 100; deklarieren. Zu diesem Zeitpunkt wird eine automatische Boxoperation ausgeführt. Vereinfacht ausgedrückt wird der Basisdatentyp in ein Integer-Objekt konvertiert, und die Konvertierung in ein Integer-Objekt wird als valueOf-Methode bezeichnet wird in Integer zwischengespeichert. Die offizielle Erklärung lautet, dass kleine Zahlen häufiger verwendet werden. Um die Leistung zu optimieren, werden die Zahlen dazwischen zwischengespeichert. Deshalb sind die Antworten auf diese Frage falsch und wahr. Wenn der Wert des deklarierten Integer-Objekts zwischen -128 und 127 liegt, bezieht es sich auf dasselbe Objekt, sodass das Ergebnis wahr ist.
Dann schauen Sie sich den Code an
String s1 = „abc“;
String s2 = „abc“; ;
System.out.println(s1 == s2);
System.out.println(s1 == s3);
Gemäß der Syntax von == sind s1, s2 und s3 zunächst drei verschiedene Objekte. Im Allgemeinen ist die Ausgabe falsch. Das laufende Ergebnis des Programms ist jedoch tatsächlich wahr oder falsch. Die zweite Ausgabe von false ist verständlich, aber die erste Ausgabe von true ist rätselhaft. Wir wissen, dass einige Grundtypen von Variablen und Objektreferenzvariablen im Stapelspeicher der Funktion zugewiesen werden, während neue Objekte und Arrays im Heapspeicher gespeichert werden. Darüber hinaus gibt es jedoch einen Bereich, der als Konstantpool bezeichnet wird.
Wie wir es uns normalerweise vorstellen, wird String s1 = „abc“; der Wert eines so deklarierten String-Objekts im Konstantenpool gespeichert. Wenn wir ein Objekt wie String s1 = „abc“ erstellen, wird „abc“ im Konstantenpool (auch String-Pool genannt) gespeichert. Wenn wir einen Verweis auf String s2 = „abc“ erstellen, wird die unterste Ebene von Java angezeigt Überprüfen Sie, ob „abc“ im Konstantenpool vorhanden ist. Wenn er vorhanden ist, wird er auf diesen Wert verweisen und nicht erneut erstellt. Wenn er im Konstantenpool nicht vorhanden ist, wird er erstellt und dem Pool hinzugefügt . Deshalb sind die Antworten wahr und falsch.
3. Letztes Schlüsselwort
public void mRun(final String name){ new Runnable() { public void run() { try { Thread. Sleep (1000); } Catch (InterruptedException e) { // TODO Automatisch generierter Catch-Block e.printStackTrace(); } System.out.println(name); }
Ich glaube das Art von Code Wir haben viel darüber geschrieben, dass eine innere Klasse, wenn sie auf eine lokale Variable zugreift, den letzten Modifikator vor der lokalen Variablen hinzufügen muss, andernfalls meldet der Compiler einen Fehler. Das ist normalerweise das, was wir tun. Okay, hier kommt die zweite Frage: Warum müssen wir den letzten Modifikator hinzufügen? Ich glaube, dass die meisten Freunde nie über dieses Problem nachgedacht haben, wenn sie es einfach verwenden, und sich nie mit den Prinzipien befasst haben. Für einen guten Programmierer ist das nicht ratsam. Wir müssen nicht nur wissen, was passiert, sondern auch warum.
Lassen Sie uns nun analysieren, warum wir das letzte Schlüsselwort hinzufügen müssen. Erstens liegt der Lebenszyklus innerer Klassen auf der Mitgliedsebene, während sich der Lebenszyklus lokaler Variablen tatsächlich auf dem Methodenkörper befindet und so weiter. Mit anderen Worten: Wenn die mRun-Methode ausgeführt wird und der neue Thread ausgeführt wird, wird der neue Thread eine Sekunde lang in den Ruhezustand versetzt. Der Hauptthread wird weiterhin ausgeführt, mRun wird ausgeführt und der Lebenszyklus des Namensattributs endet.
Nach 1 Sekunde wird Syetem.out.printh(name) ausgeführt. Zu diesem Zeitpunkt ist der Name jedoch abgelaufen und nicht mehr im Speicher. Um diese Art von Fehler zu verhindern, verlangt Java strikt, dass lokale Variablen in inneren Klassen mit dem Schlüsselwort final geändert werden müssen. Nachdem die lokale Variable durch final geändert wurde, wird eine Kopie der lokalen Variablen im Speicher gespeichert. Wenn die innere Klasse darauf zugreift, wird tatsächlich auf diese Kopie zugegriffen. Dies ist wie eine Verlängerung des Lebenszyklus lokaler Variablen. Schließlich haben Java-Ingenieure diese Lücke im Voraus für uns geschlossen, sonst weiß ich nicht, wie viele Freunde sich um interne Klassenvariablen kümmern würden.
4. Dinge über Integer und int
Sehen Sie sich den Code unten an
Integer a = new Integer(1000);
Integer c = new Integer( 10) ;
Integer d = new Integer(10);
System.out.println(c == d);
Diese Frage Ist die erste Frage, wenn Sie die Antwort auf diese Frage sehr schnell erhalten können, dann herzlichen Glückwunsch. Wenn == konsistenter ist, haben Sie ein gründlicheres Verständnis.
——————————————————Trennlinie——————————————————————— ——–
Richtige Antwort: wahr, falsch
Viele Freunde werden verwirrt sein, nachdem sie diese Antwort gesehen haben. Laut der ersten Frage wird Integer nicht zwischengespeichert. Sollte das nicht wahr sein, aber wenn Sie genau hinschauen, ist die Ganzzahl hier neu von uns und wird nicht zwischengespeichert, sodass das Ergebnis falsch ist.
Jetzt wollen wir sehen, warum die erste wieder wahr ist? Zunächst einmal ist der Wert hier 1000, was definitiv nichts mit dem uns bekannten Integer-Cache zu tun hat. Da es nichts mit Caching zu tun hat und a ein neu erstelltes Objekt ist, liegt es auf der Hand, dass die Eingabe falsch sein sollte. Beachten Sie jedoch, dass b hier vom Typ int ist. Wenn int und Integer == verglichen werden, entpackt Java die Ganzzahl automatisch, dh konvertiert die Ganzzahl in einen int-Typ, sodass hier der Wert des int-Typs verglichen wird, sodass das Ergebnis wahr ist.
