Warum können Zeichenfolgen in Java und .NET nicht veränderbar sein?

Warum haben sie beschlossen, Stringin Java und .NET (und einigen anderen Sprachen) unveränderlich zu machen ? Warum haben sie es nicht veränderlich gemacht?

Laut Effective Java , Kapitel 4, Seite 73, 2. Ausgabe:

"Dafür gibt es viele gute Gründe: Unveränderliche Klassen sind einfacher zu entwerfen, zu implementieren und zu verwenden als veränderbare Klassen. Sie sind weniger fehleranfällig und sicherer.

[...]

" Unveränderliche Objekte sind einfach. Ein unveränderliches Objekt kann sich in genau einem Zustand befinden, dem Zustand, in dem es erstellt wurde. Wenn Sie sicherstellen, dass alle Konstruktoren Klasseninvarianten erstellen, ist garantiert, dass diese Invarianten für alle Zeiten mit wahr bleiben keine Anstrengung von Ihrer Seite.

[...]

Unveränderliche Objekte sind von Natur aus threadsicher. Sie erfordern keine Synchronisation. Sie können nicht durch mehrere Threads beschädigt werden, die gleichzeitig auf sie zugreifen. Dies ist bei weitem der einfachste Ansatz, um die Gewindesicherheit zu erreichen. Tatsächlich kann kein Thread jemals einen Effekt eines anderen Threads auf ein unveränderliches Objekt beobachten. Daher können unveränderliche Objekte frei geteilt werden

[...]

Weitere kleine Punkte aus demselben Kapitel:

Sie können nicht nur unveränderliche Objekte freigeben, sondern auch deren Interna.

[...]

Unveränderliche Objekte sind großartige Bausteine ​​für andere Objekte, ob veränderlich oder unveränderlich.

[...]

Der einzige wirkliche Nachteil unveränderlicher Klassen besteht darin, dass sie für jeden einzelnen Wert ein separates Objekt benötigen.

Es gibt mindestens zwei Gründe.

Erstens - Sicherheit http://www.javafaq.nu/java-article1060.html

Der Hauptgrund, warum String unveränderlich gemacht wurde, war die Sicherheit. Schauen Sie sich dieses Beispiel an: Wir haben eine Methode zum Öffnen von Dateien mit Anmeldeprüfung. Wir übergeben dieser Methode einen String, um die Authentifizierung zu verarbeiten, die erforderlich ist, bevor der Aufruf an das Betriebssystem weitergeleitet wird. Wenn String veränderbar war, war es möglich, seinen Inhalt nach der Authentifizierungsprüfung zu ändern, bevor das Betriebssystem eine Anforderung vom Programm erhält. Dann ist es möglich, eine beliebige Datei anzufordern. Wenn Sie also das Recht haben, eine Textdatei im Benutzerverzeichnis zu öffnen, aber dann im laufenden Betrieb, wenn Sie es irgendwie schaffen, den Dateinamen zu ändern, können Sie das Öffnen der Datei "passwd" oder einer anderen anfordern. Dann kann eine Datei geändert werden und es ist möglich, sich direkt beim Betriebssystem anzumelden.

Zweitens - Speichereffizienz http://hikrish.blogspot.com/2006/07/why-string-class-is-immutable.html

JVM verwaltet intern den "String Pool". Um die Speichereffizienz zu erreichen, verweist JVM auf das String-Objekt aus dem Pool. Die neuen String-Objekte werden nicht erstellt. Wenn Sie also ein neues Zeichenfolgenliteral erstellen, überprüft JVM im Pool, ob es bereits vorhanden ist oder nicht. Wenn bereits im Pool vorhanden, geben Sie einfach den Verweis auf dasselbe Objekt an oder erstellen Sie das neue Objekt im Pool. Es gibt viele Referenzen, die auf dieselben String-Objekte verweisen. Wenn jemand den Wert ändert, wirkt sich dies auf alle Referenzen aus. Also beschloss die Sonne, es unveränderlich zu machen.

Tatsächlich haben die Gründe, warum Zeichenfolgen in Java unveränderlich sind, nicht viel mit Sicherheit zu tun. Die zwei Hauptgründe sind die folgenden:

Thead Sicherheit:

Strings sind extrem weit verbreitete Objekttypen. Es ist daher mehr oder weniger garantiert, dass es in einer Multithread-Umgebung verwendet wird. Strings sind unveränderlich, um sicherzustellen, dass es sicher ist, Strings zwischen Threads zu teilen. Durch unveränderliche Zeichenfolgen wird sichergestellt, dass Thread B beim Übergeben von Zeichenfolgen von Thread A an einen anderen Thread B die Zeichenfolge von Thread A nicht unerwartet ändern kann.

