Java Interview Questions

Головна / Усі відповіді / String

Питання 21 · Розділ 12

Чи можна змінити вміст String через рефлексію?

String задуманий як незмінний (immutable) клас. Це означає, що після створення рядок не можна поміняти. Але Java Reflection дозволяє «зазирнути всередину» будь-якого об'єкта і з...

Ukrainian String Вихідний Markdown
Мовні версії: English Russian Ukrainian

🟢 Junior Level

Технічно — так, але це вкрай погана ідея.

String задуманий як незмінний (immutable) клас. Це означає, що після створення рядок не можна поміняти. Але Java Reflection дозволяє «зазирнути всередину» будь-якого об’єкта і змінити навіть private та final поля.

Приклад (не робіть так!):

String s = "Hello";
Field valueField = String.class.getDeclaredField("value");
valueField.setAccessible(true);

// Java 9+: value — це byte[]
byte[] value = (byte[]) valueField.get(s);
value[0] = (byte) 'J'; // Міняємо байти напряму

System.out.println(s); // "Jello" — рядок змінився!

Проста аналогія: String — як запечатана пляшка води. Виробник очікує, що ви не будете її розкривати. Але якщо ви відкриєте кришку (reflection) і підфарбуєте воду — пляшка все ще виглядає як «вода», але вміст уже інший.

Чому це небезпечно:

  1. Всі посилання на цей рядок теж зміняться — інші частини програми побачать “Jello” замість “Hello”
  2. String Pool зламається — літерал "Hello" в коді тепер може означати “Jello”
  3. Безпека під загрозою — хеші паролів, ключі, токени можуть бути змінені

Висновок: Ніколи не змінюйте String через рефлексію в реальному коді.

🟡 Middle Level

Як це працює

До Java 9:

// String зберігав char[] value
Field valueField = String.class.getDeclaredField("value");
valueField.setAccessible(true);
char[] value = (char[]) valueField.get(s);
value[0] = 'J';

Java 9+ (Compact Strings):

// String зберігає byte[] value + byte coder
Field valueField = String.class.getDeclaredField("value");
valueField.setAccessible(true);
byte[] value = (byte[]) valueField.get(s);
value[0] = (byte) 'J';

Поле coder визначає, як інтерпретувати байти. Якщо рядок був Latin-1 (coder=0), а ви запишете байт за межами Latin-1 діапазону — рядок залишиться Latin-1, але дані будуть некоректними.

Практичні наслідки

String key = "password";
String cached = key; // Інше посилання на той самий рядок

// Змінюємо через рефлексію
Field f = String.class.getDeclaredField("value");
f.setAccessible(true);
byte[] v = (byte[]) f.get(key);
v[0] = (byte) 'P';

System.out.println(key);    // "Password"
System.out.println(cached); // "Password" — теж змінилася!

Таблиця типових помилок

Помилка Наслідки Рішення
Зміна String в String Pool Всі посилання на літерал бачать змінене значення Не міняти літерали; працювати тільки з new String(...)
Зміна hash-поля hashCode() повертає старе значення, HashMap.get() не знайде ключ Не чіпати hash поле; якщо змінили value — скинути hash
Зміна в багатопоточному середовищі Data race, невизначена поведінка String immutable — це контракт для всіх потоків
Java 9+ module system setAccessible(true) кидає InaccessibleObjectException --add-opens java.base/java.lang=ALL-UNNAMED

Порівняння підходів

Метод Працює? Небезпека Java 8 Java 9+
Зміна value[] Так Критична ✅ ✅ (byte[])
Зміна coder Так Критична N/A ✅
Зміна hash Так Висока ✅ ✅
Створення mutable String Ні N/A ❌ ❌

Коли НЕ використовувати рефлексію на String

  • Production-код — ніколи
  • Бібліотеки — ніколи (зламаєте чужий код)
  • Багатопоточні системи — data race гарантовано
  • Security-sensitive код — обхід перевірок, injection
  • Єдиний сценарій: unit-тести, фреймворки мокінгу, deep serialization

🔴 Senior Level

Internal Implementation — Reflection і AccessibleObject

Механізм Reflection в JVM:

// Field.setAccessible(true) internally:
// 1. Перевіряє module access (Java 9+)
// 2. Встановлює флаг override в AccessibleObject
// 3. Вимикає перевірки доступу при get/put через JNI

Java 9+ Module System (JEP 261): З появою модульної системи доступ до internal полів обмежений:

// Без JVM-флага — кидає InaccessibleObjectException
Field f = String.class.getDeclaredField("value");
f.setAccessible(true); // ❌ InaccessibleObjectException

