Bij objectgeoriënteerd programmeren wordt de onveranderlijke tekenreeks of objecten die niet meer kan worden gewijzigd zodra deze is gemaakt. Maar we kunnen alleen de verwijzing naar het object wijzigen. We beperken ons tot het wijzigen van het object zelf. De Tekenreeks is onveranderlijk in Java vanwege de beveiliging, synchronisatie en gelijktijdigheid, caching en het laden van klassen. De reden om de string definitief te maken is om de onveranderlijkheid te vernietigen en niet toe te staan ​​dat anderen deze uitbreiden.

De String-objecten worden in de cache opgeslagen in de String-pool en maken de Tekenreeks onveranderlijk . De in de cache opgeslagen tekenreeksliterals zijn toegankelijk voor meerdere clients. Er bestaat dus altijd een risico als de actie van één cliënt gevolgen heeft voor alle andere cliënten. Als één client bijvoorbeeld een actie uitvoert en de tekenreekswaarde wijzigt van Pressure in PRESSURE, zullen alle overige clients die waarde ook lezen. Om prestatieredenen was het cachen van String-objecten belangrijk, dus om dat risico weg te nemen, moeten we de String onveranderlijk maken.

Dit zijn nog enkele redenen om String onveranderlijk te maken:

• De String-pool kan niet mogelijk zijn als String niet onveranderlijk is in Java. Er wordt veel heapruimte bespaard door JRE . Er kan naar dezelfde stringvariabele worden verwezen door meer dan één stringvariabele in de pool. String-intering kan ook niet mogelijk zijn als de String niet onveranderlijk zou zijn.
• Als we de String niet onveranderlijk maken, vormt dit een ernstige bedreiging voor de veiligheid van de toepassing. Databasegebruikersnamen en wachtwoorden worden bijvoorbeeld als tekenreeksen doorgegeven om databaseverbindingen te ontvangen. De socket-programmering host- en poortbeschrijvingen worden ook als tekenreeksen doorgegeven. De String is onveranderlijk, dus de waarde ervan kan niet worden gewijzigd. Als de String niet onveranderlijk blijft, kan elke hacker een beveiligingsprobleem in de applicatie veroorzaken door de referentiewaarde te wijzigen.
• De String is veilig voor multithreading vanwege zijn onveranderlijkheid. Verschillende threads hebben toegang tot één enkele 'String-instantie'. Het verwijdert de synchronisatie voor draadveiligheid omdat we strings impliciet draadveilig maken.
• Onveranderlijkheid geeft de zekerheid dat de juiste klasse door Classloader wordt geladen. Stel dat we bijvoorbeeld een instantie hebben waarin we de klasse java.sql.Connection proberen te laden, maar de wijzigingen in de waarde waarnaar wordt verwezen in de klasse myhacked.Connection ongewenste dingen doen met onze database.

Laten we het concept van onveranderlijk begrijpen aan de hand van een voorbeeld.

OnveranderlijkeString.java

 import java.util.*; class ImmutableString{ public static void main(String args[]){ String NewString = 'Hello'; NewString.concat('World'); System.out.println(NewString); } } 

Uitgang:

Beschrijving: We kunnen het bovenstaande voorbeeld begrijpen met behulp van het volgende diagram:

In de reeksconstantepool wordt de Hallo blijft ongewijzigd en er wordt een nieuw stringobject mee gemaakt Hallo Wereld . Het laat zien dat de snaren onveranderlijk zijn. De referentievariabele verwijst naar de Hallo niet naar de Hallo Wereld.

Als we dat willen, verwijst het naar de Hallo Wereld , moeten we het expliciet aan die variabele toewijzen. Bijvoorbeeld:

 import java.util.*; class ImmutableString{ public static void main(String args[]){ String NewString = 'Hello'; NewString = NewString.concat('World'); System.out.println(NewString); } } 

Uitgang: