Porównywanie ciągów z ==, które są zadeklarowane jako końcowe w Javie

Mam proste pytanie dotyczące napisów w Javie. Następny segment prostego kodu po prostu łączy dwa ciągi, a następnie porównuje je ==.

String str1="str";
String str2="ing";
String concat=str1+str2;

System.out.println(concat=="string");

Wyrażenie porównania concat=="string"zwraca falsejako oczywiste (rozumiem różnicę między equals()i ==).

Gdy te dwa ciągi zostaną zadeklarowane w ten finalsposób,

final String str1="str";
final String str2="ing";
String concat=str1+str2;

System.out.println(concat=="string");

Wyrażenie porównania concat=="string"w tym przypadku zwraca true. Dlaczego robi finalróżnicę? Czy to musi coś zrobić z pulą stażystów, czy jestem po prostu wprowadzany w błąd?

Gdy zadeklarujesz zmienną String(która jest niezmienna ) jako finali zainicjujesz ją wyrażeniem stałym czasu kompilacji, stanie się ono również wyrażeniem stałym czasu kompilacji, a jego wartość zostanie podkreślona przez kompilator, w którym jest używana. Zatem w drugim przykładzie kodu, po wstawieniu wartości, kompilacja łańcucha jest tłumaczona przez kompilator na:

String concat = "str" + "ing";  // which then becomes `String concat = "string";`

co w porównaniu do "string"da ci true, ponieważ literały łańcuchowe są internowane .

Z JLS §4.12.4 - finalZmienne :

Zmienna pierwotnego typu lub typu String, która jest finalinicjowana za pomocą wyrażenia stałego w czasie kompilacji (§ 15.28), nazywana jest zmienną stałą .

Również z JLS § 15.28 - Wyrażenie stałe:

Wyrażenia typu stałego w czasie kompilacji Stringsą zawsze „internowane”, tak aby współużytkować unikalne instancje przy użyciu tej metody String#intern().

Nie jest tak w pierwszym przykładzie kodu, w którym Stringzmienne nie są final. Nie są to zatem wyrażenia stałe czasu kompilacji. Operacja konkatenacji zostanie opóźniona do czasu wykonania, co spowoduje utworzenie nowego Stringobiektu. Możesz to sprawdzić, porównując kod bajtowy obu kodów.

Pierwszy przykład kodu (nie w finalwersji) jest kompilowany do następującego kodu bajtowego:

  Code:
   0:   ldc     #2; //String str
   2:   astore_1
   3:   ldc     #3; //String ing
   5:   astore_2
   6:   new     #4; //class java/lang/StringBuilder
   9:   dup
   10:  invokespecial   #5; //Method java/lang/StringBuilder."<init>":()V
   13:  aload_1
   14:  invokevirtual   #6; //Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
   17:  aload_2
   18:  invokevirtual   #6; //Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
   21:  invokevirtual   #7; //Method java/lang/StringBuilder.toString:()Ljava/lang/String;
   24:  astore_3
   25:  getstatic       #8; //Field java/lang/System.out:Ljava/io/PrintStream;
   28:  aload_3
   29:  ldc     #9; //String string
   31:  if_acmpne       38
   34:  iconst_1
   35:  goto    39
   38:  iconst_0
   39:  invokevirtual   #10; //Method java/io/PrintStream.println:(Z)V
   42:  return

Oczywiste jest przechowywanie stri ingw dwóch różnych zmiennych, a przy użyciu StringBuilderwykonać operację konkatenacji.

Natomiast twój drugi przykład kodu ( finalwersja) wygląda następująco:

  Code:
   0:   ldc     #2; //String string
   2:   astore_3
   3:   getstatic       #3; //Field java/lang/System.out:Ljava/io/PrintStream;
   6:   aload_3
   7:   ldc     #2; //String string
   9:   if_acmpne       16
   12:  iconst_1
   13:  goto    17
   16:  iconst_0
   17:  invokevirtual   #4; //Method java/io/PrintStream.println:(Z)V
   20:  return

Więc bezpośrednio wstawia ostatnią zmienną do utworzenia ciągu stringw czasie kompilacji, który jest ładowany przez ldcoperację w kroku 0. Następnie drugi ldckrok literału jest ładowany przez operację w kroku 7. Nie wymaga tworzenia żadnego nowego Stringobiektu w czasie wykonywania. Łańcuch jest już znany w czasie kompilacji i jest internowany.

Według moich badań wszystkie final Stringsą internowane w Javie. Z jednego z postów na blogu:

Tak więc, jeśli naprawdę musisz porównać dwa String za pomocą == lub! = Upewnij się, że wywołujesz metodę String.intern () przed dokonaniem porównania. W przeciwnym razie zawsze preferuj String.equals (String) do porównywania String.

Oznacza to, że jeśli zadzwonisz String.intern(), możesz porównać dwa ciągi za pomocą ==operatora. Ale tutaj String.intern()nie jest to konieczne, ponieważ w Javie final Stringsą wewnętrznie internalizowane.

Możesz znaleźć więcej informacji Porównanie ciągów znaków za pomocą operatora == i Javadoc dla metody String.intern () .

Zobacz także ten post Stackoverflow, aby uzyskać więcej informacji.

Jeśli spojrzysz na te metody

