Quand devons-nous utiliser la méthode intern de String sur les littéraux de String ?

Question

Selon Chaîne#intern() , intern est censée renvoyer la chaîne du pool de chaînes si la chaîne est trouvée dans le pool de chaînes, sinon un nouvel objet chaîne sera ajouté au pool de chaînes et la référence de cette chaîne sera renvoyée.

J'ai donc essayé ceci :

String s1 = "Rakesh";
String s2 = "Rakesh";
String s3 = "Rakesh".intern();

if ( s1 == s2 ){
    System.out.println("s1 and s2 are same");  // 1.
}

if ( s1 == s3 ){
    System.out.println("s1 and s3 are same" );  // 2.
}

Je m'attendais à ce que s1 and s3 are same sera imprimé lorsque s3 sera interné, et s1 and s2 are same ne sera pas imprimé. Mais le résultat est : les deux lignes sont imprimées. Donc cela signifie que, par défaut, les constantes String sont internées. Mais si c'est le cas, alors pourquoi avons-nous besoin de l'option intern méthode ? En d'autres termes, quand devrions-nous utiliser cette méthode ?

Answer 1

Java internalise automatiquement les littéraux de type String. Cela signifie que dans de nombreux cas, l'opérateur == semble fonctionner pour les chaînes de caractères de la même manière que pour les ints ou d'autres valeurs primitives.

Étant donné que l'internage est automatique pour les littéraux de type String, la fonction intern() doit être utilisée sur les chaînes de caractères construites avec la méthode new String()

En utilisant votre exemple :

String s1 = "Rakesh";
String s2 = "Rakesh";
String s3 = "Rakesh".intern();
String s4 = new String("Rakesh");
String s5 = new String("Rakesh").intern();

if ( s1 == s2 ){
    System.out.println("s1 and s2 are same");  // 1.
}

if ( s1 == s3 ){
    System.out.println("s1 and s3 are same" );  // 2.
}

if ( s1 == s4 ){
    System.out.println("s1 and s4 are same" );  // 3.
}

if ( s1 == s5 ){
    System.out.println("s1 and s5 are same" );  // 4.
}

reviendra :

s1 and s2 are same
s1 and s3 are same
s1 and s5 are same

Dans tous les cas, à part celui de s4 dont la valeur a été explicitement créée à l'aide de la variable new et où intern n'a pas été utilisée sur son résultat, c'est une seule instance immuable qui est retournée. Le pool de constantes de la JVM .

Se référer à Techniques Java "Égalité et internationnalisation des chaînes de caractères". pour plus d'informations.

Answer 2

Dans le cadre d'un projet récent, d'énormes structures de données ont été mises en place avec des données qui ont été lues à partir d'une base de données (et donc pas de constantes/littérales de type String) mais avec une énorme quantité de duplications. Il s'agissait d'une application bancaire, et des éléments comme les noms d'un ensemble modeste (peut-être 100 ou 200) de sociétés apparaissaient un peu partout. Les structures de données étaient déjà grandes, et si tous ces noms de sociétés avaient été des objets uniques, elles auraient débordé de la mémoire. Au lieu de cela, toutes les structures de données avaient des références aux mêmes 100 ou 200 objets String, ce qui permettait de gagner beaucoup d'espace.

Un autre petit avantage des chaînes internées est que == peut être utilisé (avec succès !) pour comparer des chaînes de caractères si toutes les chaînes concernées sont garanties internées. En plus de la syntaxe allégée, ceci est également une amélioration des performances. Mais comme d'autres l'ont souligné, cette façon de faire comporte un risque élevé d'introduire des erreurs de programmation, et ne devrait donc être utilisée qu'en dernier recours.

L'inconvénient est que l'internage d'une chaîne prend plus de temps que le simple fait de la jeter sur le tas, et que l'espace pour les chaînes internées peut être limité, selon l'implémentation Java. Il est préférable d'utiliser cette méthode lorsque l'on a affaire à un nombre raisonnable de chaînes de caractères avec de nombreuses duplications.

Answer 3

Je veux ajouter mes deux cents sur l'utilisation == avec des chaînes internées.

La première chose String.equals fait est this==object .

Ainsi, bien qu'il y ait un gain de performance minuscule (vous n'appelez pas une méthode), du point de vue du mainteneur, l'utilisation de la méthode == est un cauchemar, car certaines chaînes internées ont tendance à devenir non internées.

Je suggère donc de ne pas s'appuyer sur le cas particulier du == pour les chaînes internées, mais utilisez toujours equals comme Gosling l'avait prévu.

EDIT : interné devient non-interné :

V1.0
public class MyClass
{
  private String reference_val;

  ...

  private boolean hasReferenceVal ( final String[] strings )
  {
    for ( String s : strings )
    {
      if ( s == reference_val )
      {
        return true;
      }
    }

    return false;
  }

  private void makeCall ( )
  {
     final String[] interned_strings =  { ... init with interned values ... };

     if ( hasReference( interned_strings ) )
     {
        ...
     }
  }
}

Dans la version 2.0, le mainteneur a décidé de faire de l'option hasReferenceVal public, sans trop préciser qu'il attend un tableau de chaînes internées.

V2.0
public class MyClass
{
  private String reference_val;

  ...

  public boolean hasReferenceVal ( final String[] strings )
  {
    for ( String s : strings )
    {
      if ( s == reference_val )
      {
        return true;
      }
    }

    return false;
  }

  private void makeCall ( )
  {
     final String[] interned_strings =  { ... init with interned values ... };

     if ( hasReference( interned_strings ) )
     {
        ...
     }
  }
}

Vous avez maintenant un bogue, qui peut être très difficile à trouver, car dans la majorité des cas, les tableaux contiennent des valeurs littérales, et parfois une chaîne non littérale est utilisée. Si equals ont été utilisés à la place de == puis hasReferenceVal aurait continué à fonctionner. Une fois encore, le gain de performance est minuscule, mais le coût de maintenance est élevé.

Answer 4

Les chaînes littérales et les constantes sont internées par défaut. C'est-à-dire, "foo" == "foo" (déclarés par les littéraux String), mais new String("foo") != new String("foo") .

Answer 5

Les chaînes de caractères internées évitent les chaînes de caractères en double. L'internage permet d'économiser de la RAM au prix d'un temps de calcul plus important pour détecter et remplacer les chaînes en double. Il n'existe qu'une seule copie de chaque chaîne de caractères internée, quel que soit le nombre de références qui y font référence. Les chaînes étant immuables, si deux méthodes différentes utilisent accidentellement la même chaîne, elles peuvent partager une copie de cette chaîne. Le processus de conversion des chaînes dupliquées en chaînes partagées s'appelle interne.String.intern() vous donne l'adresse de la chaîne maître canonique. Vous pouvez comparer les chaînes internées avec un simple == (qui compare les pointeurs) au lieu de est égal à qui compare les caractères de la chaîne un par un. Les chaînes étant immuables, le processus interne est libre d'économiser encore plus d'espace, par exemple en ne créant pas de littéral de chaîne distinct pour "pot" lorsqu'il existe en tant que sous-chaîne d'un autre littéral tel que "hippopotame".

Pour en savoir plus http://mindprod.com/jgloss/interned.html