Hvorfor er streng uforanderlig i Java?

1. Introduktion

I Java er strenge uforanderlige. Et åbenlyst spørgsmål, der er ret udbredt i interviews, er "Hvorfor strenge er designet som uforanderlige i Java?"

James Gosling, skaberen af ​​Java, blev engang spurgt i et interview, hvornår skal man bruge uforanderlige, som han svarer på:

Jeg ville bruge en uforanderlig, når jeg kan.

Han støtter yderligere sit argument om funktioner, som uforanderlighed giver, såsom caching, sikkerhed, let genbrug uden replikering osv.

I denne vejledning undersøger vi yderligere, hvorfor Java-sprogdesignerne besluttede at beholde Snor uforanderlig.

2. Hvad er et uforanderligt objekt?

Et uforanderligt objekt er et objekt, hvis indre tilstand forbliver konstant, efter at den er oprettet fuldstændigt. Dette betyder, at når objektet først er tildelt en variabel, kan vi hverken opdatere referencen eller mutere den interne tilstand på nogen måde.

Vi har en separat artikel, der diskuterer uforanderlige objekter i detaljer. For mere information, læs artiklen Immutable Objects in Java.

3. Hvorfor er det? Snor Uforanderlig i Java?

De vigtigste fordele ved at holde denne klasse som uforanderlig er cache, sikkerhed, synkronisering og ydeevne.

Lad os diskutere, hvordan disse ting fungerer.

3.1. Introducer til Snor Pool

Det Snor er den mest anvendte datastruktur. Caching af Snor bogstaver og genbrug af dem sparer en masse bunkeplads, fordi de er forskellige Snor variabler henviser til det samme objekt i Snor pool. Snor intern pool tjener netop dette formål.

Java String Pool er det specielle hukommelsesområde hvor Strenge gemmes af JVM. Siden Strenge er uforanderlige i Java, optimerer JVM den mængde hukommelse, der er allokeret til dem ved kun at gemme en kopi af hver bogstavelig Snor i poolen. Denne proces kaldes interning:

String s1 = "Hej verden"; String s2 = "Hej verden"; assertThat (s1 == s2) .isTrue ();

På grund af tilstedeværelsen af Snor i det foregående eksempel peger to forskellige variabler på det samme Snor objekt fra puljen, hvilket sparer vigtig hukommelsesressource.

Vi har en separat artikel dedikeret til Java Snor Pool. For mere information, gå videre til denne artikel.

3.2. Sikkerhed

Det Snor bruges i vid udstrækning i Java-applikationer til at gemme følsomme stykker information som brugernavne, adgangskoder, forbindelses-URL'er, netværksforbindelser osv. Det bruges også i vid udstrækning af JVM-klasselæssere, mens de indlæser klasser.

Derfor sikring Snor klasse er afgørende for sikkerheden i hele applikationen generelt. Overvej for eksempel dette enkle kodestykke:

ugyldig criticalMethod (String brugernavn) {// udfør sikkerhedskontrol, hvis (! isAlphaNumeric (brugernavn)) {kast ny SecurityException (); } // gør nogle sekundære opgaver initialisering af Database (); // kritisk opgaveforbindelse.executeUpdate ("OPDATER KUNDER INDSTILLING Status = 'Aktiv'" + "HVOR Brugernavn = '" + brugernavn + "'"); }

Lad os sige i ovenstående kodestykke, at vi modtog en Snor objekt fra en upålidelig kilde. Vi foretager alle nødvendige sikkerhedskontroller i første omgang for at kontrollere, om Snor er kun alfanumerisk efterfulgt af nogle flere operationer.

Husk, at vores upålidelige kildeopkaldsmetode stadig har henvisning til dette brugernavn objekt.

Hvis Strenge var ændrede, så når vi udfører opdateringen, kan vi ikke være sikre på, at Snor vi modtog, selv efter at have udført sikkerhedskontrol, ville være sikkert. Den upålidelige opkaldsmetode har stadig referencen og kan ændre Snor mellem integritetskontrol. Således gør vores forespørgsel tilbøjelig til SQL-injektioner i dette tilfælde. Så mutabel Strenge kan føre til forringelse af sikkerheden over tid.

Det kunne også ske, at Snorbrugernavn er synlig for en anden tråd, som derefter kan ændre dens værdi efter integritetskontrollen.

Generelt kommer uforanderlighed til vores redning i dette tilfælde, fordi det er lettere at betjene med følsom kode, når værdier ikke ændres, fordi der er færre sammenflettninger af operationer, der kan påvirke resultatet.

3.3. Synkronisering

At være uforanderlig gør automatisk Snor trådsikker, da de ikke ændres, når der er adgang til dem fra flere tråde.

Derfor uforanderlige objekter kan generelt deles på tværs af flere tråde, der kører samtidigt. De er også trådsikre fordi hvis en tråd ændrer værdien, så i stedet for at ændre den samme, en ny Snor ville blive skabt i Snor pool. Derfor, Strenge er sikre til multitrådning.

3.4. Hashcode-cache

Siden Snor objekter bruges i vid udstrækning som datastruktur, de bruges også i vid udstrækning i hash-implementeringer som f.eks HashMap, HashTable, HashSetosv. Når du arbejder på disse hash-implementeringer, hashCode () metoden kaldes ret ofte til skovlindlæg.

Uforanderligheden garanterer Strenge at deres værdi ikke ændres. Så det hashCode () metoden er tilsidesat Snor klasse for at lette caching, således at hashen beregnes og cachelagres i løbet af den første hashCode () opkald, og den samme værdi returneres lige siden.

Dette forbedrer igen præstationen for samlinger, der bruger hash-implementeringer, når de betjenes med Snor genstande.

På den anden side kan det ændres Strenge producerer to forskellige hashkoder på tidspunktet for indsættelse og hentning, hvis indholdet af Snor blev ændret efter operationen, hvilket potentielt mistede værdiobjektet i Kort.

3.5. Ydeevne

Som vi så tidligere, Snor pool eksisterer fordi Strenge er uforanderlige. Til gengæld forbedrer det ydeevnen ved at gemme bunkehukommelse og hurtigere adgang til hash-implementeringer, når den betjenes med Strenge.

Siden Snor er den mest anvendte datastruktur, hvilket forbedrer ydeevnen for Snor har en betydelig indvirkning på at forbedre ydeevnen for hele applikationen generelt.

4. Konklusion

Gennem denne artikel kan vi konkludere det Strenge er uforanderlige nøjagtigt, så deres referencer kan behandles som en normal variabel, og man kan sende dem rundt, mellem metoder og på tværs af tråde uden at bekymre sig om, hvorvidt den aktuelle Snor objekt det peger på vil ændre sig.

Vi lærte også, hvad der kunne være de andre grunde, der fik til Java sprogdesignere at gøre denne klasse som uforanderlig.


$config[zx-auto] not found$config[zx-overlay] not found