Una stringa Java è davvero immutabile?

Sappiamo tutti che Stringè immutabile in Java, ma controlla il seguente codice:

String s1 = "Hello World";  
String s2 = "Hello World";  
String s3 = s1.substring(6);  
System.out.println(s1); // Hello World  
System.out.println(s2); // Hello World  
System.out.println(s3); // World  

Field field = String.class.getDeclaredField("value");  
field.setAccessible(true);  
char[] value = (char[])field.get(s1);  
value[6] = 'J';  
value[7] = 'a';  
value[8] = 'v';  
value[9] = 'a';  
value[10] = '!';  

System.out.println(s1); // Hello Java!  
System.out.println(s2); // Hello Java!  
System.out.println(s3); // World  

Perché questo programma funziona in questo modo? E perché il valore di s1e s2cambiato, ma non s3?

String è immutabile * ma ciò significa solo che non è possibile modificarlo utilizzando la sua API pubblica.

Quello che stai facendo qui è aggirare l'API normale, usando la riflessione. Allo stesso modo, è possibile modificare i valori degli enum, modificare la tabella di ricerca utilizzata nell'autoboxing intero, ecc.

Ora, la ragione s1e il s2valore di modifica, è che entrambi si riferiscono alla stessa stringa internata. Il compilatore fa questo (come indicato da altre risposte).

Il motivo s3non è stato in realtà un po 'sorprendente per me, poiché pensavo che avrebbe condiviso l' valuearray ( lo faceva nella versione precedente di Java , prima di Java 7u6). Tuttavia, osservando il codice sorgente di String, possiamo vedere che l' valuearray di caratteri per una sottostringa viene effettivamente copiato (usando Arrays.copyOfRange(..)). Questo è il motivo per cui rimane invariato.

È possibile installare un SecurityManager, per evitare che codice dannoso esegua tali operazioni. Ma tieni presente che alcune librerie dipendono dall'uso di questo tipo di trucchi di riflessione (in genere strumenti ORM, librerie AOP ecc.).

*) Inizialmente ho scritto che Stringnon sono veramente immutabili, solo "efficaci immutabili". Ciò potrebbe essere fuorviante nell'attuale implementazione di String, dove l' valuearray è effettivamente contrassegnato private final. Vale comunque la pena notare che non c'è modo di dichiarare immutabile un array in Java, quindi bisogna fare attenzione a non esporlo al di fuori della sua classe, anche con i modificatori di accesso appropriati.

Dato che questo argomento sembra estremamente popolare, ecco alcuni suggerimenti suggeriti da leggere ulteriormente: il discorso Reflection Madness di Heinz Kabutz da JavaZone 2009, che copre molti problemi dell'OP, insieme ad altre riflessioni ... beh ... follia.

Copre il motivo per cui a volte questo è utile. E perché, il più delle volte, dovresti evitarlo. :-)

In Java, se due variabili primitive di stringa sono inizializzate sullo stesso valore letterale, assegna lo stesso riferimento a entrambe le variabili:

String Test1="Hello World";
String Test2="Hello World";
System.out.println(test1==test2); // true

Questo è il motivo per cui il confronto ritorna vero. La terza stringa viene creata utilizzando il substring()quale crea una nuova stringa anziché puntare alla stessa.

Quando accedi a una stringa usando reflection, ottieni il puntatore effettivo:

Field field = String.class.getDeclaredField("value");
field.setAccessible(true);

Quindi la modifica a questo cambierà la stringa che tiene un puntatore ad essa, ma come s3viene creata con una nuova stringa a causa di substring()essa non cambierebbe.

Stai usando la riflessione per aggirare l'immutabilità di String - è una forma di "attacco".

