Perché String è immutabile in Java?

In un'intervista mi è stato chiesto perché String sia immutabile

Ho risposto così:

Quando creiamo una stringa in Java come String s1="hello";allora un oggetto verrà creato nel pool di stringhe (ciao) e s1 punterà a ciao . Ora, se lo facciamo di String s2="hello";nuovo, non verrà creato un altro oggetto ma s2 punterà a hello perché JVM controllerà prima se lo stesso oggetto è presente nel pool di stringhe oppure no. Se non presente, ne viene creato solo uno nuovo, altrimenti.

Ora se supponiamo che java consenta la modifica della stringa, se cambiamo s1 in hello worldallora il valore di s2 sarà anche hello worldcosì java String è immutabile.

Qualcuno può dirmi se la mia risposta è giusta o sbagliata ?

String è immutabile per diversi motivi, ecco un riassunto:

• Sicurezza : i parametri sono in genere rappresentati come Stringnelle connessioni di rete, negli URL di connessione al database, nei nomi utente / password ecc. Se fosse mutabile, questi parametri potrebbero essere facilmente modificati.
• Sincronizzazione e concorrenza: rendere String immutabile rende automaticamente i thread sicuri, risolvendo così i problemi di sincronizzazione.
• Caching : quando il compilatore ottimizza i tuoi oggetti String, vede che se due oggetti hanno lo stesso valore (a = "test" e b = "test") e quindi hai bisogno di un solo oggetto stringa (sia per a che per questi due puntare allo stesso oggetto).
• Caricamento di classe : Stringviene utilizzato come argomento per il caricamento di classe. Se mutabile, potrebbe comportare il caricamento di una classe errata (poiché gli oggetti mutabili cambiano il loro stato).

Detto questo, l'immutabilità Stringsignifica solo che non puoi cambiarlo usando la sua API pubblica. Puoi infatti bypassare l'API normale usando reflection. Vedi la risposta qui .

Nel tuo esempio, se Stringfosse mutabile, considera il seguente esempio:

  String a="stack";
  System.out.println(a);//prints stack
  a.setValue("overflow");
  System.out.println(a);//if mutable it would print overflow

Gli sviluppatori Java decidono che le stringhe sono immutabili a causa del seguente aspetto , efficienza e sicurezza .

