I objektorientert programmering er uforanderlig streng eller objekter som ikke kan endres når den først er opprettet. Men vi kan bare endre referansen til objektet. Vi begrenser til å endre selve objektet. De String er uforanderlig i Java på grunn av sikkerhet, synkronisering og samtidighet, hurtigbufring og klasselasting. Grunnen til å gjøre strengen endelig er å ødelegge uforanderligheten og ikke la andre utvide den.
String-objektene er bufret i String-poolen, og det gjør Strenge uforanderlig . De bufrede strengliteralene får tilgang til av flere klienter. Så det er alltid en risiko, der handlinger som utføres av én klient påvirker alle andre klienter. For eksempel, hvis en klient utfører en handling og endrer strengverdien fra Pressure til PRESSURE, vil alle gjenværende klienter også lese denne verdien. Av ytelsesgrunnen var bufring av String-objekter viktig, så for å fjerne denne risikoen, må vi gjøre String Immutable.
java arrayliste
Dette er noen flere grunner til å gjøre String uforanderlig:
- String-poolen kan ikke være mulig hvis String ikke er uforanderlig i Java. Mye haugplass spares av JRE . Den samme strengvariabelen kan refereres til av mer enn én strengvariabel i bassenget. Stringinternering kan heller ikke være mulig hvis strengen ikke er uforanderlig.
- Hvis vi ikke gjør strengen uforanderlig, vil den utgjøre en alvorlig sikkerhetstrussel for applikasjonen. For eksempel sendes databasebrukernavn og passord som strenger for å motta databasetilkoblinger. De socket programmering verts- og portbeskrivelser sendes også som strenger. Strengen er uforanderlig, så verdien kan ikke endres. Hvis strengen ikke forblir uforanderlig, kan enhver hacker forårsake et sikkerhetsproblem i applikasjonen ved å endre referanseverdien.
- Strengen er trygg for flertråding på grunn av dens uforanderlighet. Ulike tråder kan få tilgang til en enkelt 'String-forekomst'. Det fjerner synkroniseringen for trådsikkerhet fordi vi gjør strenger trådsikre implisitt.
- Uforanderlighet gir sikkerheten til å laste inn riktig klasse av Classloader. Anta for eksempel at vi har en forekomst der vi prøver å laste java.sql.Connection-klassen, men endringene i den refererte verdien til myhacked.Connection-klassen gjør uønskede ting til databasen vår.
La oss forstå konseptet uforanderlig gjennom et eksempel.
ImmutableString.java
git pull origin master
import java.util.*; class ImmutableString{ public static void main(String args[]){ String NewString = 'Hello'; NewString.concat('World'); System.out.println(NewString); } } Produksjon:
Beskrivelse: Vi kan forstå eksemplet ovenfor ved hjelp av følgende diagram:
filtrerende python
I strengkonstantbassenget Hallo forblir uendret, og et nytt strengobjekt opprettes med Hei Verden . Det viser at strengene er uforanderlige. Referansevariabelen peker på Hallo ikke til Hei Verden.
Hvis vi ønsker det, refererer det til Hei Verden , må vi eksplisitt tilordne den til den variabelen. For eksempel:
import java.util.*; class ImmutableString{ public static void main(String args[]){ String NewString = 'Hello'; NewString = NewString.concat('World'); System.out.println(NewString); } } Produksjon:
