Czy łańcuch Java jest naprawdę niezmienny?

Wszyscy wiemy, że Stringjest niezmienny w Javie, ale sprawdź następujący kod:

String s1 = "Hello World";  
String s2 = "Hello World";  
String s3 = s1.substring(6);  
System.out.println(s1); // Hello World  
System.out.println(s2); // Hello World  
System.out.println(s3); // World  

Field field = String.class.getDeclaredField("value");  
field.setAccessible(true);  
char[] value = (char[])field.get(s1);  
value[6] = 'J';  
value[7] = 'a';  
value[8] = 'v';  
value[9] = 'a';  
value[10] = '!';  

System.out.println(s1); // Hello Java!  
System.out.println(s2); // Hello Java!  
System.out.println(s3); // World  

Dlaczego ten program działa w ten sposób? I dlaczego jest wartość s1i s2zmieniane, ale nie s3?

String jest niezmienny *, ale oznacza to tylko, że nie można go zmienić za pomocą jego publicznego interfejsu API.

To, co tu robisz, to obchodzenie normalnego API za pomocą odbicia. W ten sam sposób możesz zmienić wartości wyliczeń, zmienić tabelę odnośników używaną w autoboksowaniu liczb całkowitych itp.

Powodem s1i s2wartością zmiany jest to, że oba odnoszą się do tego samego łańcucha wewnętrznego. Kompilator to robi (jak wspomniano w innych odpowiedziach).

Powodem s3jest nie był faktycznie nieco zaskakujące dla mnie, jak myślałem, że dzielić valuearray ( miało to miejsce w poprzedniej wersji Java , zanim 7u6 Java). Jednak patrząc na kod źródłowy String, widzimy, że valuetablica znaków dla podłańcucha jest faktycznie kopiowana (za pomocą Arrays.copyOfRange(..)). Dlatego pozostaje niezmieniony.

Możesz zainstalować SecurityManager, aby uniknąć złośliwego kodu, aby robić takie rzeczy. Pamiętaj jednak, że niektóre biblioteki zależą od korzystania z tego rodzaju sztuczek refleksyjnych (zazwyczaj narzędzia ORM, biblioteki AOP itp.).

*) Początkowo napisałem, że Stringtak naprawdę nie są niezmienne, tylko „skuteczne niezmienne”. Może to wprowadzać w błąd w obecnej implementacji String, gdzie valuetablica jest rzeczywiście oznaczona private final. Warto jednak zauważyć, że nie ma sposobu, aby zadeklarować tablicę w Javie jako niezmienną, dlatego należy zachować ostrożność, aby nie ujawniać jej poza klasą, nawet przy odpowiednich modyfikatorach dostępu.

Ponieważ ten temat wydaje się niezwykle popularny, oto kilka sugerowanych lektur: Dyskusja Heinza Kabutza Reflection Madness z JavaZone 2009, która obejmuje wiele problemów w OP, wraz z innymi refleksjami ... cóż ... szaleństwem.

Obejmuje to, dlaczego czasami jest to przydatne. I dlaczego w większości przypadków należy tego unikać. :-)

W Javie, jeśli dwie pierwotne zmienne łańcuchowe są inicjowane na ten sam literał, przypisuje to samo odwołanie do obu zmiennych:

String Test1="Hello World";
String Test2="Hello World";
System.out.println(test1==test2); // true

Z tego powodu porównanie zwraca wartość true. Trzeci ciąg jest tworzony za pomocą, substring()który tworzy nowy ciąg zamiast wskazywać na to samo.

Gdy uzyskujesz dostęp do ciągu za pomocą odbicia, otrzymujesz rzeczywisty wskaźnik:

Field field = String.class.getDeclaredField("value");
field.setAccessible(true);

Tak więc zmiana na to spowoduje zmianę łańcucha przytrzymującego do niego wskaźnik, ale tak jak s3został utworzony z nowym ciągiem, ponieważ substring()nie zmieni się.

Używasz refleksji, aby obejść niezmienność Sznurka - jest to forma „ataku”.

Istnieje wiele przykładów, które możesz stworzyć w ten sposób (np. Możesz nawet utworzyć instancję Voidobiektu ), ale to nie znaczy, że String nie jest „niezmienny”.

Istnieją przypadki użycia, w których ten rodzaj kodu może być wykorzystany na Twoją korzyść i być „dobrym kodowaniem”, na przykład usuwanie haseł z pamięci w najwcześniejszym możliwym momencie (przed GC) .

W zależności od menedżera bezpieczeństwa wykonanie kodu może nie być możliwe.

Używasz refleksji, aby uzyskać dostęp do „szczegółów implementacji” obiektu string. Niezmienność jest cechą publicznego interfejsu obiektu.

Modyfikatory widoczności i końcowa (tj. Niezmienność) nie są miarą złośliwego kodu w Javie; są jedynie narzędziami służącymi do ochrony przed błędami i ułatwienia zarządzania kodem (jedna z głównych zalet systemu). Dlatego możesz uzyskać dostęp do wewnętrznych szczegółów implementacji, takich jak tablica charcentów dla Strings poprzez odbicie.

Drugim efektem, który widzisz, jest to, że wszystko się Stringzmienia, podczas gdy wygląda na to, że się zmieniasz s1. Jest to pewna właściwość literałów Java String, które są automatycznie internowane, tj. Buforowane. Dwa literały łańcuchowe o tej samej wartości będą faktycznie tym samym obiektem. Gdy utworzysz z newnim Łańcuch, nie zostanie on automatycznie internowany i nie zobaczysz tego efektu.

#substringdo niedawna (Java 7u6) działał w podobny sposób, co wyjaśniałoby zachowanie w oryginalnej wersji twojego pytania. Nie stworzył on nowej tablicy char, ale użył ponownie tej z oryginalnego String; właśnie utworzył nowy obiekt String, który wykorzystał przesunięcie i długość, aby przedstawić tylko część tej tablicy. Ogólnie działało to, ponieważ ciągi są niezmienne - chyba że je obejdziesz. Ta właściwość #substringoznaczała również, że cały oryginalny Ciąg nie mógł zostać wyrzucony przez śmieci, gdy jeszcze utworzono z niego krótszy podciąg.

W obecnej Javie i twojej obecnej wersji pytania nie ma dziwnego zachowania #substring.

Niezmienność łańcucha jest z perspektywy interfejsu. Używasz refleksji, aby ominąć interfejs i bezpośrednio zmodyfikować elementy wewnętrzne instancji String.

s1i s2oba zostały zmienione, ponieważ oba są przypisane do tej samej instancji ciągu „intern”. Więcej informacji na temat tej części można znaleźć w tym artykule na temat równości łańcuchów i internowania. Możesz być zaskoczony, gdy dowiesz się, że w przykładowym kodzie s1 == s2powraca true!

Jakiej wersji Java używasz? Z Java 1.7.0_06 Oracle zmieniło wewnętrzną reprezentację String, szczególnie podłańcuch.

Cytowanie z wewnętrznej reprezentacji ciągów Java Oracle Tunes :

W nowym paradygmacie pola Przesunięcie i policzenie łańcucha zostały usunięte, więc podciągi nie mają już wspólnej wartości char [].

Przy tej zmianie może się zdarzyć bez refleksji (???).

Są tutaj naprawdę dwa pytania:

1. Czy łańcuchy naprawdę są niezmienne?
2. Dlaczego s3 się nie zmienia?

Do punktu 1: Z wyjątkiem ROM, nie ma niezmiennej pamięci w twoim komputerze. W dzisiejszych czasach nawet ROM jest czasami zapisywalny. Zawsze gdzieś jest jakiś kod (czy to jądro, czy kod natywny omijający środowisko zarządzane), który może zapisać na adres pamięci. Tak więc w „rzeczywistości” nie, nie są one absolutnie niezmienne.

Do punktu 2: Jest tak, ponieważ podciąg prawdopodobnie przydziela nową instancję ciągu, która prawdopodobnie kopiuje tablicę. Możliwe jest zaimplementowanie podciągów w taki sposób, że nie zrobi ono kopii, ale to nie znaczy, że tak. W grę wchodzą kompromisy.

Na przykład, czy posiadanie odwołania powinno reallyLargeString.substring(reallyLargeString.length - 2)powodować utrzymywanie dużej ilości pamięci przy życiu, czy tylko kilka bajtów?

To zależy od sposobu implementowania podciągów. Głęboka kopia utrzyma mniej pamięci przy życiu, ale będzie działać nieco wolniej. Płytka kopia zachowa więcej pamięci, ale będzie szybsza. Korzystanie z głębokiej kopii może również zmniejszyć fragmentację sterty, ponieważ obiekt łańcucha i jego bufor można przydzielić w jednym bloku, w przeciwieństwie do 2 oddzielnych przydziałów sterty.

W każdym razie wygląda na to, że JVM wybrał głębokie kopie do wywołań podłańcuchów.

Aby dodać do odpowiedzi @ haraldK - jest to hack bezpieczeństwa, który może prowadzić do poważnego wpływu na aplikację.

Pierwszą rzeczą jest modyfikacja stałego ciągu przechowywanego w puli ciągów. Kiedy ciąg znaków jest zadeklarowany jako String s = "Hello World";, jest umieszczany w specjalnej puli obiektów w celu dalszego potencjalnego ponownego wykorzystania. Problem polega na tym, że kompilator umieści odniesienie do zmodyfikowanej wersji w czasie kompilacji, a gdy użytkownik zmodyfikuje ciąg przechowywany w tej puli w czasie wykonywania, wszystkie odniesienia w kodzie będą wskazywać na zmodyfikowaną wersję. Spowodowałoby to następujący błąd:

System.out.println("Hello World"); 

Wydrukuje:

Hello Java!

Był jeszcze jeden problem, który napotkałem, gdy wdrażałem ciężkie obliczenia w odniesieniu do tak ryzykownych ciągów. Wystąpił błąd, który wystąpił mniej więcej 1 na 1000000 razy podczas obliczeń, co spowodowało, że wynik był nieokreślony. Znalazłem problem, wyłączając JIT - zawsze otrzymywałem ten sam rezultat przy wyłączonym JIT. Domyślam się, że powodem był włamanie do systemu String, które złamało niektóre kontrakty optymalizacyjne JIT.

Zgodnie z koncepcją pulowania wszystkie zmienne String zawierające tę samą wartość będą wskazywały na ten sam adres pamięci. Dlatego s1 i s2, oba zawierające tę samą wartość „Hello World”, będą wskazywały na tę samą lokalizację pamięci (powiedzmy M1).

Z drugiej strony s3 zawiera „Świat”, stąd będzie wskazywał na inny przydział pamięci (powiedzmy M2).

Teraz dzieje się tak, że wartość S1 jest zmieniana (przy użyciu wartości char []). Tak więc wartość w miejscu pamięci M1 wskazanym zarówno przez s1, jak i s2 została zmieniona.

W rezultacie zmieniono lokalizację pamięci M1, co powoduje zmianę wartości s1 i s2.

Ale wartość położenia M2 pozostaje niezmieniona, dlatego s3 zawiera tę samą pierwotną wartość.

Powodem, dla którego s3 tak naprawdę się nie zmienia, jest to, że w Javie podczas wykonywania podłańcucha tablica znaków wartości podłańcucha jest wewnętrznie kopiowana (przy użyciu Arrays.copyOfRange ()).

s1 i s2 są takie same, ponieważ w Javie oba odnoszą się do tego samego łańcucha wewnętrznego. Jest to zaprojektowane w Javie.

String jest niezmienny, ale poprzez odbicie możesz zmienić klasę String. Właśnie zdefiniowałeś klasę String jako zmienną w czasie rzeczywistym. Jeśli chcesz, możesz przedefiniować metody, aby były publiczne, prywatne lub statyczne.

[Uwaga: jest to celowo wyrażony styl odpowiedzi, ponieważ uważam, że odpowiedź „nie rób tego w domu” jest uzasadniona]

Grzech jest linią, field.setAccessible(true);która mówi, że narusza publiczny interfejs API, umożliwiając dostęp do prywatnego pola. To gigantyczna dziura w zabezpieczeniach, którą można zamknąć, konfigurując menedżera bezpieczeństwa.

Zjawiskiem w pytaniu są szczegóły implementacji, których nigdy nie zobaczysz, gdy nie użyjesz tego niebezpiecznego wiersza kodu do naruszenia modyfikatorów dostępu poprzez odbicie. Oczywiście dwa (normalnie) niezmienne ciągi mogą dzielić tę samą tablicę znaków. To, czy podciąg dzieli tę samą tablicę, zależy od tego, czy może i czy deweloper pomyślał o udostępnieniu go. Zwykle są to niewidoczne szczegóły implementacji, których nie powinieneś znać, chyba że strzelisz do modyfikatora dostępu za pomocą tego wiersza kodu.

Po prostu nie jest dobrym pomysłem poleganie na takich szczegółach, których nie można doświadczyć bez naruszenia modyfikatorów dostępu za pomocą odbicia. Właściciel tej klasy obsługuje tylko normalny publiczny interfejs API i może wprowadzać zmiany implementacyjne w przyszłości.

Powiedziawszy wszystko, że linia kodu jest naprawdę bardzo przydatna, gdy masz pistolet, który trzyma cię za głowę, zmuszając cię do robienia tak niebezpiecznych rzeczy. Korzystanie z tych tylnych drzwi jest zwykle zapachem kodu, który należy uaktualnić do lepszego kodu biblioteki, w którym nie trzeba grzeszyć. Innym powszechnym zastosowaniem tego niebezpiecznego wiersza kodu jest napisanie „frameworka voodoo” (orm, kontener wstrzykiwania, ...). Wielu ludzi wierzy w takie ramy (zarówno za, jak i przeciw nim), więc uniknę zaproszenia do wojny z płomieniami, mówiąc, że znaczna większość programistów nie musi tam iść.

Ciągi są tworzone w stałym obszarze pamięci sterty JVM. Tak, to jest naprawdę niezmienne i nie można go zmienić po utworzeniu. Ponieważ w JVM istnieją trzy typy pamięci sterty: 1. Młoda generacja 2. Stara generacja 3. Generacja stała.

Po utworzeniu dowolnego obiektu przechodzi on w obszar sterty młodego pokolenia i obszar PermGen zarezerwowany dla puli ciągów.

Oto więcej szczegółów, z których możesz przejść i pobrać więcej informacji: Jak działa Garbage Collection w Javie .

Ciąg jest niezmienny z natury, ponieważ nie ma metody modyfikowania obiektu String. Dlatego wprowadzili klasy StringBuilder i StringBuffer