Pourquoi les chaînes ne peuvent-elles pas être mutées en Java et .NET?

Pourquoi ont-ils décidé de rendre Stringimmuable en Java et .NET (et dans d'autres langages)? Pourquoi ne l'ont-ils pas rendu mutable?

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

«Il existe de nombreuses bonnes raisons à cela: les classes immuables sont plus faciles à concevoir, à implémenter et à utiliser 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 exactement un état, l'état dans lequel il a été créé. Si vous vous assurez que tous les constructeurs établissent des invariants de classe, alors il est garanti que ces invariants resteront vrais pour toujours, avec aucun effort de votre part.

[...]

Les objets immuables sont intrinsèquement thread-safe; ils ne nécessitent aucune synchronisation. Ils ne peuvent pas être corrompus par plusieurs threads qui y accèdent simultanément. C'est de loin l'approche la plus simple pour assurer la sécurité des fils. En fait, aucun thread ne peut jamais observer l'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 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.

Il y a au moins deux raisons.

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

La principale raison pour laquelle String est devenu immuable était la sécurité. Regardez cet exemple: Nous avons une méthode d'ouverture de fichier avec vérification de connexion. Nous transmettons une chaîne à cette méthode pour traiter l'authentification qui est nécessaire avant que l'appel ne soit passé au système d'exploitation. Si String était mutable, il était possible de modifier son contenu après la vérification d'authentification avant que le système d'exploitation ne reçoive la demande du programme, il est alors possible de demander n'importe quel fichier. Donc, si vous avez le droit d'ouvrir un fichier texte dans le répertoire utilisateur, mais à la volée lorsque vous parvenez à changer le nom du fichier, vous pouvez demander d'ouvrir le fichier "passwd" ou tout autre. Ensuite, un 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

JVM gère en interne le "String Pool". Pour atteindre l'efficacité de la mémoire, JVM référencera l'objet String du pool. Il ne créera pas les nouveaux objets String. Ainsi, chaque fois que vous créez un nouveau littéral de chaîne, JVM vérifiera dans le pool s'il existe déjà ou non. S'il est déjà présent dans le pool, donnez simplement la référence au même objet ou créez le nouvel objet dans le pool. Il y aura de nombreuses références pointant vers les mêmes objets String, si quelqu'un change la valeur, cela affectera toutes les références. Ainsi, le soleil a décidé de le rendre immuable.

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

Sécurité de la tête:

Les chaînes sont un type d'objet extrêmement largement utilisé. Il est donc plus ou moins garanti d'être utilisé dans un environnement multi-thread. Les chaînes sont immuables pour s'assurer qu'il est sûr de partager des chaînes 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 de manière inattendue la chaîne du thread A.

Non seulement cela aide à simplifier la tâche déjà assez compliquée de la programmation multi-thread, mais cela aide également à la performance des applications multi-thread. L'accès aux objets mutables doit en quelque sorte être synchronisé lorsqu'ils sont accessibles à partir de plusieurs threads, pour s'assurer qu'un thread ne tente pas de lire la valeur de votre objet pendant qu'il est en cours de modification par un autre thread. Une synchronisation correcte est à la fois difficile à faire correctement pour le programmeur et coûteuse à l'exécution. Les objets immuables ne peuvent pas être modifiés et n'ont donc pas besoin de synchronisation.

Performance:

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

Plus important encore, les chaînes immuables leur permettent de partager leurs données internes. Pour de nombreuses opérations de chaîne, cela signifie que le tableau de caractères sous-jacent n'a pas besoin d'être copié. Par exemple, supposons que vous souhaitiez utiliser les cinq premiers caractères de String. En Java, vous appelleriez myString.substring (0,5). Dans ce cas, ce que fait la méthode substring () est simplement de créer un nouvel objet String qui partage le char sous-jacent de myString [] mais qui sait qu'il commence à l'index 0 et se termine à l'index 5 de ce char []. Pour mettre cela sous forme graphique, vous vous retrouveriez avec ce qui suit:

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

Cela rend ce genre 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 d'origine, ni de la longueur de la sous-chaîne que nous devons extraire. Ce comportement présente également certains avantages en matière de mémoire, car de nombreuses chaînes peuvent partager leur char [] sous-jacent.

Sécurité et performances du filetage. Si une chaîne ne peut pas être modifiée, il est sûr et rapide de passer une référence entre plusieurs threads. Si les chaînes étaient mutables, vous devrez toujours copier tous les octets de la chaîne dans une nouvelle instance ou assurer la synchronisation. Une application typique lira une chaîne 100 fois à chaque fois que cette chaîne doit être modifiée. Voir wikipedia sur l' immuabilité .

On devrait vraiment se demander "pourquoi X devrait-il être mutable?" Il est préférable de choisir par défaut l'immuabilité, en raison des avantages déjà mentionnés par Princess Fluff . Ce devrait être une exception que quelque chose est mutable.

Malheureusement, la plupart des langages de programmation actuels utilisent par défaut la mutabilité, mais j'espère que dans le futur, la valeur par défaut est davantage sur l'immutabilité (voir Une liste de souhaits pour le prochain langage de programmation grand public ).

Hou la la! Je ne peux pas croire la désinformation ici. Strings étant immuable n'ont rien avec la sécurité. Si quelqu'un a déjà accès aux objets dans une application en cours d'exécution (ce qui devrait être supposé si vous essayez de vous prémunir contre quelqu'un qui `` pirate '' un Stringdans votre application), il y aura certainement de nombreuses autres possibilités de piratage.

