2012-01-09 16 views
9

Java ha un pool di stringhe, a causa del quale oggetti di classe stringa sono immutabili.String POOL in java

Ma la mia domanda sorge -

Qual è stata la necessità di rendere String POOL?

Perché la classe di stringa non è stata mantenuta come un'altra classe per contenere i propri valori?

È internamente che JVM ha bisogno di alcune stringhe o rappresenta un vantaggio in termini di prestazioni. Se sì come?

+0

Pensa a cosa farai se vuoi creare un corso immutabile da solo. – Azodious

+0

Beh, la mia domanda è: ci sono così tante altre classi immutabili in java, quindi perché i designer Java hanno deciso di creare un pool di stringhe. È una funzione che aiuta le prestazioni o è la necessità di Java Design? –

risposta

6

Un pool è possibile perché le stringhe sono immutabili. Ma l'immutabilità dello String non è stata decisa solo a causa di questo pool. L'immutabilità ha numerosi altri vantaggi. A proposito, un Double è anche immutabile e non esiste un pool di duplicati.

La necessità per il pool di stringhe è di ridurre la memoria necessaria per contenere tutti i letterali String (e le stringhe internamente) utilizzate da un programma, poiché questi letterali hanno una buona possibilità di essere utilizzati più volte, in molti punti del programma. Invece di avere migliaia di copie della stessa stringa letterale, hai solo mille riferimenti alla stessa stringa, che riduce l'utilizzo della memoria.

Si noti che la classe String non è diversa dalle altre classi: contiene il proprio array di caratteri. Può anche condividerlo con altre istanze di String, tuttavia, quando viene chiamata la sottostringa.

+0

** Double è anche immutabile, e non c'è pool di Doubles ** Bella scelta .. :) Grazie – agpt

+0

Cosa intendi per "Stringhe letterali che un programma fa"? Stai dicendo che JVM genera internamente molte stringhe simili anche quando l'applicazione non funziona con il testo e non crea molti oggetti String in modo esplicito? – James

+1

No, quello che sto dicendo è esattamente la cosa inversa: se 200 classi usano il letterale String '" "' nel loro codice, viene creata solo un'istanza, memorizzata nel pool di stringhe e condivisa da tutte le classi. –

0

Quando il compilatore vede che è necessario creare un nuovo valore letterale String, prima controlla il pool per una stringa identica, se non viene trovato alcun nuovo String letterale, viene indirizzata la stringa esistente.

+0

Il compilatore non ha nulla a che fare con questo, in realtà. I letterali vengono inseriti nel file di classe e vengono risolti dal pool quando viene caricata la classe. –

+1

quindi quello che dici è che le stringhe nel pool non vengono indirizzate se viene trovata una corrispondenza? – Harinder

0

la benifit di rendere stringa come immutabile è stato per la funzione di sicurezza. Leggi sotto

Perché String è stato reso immutabile in Java?

Tuttavia, anche le prestazioni sono un motivo (presupponendo che si sia già a conoscenza del pool String interno gestito per assicurarsi che lo stesso oggetto String venga utilizzato più volte senza doverlo creare/ri-reclamare più volte), ma il motivo principale per cui String è stato reso immutabile in Java è "Sicurezza". Sorpreso? Capiamo perché.

Supponiamo che sia necessario aprire un file sicuro che richiede agli utenti di autenticarsi. Diciamo che ci sono due utenti chiamati 'user1' e 'user2' e hanno i propri file password 'password1' e 'password2', rispettivamente. Ovviamente 'utente2' non dovrebbe avere accesso al file 'password1'.

Come sappiamo, i nomi file in Java sono specificati utilizzando Stringhe. Anche se si crea un oggetto 'File', si passa il nome del file solo come una stringa e tale stringa viene mantenuta all'interno dell'oggetto File come uno dei suoi membri.

Aveva String stato mutevole, 'user1' avrebbe potuto effettuato l'accesso con le proprie credenziali e quindi in qualche modo sarebbe riuscito a cambiare il nome del suo nome di file password (un oggetto String) da 'password1' a 'password2' prima JVM effettivamente posti la chiamata di sistema del sistema operativo nativo per aprire il file. Ciò avrebbe permesso a 'utente1' di aprire il file di password di user2. Comprensibilmente ciò avrebbe comportato un grosso difetto di sicurezza in Java. Capisco che ce ne siano così tanti che potrebbero essere qui, ma sicuramente conveniresti che avrebbe aperto una porta per consentire agli sviluppatori di compromettere la sicurezza di molte risorse intenzionalmente o non intenzionalmente.

Con String che è immutabile, JVM può essere sicuro che il membro di istanza del file del file oggetto corrispondente continui a puntare allo stesso oggetto String "filename" invariato. Il membro dell'istanza 'filename' che è un 'final' nella classe File può comunque non essere modificato in modo da puntare a qualsiasi altro oggetto String specificando qualsiasi altro file rispetto a quello previsto (cioè, quello che è stato utilizzato per creare l'oggetto File).

+0

Questo non è davvero un motivo di sicurezza. La classe File avrebbe solo bisogno di copiare la stringa con il nome del file in un nuovo oggetto String se le stringhe fossero mutabili in Java. La sua unica funzione di prestazioni è che questa copia non è necessaria (e una funzione di comodità per i programmatori che non possono dimenticare la copia necessaria). –