Dies vereinfacht nicht nur die ohnehin schon ziemlich komplizierte Aufgabe der Multithread-Programmierung, sondern auch die Leistung von Multithread-Anwendungen. Der Zugriff auf veränderbare Objekte muss irgendwie synchronisiert werden, wenn auf sie von mehreren Threads aus zugegriffen werden kann, um sicherzustellen, dass ein Thread nicht versucht, den Wert Ihres Objekts zu lesen, während es von einem anderen Thread geändert wird. Eine ordnungsgemäße Synchronisierung ist für den Programmierer sowohl schwierig als auch zur Laufzeit teuer. Unveränderliche Objekte können nicht geändert werden und müssen daher nicht synchronisiert werden.

Performance:

Während String-Internierung erwähnt wurde, bedeutet dies nur einen geringen Gewinn an Speichereffizienz für Java-Programme. Es werden nur Zeichenfolgenliterale interniert. Dies bedeutet, dass nur die Zeichenfolgen, die in Ihrem Quellcode identisch sind, dasselbe Zeichenfolgenobjekt verwenden . Wenn Ihr Programm dynamisch gleiche Zeichenfolgen erstellt, werden diese in verschiedenen Objekten dargestellt.

Noch wichtiger ist, dass unveränderliche Zeichenfolgen es ihnen ermöglichen, ihre internen Daten gemeinsam zu nutzen. Für viele Zeichenfolgenoperationen bedeutet dies, dass das zugrunde liegende Zeichenarray nicht kopiert werden muss. Angenommen, Sie möchten die fünf ersten Zeichen von String übernehmen. In Java würden Sie myString.substring (0,5) aufrufen. In diesem Fall erstellt die substring () -Methode einfach ein neues String-Objekt, das das zugrunde liegende char [] von myString gemeinsam nutzt, aber wer weiß, dass es bei Index 0 beginnt und bei Index 5 dieses char [] endet. Um dies in grafische Form zu bringen, würden Sie am Ende Folgendes haben:

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

Dies macht diese Art von Operationen extrem billig und O (1), da die Operation weder von der Länge des ursprünglichen Strings noch von der Länge des zu extrahierenden Teilstrings abhängt. Dieses Verhalten hat auch einige Speichervorteile, da viele Zeichenfolgen ihr zugrunde liegendes Zeichen [] gemeinsam nutzen können.

Gewindesicherheit und Leistung. Wenn eine Zeichenfolge nicht geändert werden kann, ist es sicher und schnell, eine Referenz zwischen mehreren Threads weiterzugeben. Wenn Zeichenfolgen veränderbar wären, müssten Sie immer alle Bytes der Zeichenfolge in eine neue Instanz kopieren oder eine Synchronisierung bereitstellen. Eine typische Anwendung liest eine Zeichenfolge 100 Mal für jedes Mal, wenn diese Zeichenfolge geändert werden muss. Siehe Wikipedia zur Unveränderlichkeit .

Man sollte sich wirklich fragen: "Warum sollte X veränderlich sein?" Aufgrund der bereits von Princess Fluff bereits erwähnten Vorteile ist es besser, auf Unveränderlichkeit zurückzugreifen . Es sollte eine Ausnahme sein, dass etwas veränderlich ist.

Leider sind die meisten aktuellen Programmiersprachen standardmäßig veränderlich, aber hoffentlich liegt der Standard in Zukunft eher in der Unveränderlichkeit (siehe Eine Wunschliste für die nächste Mainstream-Programmiersprache ).

Beeindruckend! Ich kann die Fehlinformationen hier nicht glauben. Strings unveränderlich zu sein, hat nichts mit Sicherheit zu tun. Wenn jemand bereits Zugriff auf die Objekte in einer laufenden Anwendung hat (was angenommen werden muss, wenn Sie versuchen, sich vor jemandem zu schützen, der eine Stringin Ihrer App "hackt" ), bietet er sicherlich viele andere Möglichkeiten zum Hacken.

Es ist eine ziemlich neue Idee, dass die Unveränderlichkeit von StringThreading-Problemen angeht. Hmmm ... Ich habe ein Objekt, das von zwei verschiedenen Threads geändert wird. Wie löse ich das? Zugriff auf das Objekt synchronisieren? Naawww ... lassen wir niemanden das Objekt ändern - das wird alle unsere chaotischen Parallelitätsprobleme beheben! Lassen Sie uns alle Objekte unveränderlich machen, und dann können wir das synchronisierte Konstrukt aus der Java-Sprache entfernen.

