Правильно ли вызывать java.lang.String неизменяемым?

Question

This Java tutorial говорит, что неизменный объект не может изменить свое состояние после создания.

java.lang.String имеет поле

/** Cache the hash code for the string */ 
private int hash; // Default to 0 

, который инициализируется при первом вызове метода hashCode(), поэтому она меняется после создания:

String s = new String(new char[] {' '}); 
    Field hash = s.getClass().getDeclaredField("hash"); 
    hash.setAccessible(true); 
    System.out.println(hash.get(s)); 
    s.hashCode(); 
    System.out.println(hash.get(s)); 

выходного

0 
32 

Является ли это правильно позвонить String неизменяемым?

Answer 1

Термин «неизменяемый» является достаточно расплывчатым, чтобы не допускать точного определения.

Предлагаю прочитать дневник Kinds of Immutability из блога Эрика Липперта. Хотя это технически статья C#, это весьма актуально для поставленного вопроса. В частности:

Наблюдательная неизменность:

Предположим, что у вас есть объект, который имеет свойство, что каждый раз, когда вызове метода на ней, смотреть на поле, и т.д., вы получите такой же результат. С точки зрения вызывающего объекта такой объект будет неизменным. Однако вы могли представить себе, что за кулисами объект выполнял ленивую инициализацию, запоминая результаты вызовов функций в хеш-таблице и т. Д. «Кишки» объекта могут быть полностью изменчивыми.

Какое это имеет значение? Поистине глубоко неизменные объекты никогда не меняют свое внутреннее состояние и, следовательно, по сути являются потокобезопасными. Объект , который может быть изменен за кулисами, все равно должен иметь сложный код потоковой передачи, чтобы защитить его внутреннее изменяемое состояние от повреждения, если объект должен вызываться в двух потоках «при в то же время».

Answer 2

Он не может быть изменен извне и является окончательным классом, поэтому его нельзя подклассифицировать и сделать изменчивым. Эти два требования к неизменности. Отражение рассматривается как хак, это не обычный способ развития.

Answer 3

Отражение позволит вам изменить содержимое любого частного поля. Поэтому правильно ли вызывать любой объект в Java неизменным?

Неизменяемость относится к изменениям, которые инициируются или воспринимаются приложением.

В случае строки факт, что конкретная реализация решает лениво вычислить хэш-код, не воспринимается приложением. Я бы сделал еще один шаг и сказал, что внутренняя переменная, которая увеличивается с помощью объекта, но никогда не была открыта и никогда не использовалась каким-либо другим способом, также была бы приемлема в «неизменяемом» объекте.

Answer 4

Класс может быть неизменным при сохранении изменяемых полей, если он не предоставляет доступ к его изменяемым полям.

Это неизменно по дизайну. Если вы используете Reflection (получение объявленного поля и сброс его доступности), вы обойдете его дизайн.

Answer 5

Да, это правильно назвать их неизменяемыми.

Хотя это правда, что вы можете достичь в и изменить private ... и final ... переменные класса, он является ненужным и невероятно неразумно, что нужно сделать на String объекта. Обычно предположил, что никто не будет достаточно сумасшедшим.

С точки зрения безопасности, вызовы отражения, необходимые для изменения состояния строки, выполняют проверку безопасности. Если вы не пропустили свою песочницу, вызовы будут заблокированы для ненадежного кода. Поэтому вам стоит беспокоиться об этом как о способе, которым ненадежный код может нарушить безопасность песочницы.

Следует также отметить, что JLS заявляет, что использование отражения для изменения final может нарушить работу (например, в многопоточном режиме) или может не иметь никакого эффекта.

Answer 6

После создания все методы в экземпляре String (вызываемые с теми же параметрами) всегда будут иметь одинаковый результат. Вы не можете изменить свое поведение (с помощью любого общедоступного метода), поэтому он всегда будет представлять один и тот же объект. Также это final и не может быть подклассом, поэтому гарантируется, что все экземпляры будут вести себя следующим образом.

Таким образом, с общественной точки зрения объект считается неизменным. В этом случае внутреннее состояние не имеет большого значения.

Answer 7

Лучшее определение было бы не, что объект не изменения, но она не может быть наблюдается были изменены. Это поведение никогда не изменится: .substring(x,y) всегда будет возвращать то же самое для этой строки, что и для equals, и все остальные методы.

Эта переменная рассчитывается при первом вызове .hashcode() и кэшируется для дальнейших вызовов. Это в основном то, что они называют «memoization» в языках функционального программирования.

Отражение на самом деле не инструмент для «программирования», а скорее метапрограммирование (т. Е. Программы программирования для генерации программ), поэтому оно действительно не учитывается. Это эквивалентно изменению значения константы с помощью отладчика памяти.

Answer 8

Да, это правильно. Когда вы изменили строку, как в своем примере, создается новая String, но более старая сохраняет ее значение.

Answer 9

С точки зрения разработчика, использующего отражение, это не правильно позвонить String неизменный. Есть реальные Java-разработчики, которые используют рефлекс для ежедневного написания реального программного обеспечения. Отклонение отражения как «взлома» нелепо. Однако, с точки зрения разработчика, который не использует отражение, правильно называть String неизменяемым. Независимо от того, действительно ли предполагается, что String является неизменным, зависит от контекста.

Неизменяемость является абстрактным понятием и поэтому не может применяться в абсолютном смысле к чему-либо с физической формой (см. ship of Theseus). Конструкции языка программирования, такие как объекты, переменные и методы, существуют физически как биты на носителе данных. Деградация данных - это физический процесс, который происходит со всеми носителями, поэтому никакие данные никогда не могут считаться действительно неизменными. Кроме того, практически практически на практике возможно подорвать функции языка программирования, предназначенные для предотвращения мутации конкретной даты. В противоположность этому, число 3 является 3, всегда было 3, и всегда будет 3.

Применительно к программе данные, неизменность следует считать полезным предположение, а не фундаментальное свойство. Например, если предположить, что String является неизменяемым, можно кэшировать его хеш-код для повторного использования и избежать затрат на повторное вычисление его хеш-кода позже. Практически все нетривиальное программное обеспечение полагается на предположения, что определенные данные не будут мутировать в течение определенных продолжительностей времени. Разработчики программного обеспечения обычно предполагают, что программа code segment не изменится во время ее выполнения, если только они не написали самомодифицирующий код. Понимание того, какие предположения действительны в конкретном контексте, является важным аспектом разработки программного обеспечения.