// Потрібен JVM-флаг:
// --add-opens java.base/java.lang=ALL-UNNAMED

Поля String (Java 9+):

public final class String {
    @Stable
    private final byte[] value;  // immutable після конструювання
    private final byte coder;    // 0 = LATIN1, 1 = UTF16
    private int hash;            // lazy: 0 = not computed yet
    // serialPersistentFields, caseInsensitiveComparator, ...
}

@Stable — JVM-аннотація (з jdk.internal.vm.annotation), яка повідомляє JIT-компілятору: поле встановлюється один раз в конструкторі і більше не змінюється. Це дозволяє:

  • Constant folding: JIT підставляє значення прямо в машинний код
  • Register caching: значення кешується в CPU-регістрі
  • Escape analysis: оптимізації на основі незмінності

Зміна @Stable поля ламає JIT-оптимізації: скомпільований код може використовувати старе (закешоване) значення.

Edge Cases (мінімум 3)

1. String Pool contamination:

String s1 = "Hello"; // Literal → String Pool
String s2 = "Hello"; // Те ж посилання з пулу

Field f = String.class.getDeclaredField("value");
f.setAccessible(true);
byte[] v = (byte[]) f.get(s1);
v[0] = (byte) 'J';

System.out.println(s2); // "Jello" — літерал в коді тепер означає "Jello"!
// Будь-який новий код String s = "Hello" може отримати змінений об'єкт
// JVM behavior визначений — літерал у пулі змінений. Але JIT-compiled код, який
// constant-folded оригінальне значення, може бачити неконсистентні результати.

2. HashMap key corruption:

String key = "key";
Map<String, String> map = new HashMap<>();
map.put(key, "value");

// Змінюємо key через рефлексію
Field f = String.class.getDeclaredField("value");
f.setAccessible(true);
byte[] v = (byte[]) f.get(key);
v[0] = (byte) 'K'; // "Key"

// hash-поле все ще містить хеш від "key"
map.get("Key");  // null — hash не збігається
map.get("key");  // null — такого рядка більше немає (value змінено)
// HashMap зламаний!

3. Coder mismatch — запис UTF-16 байта в Latin-1 рядок:

String s = "Hello"; // coder = LATIN1
Field vf = String.class.getDeclaredField("value");
Field cf = String.class.getDeclaredField("coder");
vf.setAccessible(true);
cf.setAccessible(true);

byte[] v = (byte[]) vf.get(s);
v[0] = (byte) 0xD0; // Байт кирилиці в Latin-1 рядок!

// s.charAt(0) поверне (char) 0xD0 = 208 (некоректний символ)
// s.getBytes(UTF_8) поверне некоректні байти
// equals() може працювати непередбачувано

4. Concurrent modification — data race:

// Потік A читає рядок
char c = s.charAt(0);

// Потік B одночасно міняє value[] через рефлексію
v[0] = (byte) 'X';

// Потік A: значення c може бути старим або новим — data race
// happens-before порушено: немає синхронізації для final-полів,
// змінених через reflection

5. Security Manager і Reflection (Java 17+): В Java 17+ SecurityManager deprecated, а module access за замовчуванням строгий. Навіть з --add-opens деякі JVM-internal поля можуть бути захищені на рівні native code.

Продуктивність

Операція Час Примітка
setAccessible(true) ~50–200ns Одноразова, але з перевіркою модулів дорожче
Field.get() ~20–50ns JNI call overhead
Field.set() на final поле ~20–50ns Але ламає JIT-оптимізації
String.hashCode() після mutation Невірний hash-поле не перераховується
JIT deoptimization ~1–10μs Якщо JIT скомпілював код з constant-folded String

JIT deoptimization: Якщо JIT вже скомпілював метод, що використовує цей рядок (наприклад, через constant folding "Hello" → inline), то зміна значення викличе deoptimization — JVM викине скомпільований код і переінтерпретує. Це коштує 1–10μs і може відбуватися повторно.

Thread Safety

String не thread-safe після reflection-мутації. Контракт immutable порушено:

  • Немає volatile на value[] — інші потоки можуть не побачити зміни (або побачити частково)
  • Немає memory barriers — happens-before не встановлено
  • @Stable аннотація дозволяє JIT кешувати значення в регістрах — потік може ніколи не побачити зміну

Production War Story

Сценарій: Фреймворк тестування (PowerMock/Mockito) використовував reflection для мокінгу String в unit-тестах.