Ci sono molti esempi che puoi creare in questo modo (ad esempio puoi anche creare un'istanza di un Voidoggetto ), ma ciò non significa che String non sia "immutabile".

Ci sono casi d'uso in cui questo tipo di codice può essere usato a tuo vantaggio ed essere "una buona codifica", come cancellare le password dalla memoria il prima possibile (prima di GC) .

A seconda del gestore della sicurezza, potrebbe non essere possibile eseguire il codice.

Si sta utilizzando la riflessione per accedere ai "dettagli di implementazione" dell'oggetto stringa. L'immutabilità è la caratteristica dell'interfaccia pubblica di un oggetto.

I modificatori di visibilità e il finale (cioè l'immutabilità) non sono una misura rispetto al codice dannoso in Java; sono semplicemente strumenti per proteggere dagli errori e per rendere il codice più mantenibile (uno dei maggiori punti di forza del sistema). Questo è il motivo per cui è possibile accedere ai dettagli dell'implementazione interna come l'array di caratteri di supporto per Strings tramite reflection.

Il secondo effetto che vedi è che tutti Stringcambiano mentre sembra che tu cambi solo s1. È una certa proprietà dei letterali String Java che vengono automaticamente internati, ovvero memorizzati nella cache. Due letterali String con lo stesso valore saranno effettivamente lo stesso oggetto. Quando crei una stringa con newessa non verrà internata automaticamente e non vedrai questo effetto.

#substringfino a poco tempo fa (Java 7u6) funzionava in modo simile, il che avrebbe spiegato il comportamento nella versione originale della tua domanda. Non ha creato un nuovo array di caratteri di supporto ma ha riutilizzato quello della stringa originale; ha appena creato un nuovo oggetto String che utilizzava un offset e una lunghezza per presentare solo una parte di tale array. Questo in genere ha funzionato poiché le stringhe sono immutabili, a meno che non lo si elimini. Questa proprietà #substringsignificava anche che l'intera stringa originale non poteva essere raccolta in modo inutile quando esisteva ancora una sottostringa più corta creata da essa.

A partire dall'attuale Java e dalla versione corrente della domanda non vi è alcun comportamento strano di #substring.

L'immutabilità delle stringhe è dal punto di vista dell'interfaccia. Stai usando reflection per bypassare l'interfaccia e modificare direttamente gli interni delle istanze String.

s1e s2sono entrambi cambiati perché sono entrambi assegnati alla stessa istanza String "intern". Puoi scoprire qualcosa in più su quella parte di questo articolo su uguaglianza delle stringhe e interning. Potresti essere sorpreso di scoprire che nel tuo codice di esempio, s1 == s2ritorna true!

Quale versione di Java stai usando? Da Java 1.7.0_06, Oracle ha modificato la rappresentazione interna di String, in particolare la sottostringa.

Citando dalla rappresentazione della stringa interna di Oracle Tunes Java :

Nel nuovo paradigma, i campi String offset e count sono stati rimossi, quindi le sottostringhe non condividono più il valore char [] sottostante.

Con questo cambiamento, può accadere senza riflessione (???).

Ci sono davvero due domande qui:

1. Le stringhe sono davvero immutabili?
2. Perché s3 non è cambiato?

Al punto 1: ad eccezione della ROM, non esiste memoria immutabile nel computer. Oggi anche la ROM è talvolta scrivibile. C'è sempre del codice da qualche parte (sia esso il kernel o il codice nativo che elude l'ambiente gestito) che può scrivere nel tuo indirizzo di memoria. Quindi, nella "realtà", no, non sono assolutamente immutabili.

Al punto 2: ciò è dovuto al fatto che la sottostringa sta probabilmente allocando una nuova istanza di stringa, che probabilmente sta copiando l'array. È possibile implementare la sottostringa in modo tale da non farne una copia, ma ciò non significa che lo faccia. Ci sono compromessi coinvolti.

Ad esempio, è necessario mantenere un riferimento per reallyLargeString.substring(reallyLargeString.length - 2)mantenere viva una grande quantità di memoria o solo pochi byte?

Dipende da come viene implementata la sottostringa. Una copia profonda manterrà meno memoria attiva, ma verrà eseguita leggermente più lentamente. Una copia superficiale manterrà viva più memoria, ma sarà più veloce. L'uso di una copia profonda può anche ridurre la frammentazione dell'heap, poiché l'oggetto stringa e il relativo buffer possono essere allocati in un blocco, al contrario di 2 allocazioni di heap separate.

In ogni caso, sembra che la tua JVM abbia scelto di utilizzare copie profonde per le chiamate di sottostringa.

Da aggiungere alla risposta di @ haraldK: si tratta di un hack di sicurezza che potrebbe causare un grave impatto nell'app.

La prima cosa è una modifica a una stringa costante memorizzata in un pool di stringhe. Quando la stringa viene dichiarata come a String s = "Hello World";, viene inserita in un pool di oggetti speciale per un ulteriore potenziale riutilizzo. Il problema è che il compilatore inserirà un riferimento alla versione modificata in fase di compilazione e una volta che l'utente modifica la stringa memorizzata in questo pool in fase di esecuzione, tutti i riferimenti nel codice punteranno alla versione modificata. Ciò comporterebbe un seguente bug:

System.out.println("Hello World"); 

Stampa:

Hello Java!

C'è stato un altro problema che ho riscontrato durante l'implementazione di un calcolo pesante su stringhe così rischiose. Si è verificato un errore in circa 1 su 1000000 volte durante il calcolo che ha reso il risultato indeterminato. Sono stato in grado di trovare il problema spegnendo la JIT - ottenevo sempre lo stesso risultato con la JIT disattivata. La mia ipotesi è che il motivo sia stato questo hack di sicurezza String che ha rotto alcuni dei contratti di ottimizzazione JIT.

Secondo il concetto di pooling, tutte le variabili String che contengono lo stesso valore punteranno allo stesso indirizzo di memoria. Pertanto s1 e s2, entrambi contenenti lo stesso valore di "Hello World", indicheranno la stessa posizione di memoria (ad esempio M1).

D'altra parte, s3 contiene "World", quindi indicherà una diversa allocazione di memoria (diciamo M2).

Quindi ora ciò che sta accadendo è che il valore di S1 ​​viene modificato (usando il valore char []). Quindi il valore nella posizione di memoria M1 indicato sia da s1 che da s2 è stato modificato.

Di conseguenza, la posizione di memoria M1 è stata modificata che causa la modifica del valore di s1 e s2.

Ma il valore della posizione M2 rimane invariato, quindi s3 contiene lo stesso valore originale.

Il motivo per cui s3 non cambia in realtà è perché in Java quando si esegue una sottostringa l'array di caratteri valore per una sottostringa viene copiato internamente (utilizzando Arrays.copyOfRange ()).

s1 e s2 sono uguali perché in Java si riferiscono entrambi alla stessa stringa internata. È progettato in Java.

String è immutabile, ma tramite la riflessione puoi modificare la classe String. Hai appena ridefinito la classe String come modificabile in tempo reale. Se lo desideri, puoi ridefinire i metodi in modo che siano pubblici, privati ​​o statici.

[Dichiarazione di non responsabilità si tratta di uno stile di risposta deliberatamente ponderato poiché ritengo che una risposta più "non farlo a casa dei bambini" sia garantita]

Il peccato è la linea field.setAccessible(true);che dice di violare l'api pubblica consentendo l'accesso a un campo privato. Questo è un enorme buco di sicurezza che può essere bloccato configurando un gestore della sicurezza.

Il fenomeno nella domanda sono i dettagli di implementazione che non vedresti mai quando non usi quella pericolosa riga di codice per violare i modificatori di accesso tramite la riflessione. Chiaramente due stringhe (normalmente) immutabili possono condividere lo stesso array di caratteri. Il fatto che una sottostringa condivida lo stesso array dipende dal fatto che possa o meno che lo sviluppatore abbia pensato di condividerlo. Normalmente si tratta di dettagli di implementazione invisibili che non dovresti conoscere se non spari al modificatore di accesso attraverso la testa con quella riga di codice.

Semplicemente non è una buona idea fare affidamento su tali dettagli che non possono essere sperimentati senza violare i modificatori di accesso mediante la riflessione. Il proprietario di quella classe supporta solo la normale API pubblica ed è libero di apportare modifiche all'implementazione in futuro.

Detto questo, la linea di codice è davvero molto utile quando hai una pistola che ti tiene in testa costringendoti a fare cose così pericolose. L'uso di quella backdoor è in genere un odore di codice che è necessario aggiornare a un codice di libreria migliore in cui non è necessario peccare. Un altro uso comune di quella pericolosa riga di codice è scrivere un "framework voodoo" (orm, container per iniezione, ...). Molte persone diventano religiose su tali schemi (sia a favore che contro di loro), quindi eviterò di invitare una guerra di fiamma dicendo che nient'altro che la stragrande maggioranza dei programmatori non deve andare lì.

Le stringhe vengono create nell'area permanente della memoria heap JVM. Quindi sì, è davvero immutabile e non può essere modificato dopo essere stato creato. Perché nella JVM esistono tre tipi di memoria heap: 1. Young generation 2. Old generation 3. Generazione permanente.

Quando viene creato un oggetto, viene inserito nell'area heap di generazione giovane e nell'area PermGen riservata al pool di stringhe.

Qui puoi trovare ulteriori dettagli e ottenere maggiori informazioni da: Come funziona Garbage Collection in Java .

String è immutabile in natura Perché non esiste un metodo per modificare l'oggetto String. Questo è il motivo per cui hanno introdotto le classi StringBuilder e StringBuffer