Der wahre Grund (auf den oben von anderen hingewiesen wurde) ist die Speicheroptimierung. In jeder Anwendung ist es durchaus üblich, dass dasselbe Zeichenfolgenliteral wiederholt verwendet wird. Tatsächlich ist es so üblich, dass viele Compiler vor Jahrzehnten die Optimierung vorgenommen haben, nur eine einzige Instanz eines StringLiteral zu speichern . Der Nachteil dieser Optimierung besteht darin, dass Laufzeitcode, der ein StringLiteral ändert , ein Problem verursacht, da die Instanz für alle anderen Codes geändert wird, die es gemeinsam nutzen. Zum Beispiel wäre es für eine Funktion irgendwo in einer Anwendung nicht gut, das StringLiteral "dog"in zu ändern "cat". A printf("dog")würde dazu führen, "cat"dass in stdout geschrieben wird. Aus diesem Grund musste es eine Möglichkeit geben, sich vor Code zu schützen, der versucht, sich zu ändernStringLiterale (dh machen sie unveränderlich). Einige Compiler (mit Unterstützung des Betriebssystems) würden dies erreichen, indem sie das StringLiteral in ein spezielles schreibgeschütztes Speichersegment einfügen, das bei einem Schreibversuch einen Speicherfehler verursachen würde.

In Java wird dies als Internierung bezeichnet. Der Java-Compiler folgt hier nur einer Standardspeicheroptimierung, die Compiler seit Jahrzehnten durchführen. Um das gleiche Problem zu lösen, bei dem diese StringLiterale zur Laufzeit geändert werden, macht Java die StringKlasse einfach unveränderlich (d. H. Sie erhalten keine Setter, mit denen Sie den StringInhalt ändern können ). Strings müsste nicht unveränderlich sein, wenn Stringkeine Internierung von Literalen stattgefunden hätte .

String ist kein primitiver Typ, aber Sie möchten ihn normalerweise mit Wertesemantik verwenden, dh wie einen Wert.

Ein Wert, dem Sie vertrauen können, ändert sich hinter Ihrem Rücken nicht. Wenn Sie schreiben: String str = someExpr(); Sie möchten nicht, dass es sich ändert, es sei denn, Sie tun etwas damit str.

Stringals ein Objectnatürlich Zeiger Semantik hat, um Wertsemantik zu erhalten und es unveränderlich sein muss.

Ein Faktor ist, dass, wenn Strings veränderlich wäre, Objekte, die Strings speichern , vorsichtig sein müssten, um Kopien zu speichern, damit sich ihre internen Daten nicht ohne vorherige Ankündigung ändern. Angesichts der Tatsache, dass Strings ein ziemlich primitiver Typ wie Zahlen ist, ist es schön, wenn man sie so behandeln kann, als ob sie als Wert übergeben würden, selbst wenn sie als Referenz übergeben werden (was auch hilft, Speicherplatz zu sparen).

Ich weiß, das ist eine Beule, aber ... Sind sie wirklich unveränderlich? Folgendes berücksichtigen.

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

Sie könnten es sogar zu einer Erweiterungsmethode machen.

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

Welches macht die folgende Arbeit

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

Fazit: Sie befinden sich in einem unveränderlichen Zustand, der dem Compiler bekannt ist. Natürlich gilt das oben Gesagte nur für .NET-Zeichenfolgen, da Java keine Zeiger hat. Eine Zeichenfolge kann jedoch mithilfe von Zeigern in C # vollständig veränderbar sein. Es ist nicht so, wie Zeiger verwendet werden sollen, praktisch verwendet werden oder sicher verwendet werden. es ist jedoch möglich, die gesamte "veränderbare" Regel zu verbiegen. Normalerweise können Sie einen Index einer Zeichenfolge nicht direkt ändern. Dies ist der einzige Weg. Es gibt eine Möglichkeit, dies zu verhindern, indem Zeigerinstanzen von Zeichenfolgen nicht zugelassen werden oder eine Kopie erstellt wird, wenn auf eine Zeichenfolge verwiesen wird. Dies ist jedoch auch nicht der Fall, wodurch Zeichenfolgen in C # nicht vollständig unveränderlich werden.

Für die meisten Zwecke ist eine "Zeichenfolge" (verwendet / behandelt als / gedacht / angenommen) eine bedeutungsvolle atomare Einheit, genau wie eine Zahl .

Die Frage, warum die einzelnen Zeichen einer Zeichenfolge nicht veränderbar sind, entspricht der Frage, warum die einzelnen Bits einer Ganzzahl nicht veränderbar sind.

Sie sollten wissen warum. Denken Sie nur darüber nach.

Ich hasse es, es zu sagen, aber leider diskutieren wir darüber, weil unsere Sprache scheiße ist, und wir versuchen, ein einzelnes Wort, eine Zeichenfolge , zu verwenden, um ein komplexes, kontextbezogenes Konzept oder eine Klasse von Objekten zu beschreiben.