// Тест міняє рядок-константу
Field f = String.class.getDeclaredField("value");
f.setAccessible(true);
byte[] v = (byte[]) f.get("CONSTANT");
// ... міняє значення

Проблема: тести проходили окремо, але при паралельному запуску (Maven Surefire, forkCount > 1) один тест міняв рядок у String Pool, і інший тест падав з AssertionError. String Pool — спільний для всіх тестів в одній JVM.

Fix: Ізоляція тестів в окремих JVM (forkMode=always) або відмова від мокінгу immutable об’єктів.

Сценарій 2: Бібліотека deep serialization (Kryo) оптимізувала серіалізацію String, змінюючи internal value[] напряму. Після міграції на Java 17 з --add-opens не був налаштований → InaccessibleObjectException у продакшені. Fix: перехід на стандартну серіалізацію.

Monitoring

# Перевірити module access
java --add-opens java.base/java.lang=ALL-UNNAMED -jar app.jar

# JFR — reflection Access events
java -XX:StartFlightRecording=filename=recording.jfr ...
# В JDK Flight Recorder: немає спеціального event для reflection,
# але можна відловити через custom events

# GC logs — якщо mutation викликає витоки пам'яті
java -Xlog:gc*:file=gc.log ...

# jcmd — перевірка флагів
jcmd <pid> VM.flags | grep add-opens

// Runtime-детекція reflection-доступу
// (Java 9+: можна встановити custom ReflectionFilter)
// Або через java.lang.instrument — перехоплення Field.setAccessible()

// Перевірка доступності поля
try {
    Field f = String.class.getDeclaredField("value");
    f.setAccessible(true);
    System.out.println("Accessible: " + f.canAccess(""));
} catch (InaccessibleObjectException e) {
    System.out.println("Blocked by module system");
}

Best Practices для Highload

  • Ніколи не змінюйте String через рефлексію в production-коді
  • Для unit-тестів: використовуйте ізольовані JVM або уникайте мокінгу immutable об’єктів
  • Для серіалізації: використовуйте стандартні механізми (Serializable, JSON, Protobuf)
  • Якщо absolutely необхідно (framework development):
    • Використовуйте --add-opens тільки для необхідних модулів
    • Не змінюйте літерали з String Pool
    • Скидайте hash-поле після зміни value[]
    • Документуйте requirement для всіх користувачів фреймворку
  • Для security-sensitive додатків: встановіть Security Manager (до Java 17) або використовуйте JVM-флаги для блокування reflection
  • Альтернатива: MethodHandles.privateLookupIn() (Java 9+) — більш контрольований доступ до полів
  • Для mutable strings: використовуйте char[], byte[], StringBuilder, або ByteBuffer — вони для цього і призначені

🎯 Шпаргалка для інтерв’ю

Обов’язково знати:

  • Технічно можна змінити byte[] value через reflection, але це вкрай небезпечно
  • Java 9+: module system блокує setAccessible(true) без --add-opens java.base/java.lang=ALL-UNNAMED
  • @Stable аннотація на value — JIT використовує constant folding, зміна зламає оптимізації
  • Зміна літерала в String Pool торкнеться ВСІХ посилань на цей літерал у всьому додатку
  • HashMap key corruption: зміна key через reflection → hashCode() повертає старе значення → get() не знайде
  • Єдиний легітимний сценарій: unit-тести, фреймворки мокінгу, deep serialization

Часті уточнюючі запитання:

  • Що буде при зміні літерала через рефлексію? — Всі посилання на цей літерал побачать змінене значення. String s = "Hello" може стати "Jello".
  • Чому @Stable аннотація важлива? — JIT кешує значення в регістрах, робить constant folding. Зміна викличе deoptimization (~1-10μs).
  • Як module system (Java 9+) захищає від reflection? — setAccessible(true) кидає InaccessibleObjectException без флага --add-opens.
  • Що буде з HashMap при зміні ключа? — hash-поле не перерахується, get() не знайде ключ, HashMap зламаний.

Червоні прапорці (НЕ говорити):

  • ❌ “Reflection на String — нормальна практика” — це антипатерн, порушення контракту immutable
  • ❌ “Можна змінити рядок без наслідків” — ламає String Pool, HashMap, JIT-оптимізації
  • ❌ “setAccessible() завжди працює” — в Java 9+ блокується module system
  • ❌ “Це thread-safe якщо змінити в одному потоці” — @Stable дозволяє JIT кешувати, інші потоки можуть бачити старе значення

Пов’язані теми:

  • [[4. Чому String є незмінним]]
  • [[1. Як працює String Pool]]
  • [[19. Що таке компактні рядки в Java 9+]]