C'est une idée assez nouvelle dont l'immuabilité Stringrésout les problèmes de filetage. Hmmm ... J'ai un objet qui est modifié par deux threads différents. Comment résoudre ça? synchroniser l'accès à l'objet? Naawww ... ne laissons personne du tout changer l'objet - cela résoudra tous nos problèmes de concurrence désordonnés! En fait, rendons tous les objets immuables, puis nous pourrons supprimer la structure synchronisée du langage Java.

La vraie raison (soulignée par d'autres ci-dessus) est l'optimisation de la mémoire. Il est assez courant dans toute application que le même littéral de chaîne soit utilisé à plusieurs reprises. Il est si courant, en fait, qu'il y a des décennies, de nombreux compilateurs ont optimisé le stockage d'une seule instance d'un Stringlittéral. L'inconvénient de cette optimisation est que le code d'exécution qui modifie un Stringlittéral introduit un problème car il modifie l'instance pour tout autre code qui la partage. Par exemple, il ne serait pas bon pour une fonction quelque part dans une application de changer le Stringlittéral "dog"en "cat". A printf("dog")entraînerait l' "cat"écriture sur stdout. Pour cette raison, il devait y avoir un moyen de se prémunir contre le code qui tente de changerStringlittéraux (c'est-à-dire les rendre immuables). Certains compilateurs (avec le support du système d'exploitation) accompliraient cela en plaçant Stringlittéral dans un segment de mémoire spécial en lecture seule qui provoquerait une erreur de mémoire si une tentative d'écriture était faite.

En Java, cela s'appelle le stage. Le compilateur Java ici ne fait que suivre une optimisation de la mémoire standard effectuée par des compilateurs depuis des décennies. Et pour résoudre le même problème de Stringmodification de ces littéraux au moment de l'exécution, Java rend simplement la Stringclasse immuable (c'est-à-dire, ne vous donne aucun paramètre qui vous permettrait de modifier le Stringcontenu). Strings n'aurait pas à être immuable si l'internement de Stringlittéraux ne se produisait pas.

String n'est pas un type primitif, mais vous voulez normalement l'utiliser avec une sémantique de valeur, c'est-à-dire comme une valeur.

Une valeur est quelque chose dont vous pouvez avoir confiance et qui ne changera pas derrière votre dos. Si vous écrivez: String str = someExpr(); Vous ne voulez pas que cela change à moins que VOUS ne fassiez quelque chose avec str.

Stringcomme un Objecta naturellement une sémantique de pointeur, pour obtenir également une sémantique de valeur, il doit être immuable.

Un facteur est que, si Strings était mutable, les objets stockant Strings devraient faire attention à stocker des copies, de peur que leurs données internes ne changent sans préavis. Étant donné que les Strings sont un type assez primitif comme les nombres, c'est bien quand on peut les traiter comme s'ils étaient passés par valeur, même s'ils sont passés par référence (ce qui permet également d'économiser de la mémoire).

Je sais que c'est une bosse, mais ... Sont-ils vraiment immuables? Considérer ce qui suit.

public static unsafe void MutableReplaceIndex(string s, char c, int i)
{
    fixed (char* ptr = s)
    {
        *((char*)(ptr + i)) = c;
    }
}

...

string s = "abc";
MutableReplaceIndex(s, '1', 0);
MutableReplaceIndex(s, '2', 1);
MutableReplaceIndex(s, '3', 2);
Console.WriteLine(s); // Prints 1 2 3

Vous pouvez même en faire une méthode d'extension.

public static class Extensions
{
    public static unsafe void MutableReplaceIndex(this string s, char c, int i)
    {
        fixed (char* ptr = s)
        {
            *((char*)(ptr + i)) = c;
        }
    }
}

Ce qui fait le travail suivant

s.MutableReplaceIndex('1', 0);
s.MutableReplaceIndex('2', 1);
s.MutableReplaceIndex('3', 2);

Conclusion: Ils sont dans un état immuable connu du compilateur. Bien sûr, ce qui précède ne s'applique qu'aux chaînes .NET car Java n'a pas de pointeurs. Cependant, une chaîne peut être entièrement modifiable en utilisant des pointeurs en C #. Ce n'est pas la façon dont les pointeurs sont destinés à être utilisés, ont une utilisation pratique ou sont utilisés en toute sécurité; c'est cependant possible, contournant ainsi toute la règle "mutable". Vous ne pouvez normalement pas modifier directement un index d'une chaîne et c'est le seul moyen. Il existe un moyen d'empêcher cela en interdisant les instances de pointeur de chaînes ou en effectuant une copie lorsqu'une chaîne est pointée, mais ni l'un ni l'autre n'est fait, ce qui rend les chaînes en C # pas entièrement immuables.

Dans la plupart des cas, une "chaîne" est (utilisée / traitée comme / pensée / supposée être) une unité atomique significative , tout comme un nombre .

Demander pourquoi les caractères individuels d'une chaîne ne sont pas mutables revient donc à demander pourquoi les bits individuels d'un entier ne sont pas mutables.

Tu devrais savoir pourquoi. Pensez-y.

Je déteste le dire, mais malheureusement, nous en débattons parce que notre langage est nul, et nous essayons d'utiliser un seul mot, une chaîne , pour décrire un concept ou une classe d'objet complexe et contextuellement situé.

Nous effectuons des calculs et des comparaisons avec des «chaînes», comme nous le faisons avec des nombres. Si les chaînes (ou les entiers) étaient mutables, nous aurions à écrire un code spécial pour verrouiller leurs valeurs dans des formes locales immuables afin d'effectuer n'importe quel type de calcul de manière fiable. Par conséquent, il est préférable de penser à une chaîne comme un identifiant numérique, mais au lieu d'avoir une longueur de 16, 32 ou 64 bits, elle pourrait comporter des centaines de bits.

Quand quelqu'un dit "string", nous pensons tous à des choses différentes. Ceux qui le considèrent simplement comme un ensemble de personnages, sans but particulier en tête, seront bien sûr consternés que quelqu'un vient de décider de ne pas pouvoir manipuler ces personnages. Mais la classe "string" n'est pas seulement un tableau de caractères. C'est un STRING, pas un char[]. Il y a quelques hypothèses de base sur le concept que nous appelons une «chaîne», et il peut généralement être décrit comme une unité atomique significative de données codées comme un nombre. Quand les gens parlent de "manipuler des chaînes", ils parlent peut-être vraiment de manipuler des caractères pour créer des chaînes , et un StringBuilder est parfait pour cela.

Considérez un instant ce que ce serait si les chaînes étaient mutables. La fonction API suivante pourrait être amenée à renvoyer des informations pour un utilisateur différent si la chaîne de nom d'utilisateur mutable est intentionnellement ou non modifiée par un autre thread pendant que cette fonction l'utilise:

string GetPersonalInfo( string username, string password )
{
    string stored_password = DBQuery.GetPasswordFor( username );
    if (password == stored_password)
    {
        //another thread modifies the mutable 'username' string
        return DBQuery.GetPersonalInfoFor( username );
    }
}

La sécurité n'est pas seulement une question de «contrôle d'accès», c'est aussi une question de «sécurité» et de «garantie d'exactitude». Si une méthode ne peut pas être facilement écrite et dépendante pour effectuer un simple calcul ou une comparaison de manière fiable, il n'est pas sûr de l'appeler, mais il serait prudent de remettre en question le langage de programmation lui-même.

L'immuabilité n'est pas si étroitement liée à la sécurité. Pour cela, au moins dans .NET, vous obtenez la SecureStringclasse.

Edition ultérieure: En Java, vous trouverez GuardedStringune implémentation similaire.

La décision d'avoir une chaîne mutable en C ++ pose beaucoup de problèmes, voir cet excellent article de Kelvin Henney sur Mad COW Disease .

COW = Copie en écriture.

C'est un compromis. Strings vont dans le Stringpool et lorsque vous créez plusieurs Strings identiques, ils partagent la même mémoire. Les concepteurs ont pensé que cette technique d'économie de mémoire fonctionnerait bien pour le cas courant, car les programmes ont tendance à broyer beaucoup les mêmes chaînes.

L'inconvénient est que les concaténations font beaucoup de Strings supplémentaires qui ne sont que transitionnels et deviennent simplement des déchets, nuisant en fait aux performances de la mémoire. Vous avez StringBufferet StringBuilder(en Java, StringBuilderest également dans .NET) à utiliser pour préserver la mémoire dans ces cas.

StringLes s en Java ne sont pas vraiment immuables, vous pouvez changer leur valeur en utilisant la réflexion et / ou le chargement de classe. Vous ne devriez pas dépendre de cette propriété pour la sécurité. Pour des exemples, voir: Magic Trick en Java

L'immuabilité est bonne. Voir Java efficace. Si vous deviez copier une chaîne à chaque fois que vous la passiez, alors ce serait beaucoup de code sujet aux erreurs. Vous ne savez pas non plus quelles modifications affectent quelles références. De la même manière qu'Integer doit être immuable pour se comporter comme int, les chaînes doivent se comporter comme immuables pour agir comme des primitives. En C ++, le passage des chaînes par valeur le fait sans mention explicite dans le code source.

Il existe une exception pour presque toutes les règles:

using System;
using System.Runtime.InteropServices;

namespace Guess
{
    class Program
    {
        static void Main(string[] args)
        {
            const string str = "ABC";

            Console.WriteLine(str);
            Console.WriteLine(str.GetHashCode());

            var handle = GCHandle.Alloc(str, GCHandleType.Pinned);

            try
            {
                Marshal.WriteInt16(handle.AddrOfPinnedObject(), 4, 'Z');

                Console.WriteLine(str);
                Console.WriteLine(str.GetHashCode());
            }
            finally
            {
                handle.Free();
            }
        }
    }
}

C'est en grande partie pour des raisons de sécurité. Il est beaucoup plus difficile de sécuriser un système si vous ne pouvez pas croire que vos Strings sont inviolables.