Pourquoi les chaînes de caractères ne peuvent-elles pas être mutables en Java et .NET ?

Question

Comment se fait-il qu'ils aient décidé de faire String immuable en Java et .NET (et dans certains autres langages) ? Pourquoi ne l'ont-ils pas rendu mutable ?

Answer 1

Selon Java efficace chapitre 4, page 73, 2e édition :

" Il y a de nombreuses bonnes raisons à cela : Les classes immuables sont plus faciles à conception, d'implémentation et d'utilisation que les classes mutables. Elles sont moins sujettes aux erreurs et sont plus sûres.

[...]

" Les objets immuables sont simples. Un objet immuable peut être dans un seul état, celui dans lequel il a été créé. Si vous vous assurez que tous les constructeurs établissent des invariants de classe, alors il est garantie que ces invariants resteront vrais à tout moment, sans aucun aucun effort de votre part.

[...]

Les objets immuables sont intrinsèquement sûrs pour les fils de discussion ; ils ne nécessitent aucune synchronisation. Ils ne peuvent pas être corrompus par de multiples fils. qui y accèdent simultanément. C'est de loin l'approche la plus simple pour assurer la sécurité des threads. En fait, aucun thread ne peut jamais observer effet d'un autre thread sur un objet immuable. Par conséquent, les objets immuables peuvent être partagés librement

[...]

Autres petits points du même chapitre :

Non seulement vous pouvez partager des objets immuables, mais vous pouvez également partager leurs éléments internes.

[...]

Les objets immuables constituent d'excellents blocs de construction pour d'autres objets, qu'ils soient mutables ou immuables.

[...]

Le seul véritable inconvénient des classes immuables est qu'elles nécessitent un objet séparé pour chaque valeur distincte.

Answer 2

Il y a au moins deux raisons.

Premièrement - la sécurité http://www.javafaq.nu/java-article1060.html

La principale raison pour laquelle String a fait immuable était la sécurité. Regardez cet exemple : Nous avons une méthode d'ouverture de fichier avec vérification de la connexion. Nous passons une chaîne à cette méthode pour traiter l'authentification qui est nécessaire avant que l'appel soit transmis au système d'exploitation. Si la chaîne est mutable, il était possible d'une manière ou d'une autre de modifier son contenu après la contrôle d'authentification avant que l'OS ne reçoive demande du programme, alors il est possible possible de demander n'importe quel fichier. Ainsi, si vous avez le droit d'ouvrir un fichier texte dans répertoire de l'utilisateur mais qu'à la volée si vous parvenez à changer le nom du fichier nom du fichier, vous pouvez demander à ouvrir le fichier "passwd" ou un autre. Ensuite, un fichier fichier peut être modifié et il sera possible de se connecter directement à l'OS.

Deuxièmement - Efficacité de la mémoire http://hikrish.blogspot.com/2006/07/why-string-class-is-immutable.html

La JVM gère en interne le "String Pool". Pour atteindre l'efficacité de la mémoire l'efficacité de la mémoire, la JVM référera l'objet String à partir du pool. Elle ne créera pas les nouveaux objets String. Ainsi, chaque fois que vous créez une nouvelle chaîne littérale, la JVM vérifiera dans le pool si elle existe déjà ou non. Si elle est déjà présent dans le pool, il suffit de donner la référence au même objet ou de créer le nouvel objet dans le pool. Il y aura de nombreuses références pointent vers les mêmes objets String, si quelqu'un change la valeur, cela affectera toutes les références. Donc, Sun a décidé de la rendre immuable.

Answer 3

En fait, les raisons pour lesquelles les chaînes sont immuables en Java n'ont pas grand-chose à voir avec la sécurité. Les deux principales raisons sont les suivantes :

Sécurité de la théade :

Les chaînes de caractères sont un type d'objet extrêmement répandu. Il est donc plus ou moins garanti qu'elles seront utilisées dans un environnement multithread. Les chaînes de caractères sont immuables afin de garantir la sécurité du partage des chaînes de caractères entre les threads. Le fait d'avoir des chaînes immuables garantit que, lors du passage de chaînes du thread A à un autre thread B, le thread B ne peut pas modifier inopinément la chaîne du thread A.

Cela permet non seulement de simplifier la tâche déjà assez compliquée de la programmation multithread, mais aussi d'améliorer les performances des applications multithread. L'accès aux objets mutables doit être synchronisé d'une manière ou d'une autre lorsqu'ils sont accessibles à partir de plusieurs threads, afin de s'assurer qu'un thread ne tente pas de lire la valeur de votre objet pendant qu'il est modifié par un autre thread. Une synchronisation appropriée est à la fois difficile à réaliser correctement pour le programmeur et coûteuse au moment de l'exécution. Les objets immuables ne peuvent pas être modifiés et n'ont donc pas besoin de synchronisation.

Performance :

Bien que l'internage des chaînes de caractères ait été mentionné, il ne représente qu'un faible gain d'efficacité mémoire pour les programmes Java. Seuls les littéraux de chaîne sont internés. Cela signifie que seules les chaînes de caractères qui sont les mêmes dans votre fichier code source partageront le même String Object. Si votre programme crée dynamiquement des chaînes qui sont identiques, elles seront représentées dans des objets différents.

Plus important encore, les chaînes immuables leur permettent de partager leurs données internes. Pour de nombreuses opérations sur les chaînes, cela signifie que le tableau de caractères sous-jacent ne doit pas être copié. Par exemple, disons que vous voulez prendre les cinq premiers caractères de String. En Java, vous appelleriez maChaîne.substring(0,5). Dans ce cas, la méthode substring() crée simplement un nouvel objet String qui partage le char[] sous-jacent de myString mais qui sait qu'il commence à l'indice 0 et se termine à l'indice 5 de ce char[]. Pour exprimer cela sous forme graphique, vous obtiendrez ce qui suit :

 |               myString                  |
 v                                         v
"The quick brown fox jumps over the lazy dog"   <-- shared char[]
 ^   ^
 |   |  myString.substring(0,5)

Cela rend ce type d'opérations extrêmement bon marché, et O(1) puisque l'opération ne dépend ni de la longueur de la chaîne originale, ni de la longueur de la sous-chaîne que nous devons extraire. Ce comportement présente également des avantages en termes de mémoire, puisque de nombreuses chaînes de caractères peuvent partager leur char[] sous-jacent.

Answer 4

Sécurité et performance des filets. Si une chaîne ne peut pas être modifiée, il est sûr et rapide de faire circuler une référence entre plusieurs threads. Si les chaînes étaient mutables, il faudrait toujours copier tous les octets de la chaîne dans une nouvelle instance, ou fournir une synchronisation. Une application typique lira une chaîne 100 fois à chaque fois que cette chaîne devra être modifiée. Voir wikipedia sur immutabilité .

Answer 5

On devrait vraiment se demander, "pourquoi X devrait-il être mutable ?" Il vaut mieux opter pour l'immuabilité par défaut, en raison des avantages déjà mentionnés par Princesse Fluff . Le fait que quelque chose soit mutable devrait être une exception.

Malheureusement, la plupart des langages de programmation actuels optent par défaut pour la mutabilité, mais nous espérons qu'à l'avenir, le choix se portera davantage sur l'immuabilité (cf. Une liste de souhaits pour le prochain langage de programmation grand public ).