Comparar cadenas con == que se declaran finales en Java

Tengo una pregunta simple sobre cadenas en Java. El siguiente segmento de código simple solo concatena dos cadenas y luego las compara ==.

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

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

La expresión de comparación concat=="string"regresa falsecomo obvia (entiendo la diferencia entre equals()y ==).

Cuando estas dos cadenas se declaran finalasí,

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

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

La expresión de comparación concat=="string", en este caso, regresa true. ¿Por qué hace la finaldiferencia? ¿Tiene que ver algo con el grupo de internos o simplemente estoy siendo engañado?

Cuando declara una variable String(que es inmutable ) como final, y la inicializa con una expresión constante en tiempo de compilación, también se convierte en una expresión constante en tiempo de compilación, y el compilador en el que se utiliza inserta su valor. Entonces, en su segundo ejemplo de código, después de incluir los valores, el compilador traduce la concatenación de cadenas a:

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

que en comparación con "string"te dará true, porque los literales de cadena están internados .

De JLS §4.12.4 - finalVariables :

Una variable de tipo o tipo primitivo String, que se finalinicializa con una expresión constante en tiempo de compilación (§15.28), se denomina variable constante .

También de JLS §15.28 - Expresión constante:

Las expresiones de tipo constantes en tiempo de compilación Stringsiempre están "internados" para compartir instancias únicas, utilizando el método String#intern().

Este no es el caso en su primer ejemplo de código, donde las Stringvariables no lo son final. Por lo tanto, no son expresiones constantes en tiempo de compilación. La operación de concatenación allí se retrasará hasta el tiempo de ejecución, lo que conducirá a la creación de un nuevo Stringobjeto. Puede verificar esto comparando el código de bytes de ambos códigos.

El primer ejemplo de código (no finalversión) se compila con el siguiente código de bytes:

  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

Claramente está almacenando stry ingen dos variables separadas, y está utilizando StringBuilderpara realizar la operación de concatenación.

Mientras que su segundo ejemplo de código ( finalversión) se ve así:

  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

Por lo tanto, alinea directamente la variable final para crear String stringen tiempo de compilación, que se carga por ldcoperación en el paso 0. Luego, el segundo literal de cadena se carga por ldcoperación en el paso 7. No implica la creación de ningún Stringobjeto nuevo en tiempo de ejecución. La cadena ya se conoce en tiempo de compilación, y están internadas.

Según mi investigación, todos final Stringestán internados en Java. De una de las publicaciones del blog:

Entonces, si realmente necesita comparar dos cadenas usando == o! = Asegúrese de llamar al método String.intern () antes de hacer la comparación. De lo contrario, siempre prefiera String.equals (String) para la comparación de String.

Por lo tanto, si llama String.intern()puede comparar dos cadenas usando el ==operador. Pero aquí String.intern()no es necesario porque en Java final Stringse interna internamente.

Puede encontrar más información Comparación de cadenas usando el operador == y Javadoc para el método String.intern () .

Consulte también esta publicación de Stackoverflow para obtener más información.

Si echas un vistazo a estos métodos

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");
}

y está descompilado con javap -c ClassWithTheseMethods versiones que verás

  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;
      ...

y

  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      
       ...

Entonces, si las cadenas no son el compilador final, tendrá que usar StringBuilderpara concatenar str1y str2así

String concat=str1+str2;

será compilado a

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

lo que significa que concatse creará en tiempo de ejecución, por lo que no vendrá del conjunto de cadenas.

Además, si las cadenas son finales, el compilador puede suponer que nunca cambiarán, por lo que, en lugar de usarlo StringBuilder, puede concatenar sus valores de manera segura

String concat = str1 + str2;

se puede cambiar a

String concat = "str" + "ing";

y concatenado en

String concat = "string";

lo que significa que concatese convertirá en un sting literal que se internará en el grupo de cadenas y luego se comparará con el mismo literal de cadena de ese grupo en la ifdeclaración.

Concepto de grupo de conts de pila y cuerda

Veamos un código de bytes para el finalejemplo.

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
}

En 0:y 2:, String "string"se empuja a la pila (desde el grupo constante) y se almacena concatdirectamente en la variable local . Puede deducir que el compilador está creando (concatenando) el String "string"mismo en el momento de la compilación.

El finalcódigo no byte

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
}

Aquí tiene dos Stringconstantes, "str"y "ing"que deben concatenarse en tiempo de ejecución con a StringBuilder.

Sin embargo, cuando crea utilizando la notación literal de String de Java, llama automáticamente al método intern () para poner ese objeto en el conjunto de String, siempre que no esté presente en el conjunto.

¿Por qué final hace la diferencia?

El compilador sabe que la variable final nunca cambiará, cuando agregamos estas variables finales, la salida va al conjunto de cadenas debido a str1 + str2que la salida de expresión tampoco cambiará, por lo que finalmente el compilador llama al método inter después de la salida de las dos variables finales anteriores. En el caso del compilador de variables no final, no llame al método interno.