Le stringhe di progettazione vengono create in un'area di memoria speciale nell'heap java noto come "String Intern pool". Durante la creazione di una nuova stringa (non nel caso dell'utilizzo del costruttore String () o di qualsiasi altra funzione String che utilizza internamente il costruttore String () per creare un nuovo oggetto String; il costruttore String () crea sempre una nuova costante stringa nel pool a meno che non chiama la variabile metodo intern () ) che cerca nel pool per verificare se esiste già. Se esiste, restituisce il riferimento dell'oggetto String esistente. Se la stringa non è immutabile, cambiando la stringa con un riferimento si otterrà un valore errato per gli altri riferimenti.

Secondo questo articolo su DZone:

La stringa di sicurezza è ampiamente utilizzata come parametro per molte classi java, ad es. Connessione di rete, apertura di file, ecc. Se la stringa non fosse immutabile, una connessione o un file verrebbero modificati e porterebbe a gravi minacce alla sicurezza. Le stringhe mutabili potrebbero causare problemi di sicurezza anche in Reflection, poiché i parametri sono stringhe.

Efficienza L'hashcode della stringa viene spesso utilizzato in Java. Ad esempio, in una HashMap. Essere immutabili garantisce che l'hashcode sarà sempre lo stesso, in modo che possa essere memorizzato nella cache senza preoccuparsi delle modifiche. Ciò significa che non è necessario calcolare l'hashcode ogni volta che viene utilizzato.

Non possiamo essere sicuri di cosa stessero realmente pensando i progettisti Java durante la progettazione, Stringma possiamo solo concludere queste ragioni sulla base dei vantaggi che otteniamo dall'immutabilità delle stringhe, alcune delle quali sono

1. Esistenza del pool di costanti di stringhe

Come discusso nell'articolo Perché String è memorizzato nell'articolo String Constant Pool , ogni applicazione crea troppi oggetti stringa e al fine di salvare JVM dalla prima creazione di molti oggetti stringa e quindi dalla loro immondizia. JVM memorizza tutti gli oggetti stringa in un'area di memoria separata chiamata Pool costante di stringhe e riutilizza gli oggetti da quel pool memorizzato nella cache.

Ogni volta che creiamo una stringa JVM letterale per prima cosa vede se quel letterale è già presente nel pool costante o meno e se è presente, un nuovo riferimento inizierà a puntare allo stesso oggetto in SCP.

String a = "Naresh";
String b = "Naresh";
String c = "Naresh";

Supra oggetto stringa esempio con valore Nareshandranno creato nel SCP sola volta e ogni riferimento a, b, cpunterà allo stesso oggetto ma se si cerca di apportare cambiamenti in aes a.replace("a", "").

Idealmente, adovrebbe avere valore Nreshma b, cdovrebbe rimanere invariato perché come utente finale stiamo effettuando la modifica asolo. E sappiamo a, b, ctutti stanno indicando lo stesso oggetto quindi se facciamo un cambiamento a, altri dovrebbe anche riflettere il cambiamento.

Ma l'immutabilità delle stringhe ci salva da questo scenario e, a causa dell'immutabilità dell'oggetto stringa, l'oggetto stringa Nareshnon cambierà mai. Pertanto, quando apportiamo modifiche aanziché modifiche nell'oggetto stringa, NareshJVM crea un nuovo oggetto assegnandolo ae quindi apportando le modifiche in tale oggetto.

Quindi il pool di stringhe è possibile solo a causa dell'immutabilità di String e se String non fosse stato immutabile, la memorizzazione nella cache degli oggetti stringa e il loro riutilizzo non avrebbero possibilità perché qualsiasi variabile avrebbe cambiato il valore e danneggiato altri.

Ed è per questo che è gestito da JVM in modo molto speciale e ha ricevuto un'area di memoria speciale.

2. Sicurezza del filo

Un oggetto viene chiamato thread-safe quando più thread ci stanno operando, ma nessuno di essi è in grado di corromperne lo stato e l'oggetto mantiene lo stesso stato per ogni thread in qualsiasi momento.

Dato che un oggetto immutabile non può essere modificato da nessuno dopo la sua creazione, il che rende ogni oggetto immutabile sicuro per impostazione predefinita. Non è necessario applicare alcuna misura di sicurezza del thread come la creazione di metodi sincronizzati.

Quindi, a causa della sua natura immutabile, l'oggetto stringa può essere condiviso da più thread e anche se viene manipolato da molti thread non cambierà il suo valore.

3. Sicurezza

In ogni applicazione, è necessario passare diversi segreti, ad esempio nome utente \ password, URL di connessione e, in generale, tutte queste informazioni vengono passate come oggetto stringa.

Supponiamo ora che String non sarebbe stato immutabile in natura, quindi causerebbe una grave minaccia alla sicurezza dell'applicazione perché questi valori possono essere modificati e se è consentito, questi potrebbero essere modificati a causa di un codice scritto erroneamente o di qualsiasi altra persona che avere accesso ai nostri riferimenti variabili.

4. Caricamento classe

Come discusso in Creazione di oggetti tramite Reflection in Java con Esempio , possiamo usare il Class.forName("class_name")metodo per caricare una classe in memoria che chiama nuovamente altri metodi per farlo. E anche JVM utilizza questi metodi per caricare le classi.

Ma se vedi chiaramente tutti questi metodi accetta il nome della classe come oggetto stringa, quindi le stringhe vengono utilizzate nel caricamento della classe java e l'immutabilità garantisce la sicurezza da cui viene caricata la classe corretta ClassLoader.

Supponiamo che String non sia immutabile e stiamo provando a caricare i java.lang.Objectquali vengono cambiati org.theft.OurObjectnel mezzo e ora tutti i nostri oggetti hanno un comportamento che qualcuno può usare per cose indesiderate.

5. HashCode nella cache

Se eseguiremo operazioni correlate all'hash su qualsiasi oggetto, dovremo sovrascrivere il hashCode()metodo e provare a generare un hashcode accurato utilizzando lo stato dell'oggetto. Se lo stato di un oggetto viene modificato, significa che dovrebbe cambiare anche il suo hashcode.

Poiché String è immutabile, quindi il valore di un oggetto stringa non verrà mai modificato, il che significa che anche il suo hashcode non cambierà, dando alla classe String l'opportunità di memorizzare nella cache il suo hashcode durante la creazione dell'oggetto.

Sì, l'oggetto String memorizza nella cache il suo hashcode al momento della creazione dell'oggetto, il che lo rende il candidato ideale per le operazioni correlate all'hash perché non è necessario calcolare nuovamente l'hashcode che ci fa risparmiare un po 'di tempo. Questo è il motivo per cui String è usato principalmente come HashMapchiavi.

Maggiori informazioni sul motivo per cui String è immutabile e finale in Java .

La ragione più importante secondo questo articolo su DZone:

Pool di costanti stringa ... Se la stringa è mutabile, la modifica della stringa con un riferimento comporterà un valore errato per gli altri riferimenti.

Sicurezza

String è ampiamente usato come parametro per molte classi java, ad es. Connessione di rete, apertura di file, ecc. Se String non fosse immutabile, una connessione o un file verrebbero modificati e porterebbe a gravi minacce alla sicurezza. ...

Spero che ti possa aiutare.

Ho letto questo post Perché String è immutabile o finale in Java e suppongo che il seguente possa essere il motivo più importante:

String è immutabile in Java perché gli oggetti String sono memorizzati nella cache del pool String . Poiché i valori letterali String memorizzati nella cache sono condivisi tra più client, esiste sempre un rischio, in cui l'azione di un client influirebbe su un altro client.

Hai ragione. Stringin java usa il concetto di String Poolletterale. Quando viene creata una stringa e se la stringa esiste già nel pool, verrà restituito il riferimento della stringa esistente, invece di creare un nuovo oggetto e restituirne il riferimento. Se una stringa non è immutabile, modificando la stringa con un riferimento verrà portare a un valore errato per gli altri riferimenti.

Vorrei aggiungere un'altra cosa, poiché Stringè immutabile, è sicuro per il multi threading e una singola istanza String può essere condivisa tra thread diversi. Questo evita l'uso della sincronizzazione per la sicurezza dei thread, le stringhe sono implicitamente thread safe.

Classe di stringa FINALsignifica che non è possibile creare alcuna classe per ereditarla e modificare la struttura di base e rendere mutevole la puntura.

Un'altra variabile di istanza e i metodi della classe String forniti sono tali che non è possibile modificare l' Stringoggetto una volta creato.

Il motivo che hai aggiunto non rende affatto la stringa immutabile. Tutto ciò dice come la stringa è memorizzata nell'heap. Anche il pool di stringhe fa l'enorme differenza nelle prestazioni

La stringa viene data come immutabile dai micro sistemi Sun, poiché può essere utilizzata per archiviare come chiave nella raccolta mappe. StringBuffer è modificabile. Questo è il motivo, non può essere utilizzato come chiave nell'oggetto mappa

Il motivo più importante per cui una stringa viene resa immutabile in Java è la considerazione della sicurezza . Il prossimo sarebbe il caching .

Credo che altri motivi qui indicati, come l'efficienza, la concorrenza, il design e il pool di stringhe derivino dal fatto che String è diventato immutabile. Per es. String Pool potrebbe essere creato perché String era immutabile e non viceversa.

Controlla qui la trascrizione dell'intervista a Gosling

Da un punto di vista strategico, tendono ad essere più spesso senza problemi. E di solito ci sono cose che puoi fare con immutabili che non puoi fare con cose mutabili, come cache il risultato. Se si passa una stringa a un metodo di apertura file o se si passa una stringa a un costruttore per un'etichetta in un'interfaccia utente, in alcune API (come in molte API di Windows) si passa in una matrice di caratteri. Il destinatario di quell'oggetto deve davvero copiarlo, perché non sa nulla della sua durata di archiviazione. E non sanno cosa sta succedendo all'oggetto, se sta cambiando sotto i loro piedi.

Finisci per essere quasi costretto a replicare l'oggetto perché non sai se puoi possederlo o meno. E una delle cose belle degli oggetti immutabili è che la risposta è "Sì, certo che lo fai." Perché la questione della proprietà, che ha il diritto di cambiarla, non esiste.

Una delle cose che ha costretto le stringhe a essere immutabili è stata la sicurezza. Hai un metodo di apertura file. Gli passi una stringa. E poi sta facendo tutti i tipi di controlli di autenticazione prima di iniziare a fare la chiamata del sistema operativo. Se riesci a fare qualcosa che ha effettivamente mutato la stringa, dopo il controllo di sicurezza e prima della chiamata del sistema operativo, poi boom, sei dentro. Ma le stringhe sono immutabili, quindi quel tipo di attacco non funziona. Questo esempio preciso è ciò che ha veramente richiesto che le stringhe fossero immutabili

Oltre alle ottime risposte, volevo aggiungere alcuni punti. Come le stringhe, l'array contiene un riferimento all'avvio dell'array, quindi se si creano due array arr1e se si arr2fa qualcosa del genere arr2 = arr1si farà il riferimento allo arr2stesso, arr1quindi la modifica del valore in uno di essi comporterà il cambio dell'altro, ad esempio

public class Main {
    public static void main(String[] args) {
        int[] a = {1, 2, 3, 4};
        int[] b = a;
        a[0] = 8;
        b[1] = 7;
        System.out.println("A: " + a[0] + ", B: " + b[0]);
        System.out.println("A: " + a[1] + ", B: " + b[1]);
        //outputs
        //A: 8, B: 8
        //A: 7, B: 7
    }
}

Non solo causerebbe bug nel codice ma può (e sarà) essere sfruttato da utenti malintenzionati. Supponiamo che tu abbia un sistema che modifica la password dell'amministratore. L'utente deve prima inserire il newPassworde poi il oldPasswordse oldPasswordè uguale adminPassal programma cambiare la password di adminPass = newPassword. diciamo che la nuova password ha lo stesso riferimento della password dell'amministratore, quindi un programmatore errato può creare una tempvariabile per conservare la password dell'amministratore prima che l'utente inserisca i dati se oldPasswordè uguale tempcambia la password altrimentiadminPass = temp. Qualcuno sa che potrebbe facilmente inserire la nuova password e non inserire mai la vecchia password e abracadabra che ha accesso come amministratore. Un'altra cosa che non ho capito quando ho appreso sulle stringhe perché JVM non crea una nuova stringa per ogni oggetto e ha un posto unico in memoria per esso e puoi semplicemente farlo usando new String("str");Il motivo che non vorresti usare sempre newè perché non è efficiente in termini di memoria ed è più lento nella maggior parte dei casi leggi di più .

Se HELLOè la vostra String allora non si può cambiare HELLOa HILLO. Questa proprietà si chiama proprietà di immutabilità.

Puoi avere più variabili String puntatore per puntare HELLO String.

Ma se HELLO è Char array, allora puoi cambiare HELLO in HILLO. Per esempio,

char[] charArr = 'HELLO';
char[1] = 'I'; //you can do this

Risposta:

I linguaggi di programmazione hanno variabili di dati immutabili in modo che possano essere utilizzati come chiavi nella chiave, coppia di valori. Le variabili stringa sono usate come chiavi / indici, quindi sono immutabili .

Dal Securitypunto di vista possiamo usare questo esempio pratico:

DBCursor makeConnection(String IP,String PORT,String USER,String PASS,String TABLE) {

    // if strings were mutable IP,PORT,USER,PASS can be changed by validate function
    Boolean validated = validate(IP,PORT,USER,PASS);

    // here we are not sure if IP, PORT, USER, PASS changed or not ??
    if (validated) {
         DBConnection conn = doConnection(IP,PORT,USER,PASS);
    }

    // rest of the code goes here ....
}