Vergleich finaler Strings mit == in Java
Strings in Java sind unveränderlich und verhalten sich eindeutig, wenn sie als final deklariert werden. Betrachten Sie den folgenden Code:
String str1 = "str"; String str2 = "ing"; String concat = str1 + str2; System.out.println(concat == "string"); // false
Hier gibt der Vergleich „false“ zurück, da „==" Objektreferenzen vergleicht. Wenn wir jedoch die Zeichenfolgen als endgültig deklarieren:
final String str1 = "str"; final String str2 = "ing"; String concat = str1 + str2; System.out.println(concat == "string"); // true
Jetzt gibt der Vergleich aus unerklärlichen Gründen „true“ zurück.
Grund
Endgültige Zeichenfolgen, die initialisiert werden Mit konstanten Ausdrücken zur Kompilierungszeit, wie im Beispiel oben, werden sie zu konstanten Variablen und erhalten eine einzigartige Eigenschaft: Sie sind intern. Internierung bedeutet, dass eindeutige Instanzen von Zeichenfolgen gemeinsam genutzt werden.
Im zweiten Codeausschnitt wird das Verkettungsergebnis „string“ zur Kompilierungszeit interniert. Somit hat es dieselbe Referenz wie das String-Literal „string“, das an „==“ übergeben wird. Daraus ergibt sich der wahre Vergleich.
Bytecode-Analyse
Der Unterschied zwischen den beiden Versionen ist in ihrem Bytecode zu sehen:
Fazit
Endgültige Zeichenfolgen mit konstanten Ausdrücken zur Kompilierungszeit in Java sind internieren und einzigartige Instanzen teilen. Dies kann beim Vergleich mit „==“ zu unerwarteten Ergebnissen führen, da Objektverweise direkt und nicht deren Werte überprüft werden.
Das obige ist der detaillierte Inhalt vonWarum gibt der „=='-Vergleich der endgültigen Zeichenfolgen in Java manchmal „True' und manchmal „False' zurück?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!