public void noFinal() {
    String str1 = "str";
    String str2 = "ing";
    String concat = str1 + str2;

    System.out.println(concat == "string");
}

public void withFinal() {
    final String str1 = "str";
    final String str2 = "ing";
    String concat = str1 + str2;

    System.out.println(concat == "string");
}

i jego dekompilacja z javap -c ClassWithTheseMethods wersjami, które zobaczysz

  public void noFinal();
    Code:
       0: ldc           #15                 // String str
       2: astore_1      
       3: ldc           #17                 // String ing
       5: astore_2      
       6: new           #19                 // class java/lang/StringBuilder
       9: dup           
      10: aload_1       
      11: invokestatic  #21                 // Method java/lang/String.valueOf:(Ljava/lang/Object;)Ljava/lang/String;
      14: invokespecial #27                 // Method java/lang/StringBuilder."<init>":(Ljava/lang/String;)V
      17: aload_2       
      18: invokevirtual #30                 // Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
      21: invokevirtual #34                 // Method java/lang/StringBuilder.toString:()Ljava/lang/String;
      ...

i

  public void withFinal();
    Code:
       0: ldc           #15                 // String str
       2: astore_1      
       3: ldc           #17                 // String ing
       5: astore_2      
       6: ldc           #44                 // String string
       8: astore_3      
       ...

Więc jeśli ciągi nie są ostateczne, kompilator będzie musiał użyć StringBuilderdo połączenia str1i str2tak

String concat=str1+str2;

zostanie skompilowany do

String concat = new StringBuilder(str1).append(str2).toString();

co oznacza, że concatzostaną utworzone w czasie wykonywania, więc nie będą pochodzić z puli ciągów.

Również jeśli ciągi są ostateczne, kompilator może założyć, że nigdy się nie zmieni, więc zamiast StringBuildergo używać , może bezpiecznie połączyć swoje wartości, aby

String concat = str1 + str2;

można zmienić na

String concat = "str" + "ing";

i połączone w

String concat = "string";

co oznacza, że concatestanie się literałem żądła, które zostanie internowane w puli łańcuchów, a następnie porównane z tym samym literałem łańcucha z tej puli w ifinstrukcji.

Stos i ciąg conts koncepcja puli

Zobaczmy na finalprzykład kod bajtowy

Compiled from "Main.java"
public class Main {
  public Main();
    Code:
       0: aload_0
       1: invokespecial #1                  // Method java/lang/Object."<init>":()V
       4: return

  public static void main(java.lang.String[]) throws java.lang.Exception;
    Code:
       0: ldc           #2                  // String string
       2: astore_3
       3: getstatic     #3                  // Field java/lang/System.out:Ljava/io/PrintStream;
       6: aload_3
       7: ldc           #2                  // String string
       9: if_acmpne     16
      12: iconst_1
      13: goto          17
      16: iconst_0
      17: invokevirtual #4                  // Method java/io/PrintStream.println:(Z)V
      20: return
}

At 0:i 2:, String "string"jest wypychany na stos (ze stałej puli) i zapisywany concatbezpośrednio w zmiennej lokalnej . Można wywnioskować, że kompilator sam tworzy (konkatenuje) String "string"w czasie kompilacji.

Non finalkod bajtowy

Compiled from "Main2.java"
public class Main2 {
  public Main2();
    Code:
       0: aload_0
       1: invokespecial #1                  // Method java/lang/Object."<init>":()V
       4: return

  public static void main(java.lang.String[]) throws java.lang.Exception;
    Code:
       0: ldc           #2                  // String str
       2: astore_1
       3: ldc           #3                  // String ing
       5: astore_2
       6: new           #4                  // class java/lang/StringBuilder
       9: dup
      10: invokespecial #5                  // Method java/lang/StringBuilder."<init>":()V
      13: aload_1
      14: invokevirtual #6                  // Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/Stri
ngBuilder;
      17: aload_2
      18: invokevirtual #6                  // Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/Stri
ngBuilder;
      21: invokevirtual #7                  // Method java/lang/StringBuilder.toString:()Ljava/lang/String;
      24: astore_3
      25: getstatic     #8                  // Field java/lang/System.out:Ljava/io/PrintStream;
      28: aload_3
      29: ldc           #9                  // String string
      31: if_acmpne     38
      34: iconst_1
      35: goto          39
      38: iconst_0
      39: invokevirtual #10                 // Method java/io/PrintStream.println:(Z)V
      42: return
}

Tutaj masz dwie Stringstałe, "str"a "ing"które muszą być łączone przy starcie z StringBuilder.

Chociaż podczas tworzenia za pomocą notacji Javy literału ciągowego, automatycznie wywołuje metodę intern () w celu umieszczenia tego obiektu w puli ciągów, pod warunkiem, że nie był już obecny w puli.

Dlaczego finał robi różnicę?

Kompilator wie, że końcowa zmienna nigdy się nie zmieni, kiedy dodamy te zmienne końcowe, dane wyjściowe trafiają do puli ciągów, ponieważ str1 + str2dane wyjściowe również nigdy się nie zmienią, więc w końcu kompilator wywołuje metodę inter po wyjściu powyższych dwóch zmiennych końcowych. W przypadku niekończącego kompilatora zmiennych nie należy wywoływać metody intern.