Wir führen Berechnungen und Vergleiche mit "Strings" durch, ähnlich wie wir es mit Zahlen tun. Wenn Zeichenfolgen (oder Ganzzahlen) veränderbar wären, müssten wir speziellen Code schreiben, um ihre Werte in unveränderliche lokale Formen zu sperren, damit jede Art von Berechnung zuverlässig durchgeführt werden kann. Daher ist es am besten, sich eine Zeichenfolge wie eine numerische Kennung vorzustellen, aber anstatt 16, 32 oder 64 Bit lang zu sein, kann sie Hunderte von Bit lang sein.

Wenn jemand "String" sagt, denken wir alle an verschiedene Dinge. Diejenigen, die es einfach als eine Reihe von Charakteren ohne besonderen Zweck betrachten, werden natürlich entsetzt sein, dass jemand gerade entschieden hat, dass sie diese Charaktere nicht manipulieren können sollten. Die "string" -Klasse besteht jedoch nicht nur aus einer Reihe von Zeichen. Es ist ein STRING, kein char[]. Es gibt einige grundlegende Annahmen über das Konzept, das wir als "Zeichenfolge" bezeichnen, und es kann allgemein als sinnvolle atomare Einheit codierter Daten wie eine Zahl beschrieben werden. Wenn Leute über das "Manipulieren von Strings" sprechen, sprechen sie vielleicht wirklich über das Manipulieren von Zeichen , um Strings zu erstellen , und ein StringBuilder ist dafür großartig.

Überlegen Sie sich für einen Moment, wie es wäre, wenn Zeichenfolgen veränderlich wären. Die folgende API-Funktion könnte dazu verleitet werden, Informationen für einen anderen Benutzer zurückzugeben, wenn die veränderbare Benutzernamenzeichenfolge absichtlich oder unbeabsichtigt von einem anderen Thread geändert wird, während diese Funktion sie verwendet:

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

Bei Sicherheit geht es nicht nur um "Zugangskontrolle", sondern auch um "Sicherheit" und "Gewährleistung der Korrektheit". Wenn eine Methode nicht einfach geschrieben und abhängig gemacht werden kann, um eine einfache Berechnung oder einen Vergleich zuverlässig durchzuführen, ist es nicht sicher, sie aufzurufen, aber es wäre sicher, die Programmiersprache selbst in Frage zu stellen.

Unveränderlichkeit ist nicht so eng mit Sicherheit verbunden. Dafür erhalten Sie zumindest in .NET die SecureStringKlasse.

Später bearbeiten: In Java finden Sie GuardedStringeine ähnliche Implementierung.

Die Entscheidung, String in C ++ veränderbar zu machen, verursacht viele Probleme. Siehe diesen ausgezeichneten Artikel von Kelvin Henney über Mad COW Disease .

COW = Beim Schreiben kopieren.

Es ist ein Kompromiss. Strings gehen in den StringPool und wenn Sie mehrere identische Strings erstellen , teilen sie sich den gleichen Speicher. Die Designer gingen davon aus, dass diese speichersparende Technik für den allgemeinen Fall gut geeignet ist, da Programme häufig über dieselben Zeichenfolgen laufen.

Der Nachteil ist, dass Verkettungen viele zusätzliche Strings verursachen, die nur vorübergehend sind und nur zu Müll werden, was die Speicherleistung tatsächlich beeinträchtigt. Sie müssen StringBufferund StringBuilder(in Java StringBuilderauch in .NET) verwenden, um in diesen Fällen Speicher zu erhalten.

Strings in Java sind nicht wirklich unveränderlich. Sie können ihre Werte mithilfe von Reflection und / oder Klassenladen ändern. Sie sollten aus Sicherheitsgründen nicht von dieser Eigenschaft abhängig sein. Beispiele finden Sie unter: Zaubertrick in Java

Unveränderlichkeit ist gut. Siehe Effektives Java. Wenn Sie einen String jedes Mal kopieren müssten, wenn Sie ihn weitergeben, wäre das eine Menge fehleranfälliger Code. Sie haben auch Verwirrung darüber, welche Änderungen welche Referenzen beeinflussen. Ebenso wie Integer unveränderlich sein muss, um sich wie int zu verhalten, müssen sich Strings unveränderlich verhalten, um sich wie Primitive zu verhalten. In C ++ erfolgt die Übergabe von Zeichenfolgen nach Wert ohne explizite Erwähnung im Quellcode.

Für fast jede Regel gibt es eine Ausnahme:

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

Es ist hauptsächlich aus Sicherheitsgründen. Es ist viel schwieriger, ein System zu sichern, wenn Sie nicht darauf vertrauen können, dass Ihre StringSysteme manipulationssicher sind.