Immutable java что это

Как написать иммутабельный класс?

Immutable (неизменяемый) класс – это класс, состояние экземпляров которого невозможно изменить после создания.

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

Шаги, которые необходимо предпринять, чтобы класс стал immutable:

1. Запретите расширение класса – либо объявите его final , либо закройте доступ наследникам ко всем способам мутации, перечисленным в следующих пунктах;
2. Сделайте все поля финальными;
3. Не выставляйте наружу методов-мутаторов, которые меняют состояние;
4. Не отдавайте наружу поля ссылочного изменяемого типа (объекты классов, массивы) – если объект под ссылкой не иммутабельный, должна возвращаться его глубокая копия (defensive copy);
5. Создавайте объект правильно (подробнее в следующем посте).

Если вам нужны преимущества иммутабельного объекта, но также нужно иногда изменять его, подойдет подход copy on write: каждый метод-мутатор должен мутировать и возвращать не сам объект, а только что созданную его копию. Оригинал всё так же остается неизменным.

Иммутабельность в Java

Привет, Хабр. В преддверии скорого старта курса «Подготовка к сертификации Oracle Java Programmer (OCAJP)» подготовили для вас традиционный перевод материала.

Приглашаем также всех желающих поучаствовать в открытом демо-уроке «Конструкторы и блоки инициализации». На этом бесплатном вебинаре мы:
— Разберём конструктор на запчасти
— Определим финалистов (финальные переменные)
— Наведём порядок (инициализации)

Иммутабельный (неизменяемый, immutable) класс — это класс, который после инициализации не может изменить свое состояние. То есть если в коде есть ссылка на экземпляр иммутабельного класса, то любые изменения в нем приводят к созданию нового экземпляра.

Чтобы класс был иммутабельным, он должен соответствовать следующим требованиям:

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

Иммутабельность в действии

Начнем со следующего класса, который, на первый взгляд, выглядит иммутабельным:

import java.util.Map; public final class MutableClass < private String field; private MapfieldMap; public MutableClass(String field, Map fieldMap) < this.field = field; this.fieldMap = fieldMap; >public String getField() < return field; >public Map getFieldMap() < return fieldMap; >>

Теперь посмотрим на него в действии.

import java.util.HashMap; import java.util.Map; public class App < public static void main(String[] args) < Mapmap = new HashMap<>(); map.put("key", "value"); // Инициализация нашего "иммутабельного" класса MutableClass mutable = new MutableClass("this is not immutable", map); // Можно легко добавлять элементы в map == изменение состояния mutable.getFieldMap().put("unwanted key", "another value"); mutable.getFieldMap().keySet().forEach(e -> System.out.println(e)); > > // Вывод в консоли unwanted key key

Очевидно, что мы хотим запретить добавление элементов в коллекцию, поскольку это изменение состояния объекта, то есть отсутствие иммутабельности.

import java.util.HashMap; import java.util.Map; public class AlmostMutableClass < private String field; private MapfieldMap; public AlmostMutableClass(String field, Map fieldMap) < this.field = field; this.fieldMap = fieldMap; >public String getField() < return field; >public Map getFieldMap() < MapdeepCopy = new HashMap(); for(String key : fieldMap.keySet()) < deepCopy.put(key, fieldMap.get(key)); >return deepCopy; > >

Здесь мы изменили метод getFieldMap , который теперь возвращает глубокую копию коллекции, ссылка на которую есть в AlmostMutableClass . Получается, что если мы получим Map , вызвав метод getFieldMap , и добавим к нему элемент, то на map из нашего класса это никак не повлияет. Изменится только map , которую мы получили.

Однако если у нас остается доступ к исходной map , которая была передана в качестве параметра конструктору, то все не так уж и хорошо. Мы можем изменить ее, тем самым изменив состояние объекта.

import java.util.HashMap; import java.util.Map; public class App < public static void main(String[] args) < Mapmap = new HashMap<>(); map.put("good key", "value"); // Инициализация нашего "иммутабельного" класса AlmostMutableClass almostMutable = new AlmostMutableClass("this is not immutable", map); // Мы не можем изменять состояние объекта // через добавление элементов в полученную map System.out.println("Result after modifying the map after we get it from the object"); almostMutable.getFieldMap().put("bad key", "another value"); almostMutable.getFieldMap().keySet().forEach(e -> System.out.println(e)); System.out.println("Result of the object's map after modifying the initial map"); map.put("bad key", "another value"); almostMutable.getFieldMap().keySet().forEach(e -> System.out.println(e)); > > // Вывод в консоли Result after modifying the map after we get it from the object good key Result of the object's map after modifying the initial map good key bad key

Мы забыли, что в конструкторе нужно сделать то же самое, что и в методе getFieldMap . В итоге конструктор должен выглядеть так:

public AlmostMutableClass(String field, Map fieldMap) < this.field = field; MapdeepCopy = new HashMap(); for(String key : fieldMap.keySet()) < deepCopy.put(key, fieldMap.get(key)); >this.fieldMap = deepCopy; > // Вывод в консоли Result after modifying the map after we get it from the object good key Result of the object's map after modifying the initial map good key

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

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

Иммутабельность строк в Java

Класс String , представляющий набор символов, вероятно, самый популярный класс в Java. Его назначение — упростить работу со строками, предоставляя различные методы для их обработки.

Например, в классе String есть методы для получения символов, выделения подстрок, поиска, замены и многие другие. Как и другие классы-обертки в Java (Integer, Boolean и т.д.), класс String является иммутабельным.

Иммутабельность строк дает следующие преимущества:

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

Подробнее о курсе «Подготовка к сертификации Oracle Java Programmer (OCAJP)».

Смотреть вебинар «Конструкторы и блоки инициализации».

Объекты Stateless и Immutable

Данные объекты используются в многопоточной среде для того, чтобы быть уверенными что эти объекты не будут изменены каким-либо другим потоком. То есть зафиксировали состояние один раз и все. Иначе нам бы пришлось думать о том как синхронизировать доступ к этим объектам из разных потоков. А это замедляет работу программы.

Что такое stateless объект?

Stateless объект, или «объект без состояния» — это объект, в котором нет изменяемых полей. Если проще — это объект, в котором «и менять-то нечего» ��

Так что такое «состояние»?

Обычно каждый объект имеет какие-то изменяемые переменные внутри. Например, мы создаем объект Car, и задаем ему:

Все эти параметры вместе — цвет, марка и пробег — и есть состояние объекта. Если мы, например, поменяем пробег — скажем сделаем его 10000 км — тем самым мы изменим состояние Car:

Так, если мы поменяем любой параметр объекта — цвет, марку, или пробег — состояние опять изменится.

Объект без состояния

Обычно мы создаем объекты так, что они хранят много переменных. И эти переменные изменяются, меняя состояние объекта.

Но это обычно.

На самом деле, изменяемые части — а значит и состояние — есть не у всех объектов. На некоторые посмотришь и скажешь:

immutable-объекты и многопоточность

Доброго дня, уважаемые гуру Java. Анализирую вопросы, которые задают на собеседованиях. Пытаюсь более детально разобраться с темой immutable-объектов. К сожалению, те ресурсы, которые предлагает «Google» дают лишь очень общую информацию в стиле «immutable-объекты, это те объекты, которые не могут быть изменены в программе. Для того, чтобы объект был immutable используйте модификатор final». Как энциклопедические знания такое конечно можно сказать, на собеседовании, но думаю, там хотят слышать понимание более глубоких принципов. Кроме того, хочу написать мини-проект для лучшего понимания. Можете ли Вы пояснить на примерах или подсказать адекватные источники, где раскрыты рекомендации по использованию неизменяемых объектов в контексте многопоточности?

Отслеживать
34.5k 15 15 золотых знаков 65 65 серебряных знаков 94 94 бронзовых знака
задан 29 июн 2015 в 5:26
645 1 1 золотой знак 6 6 серебряных знаков 14 14 бронзовых знаков

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

29 июн 2015 в 6:52
@Etki, запилите как ответ, если не трудно.
29 июн 2015 в 7:32

Что касается адекватных источников: Java Concurrency in Practice by Brian Goetz, Tim Peierls, Joshua Bloch, Joseph Bowbeer, David Holmes, Doug Lea — наше все.

29 июн 2015 в 7:33

@Nofate, это бы хорошо с примерами race condition, а я по этой части в джаве теоретик. Я постараюсь родить что-нибудь вечером.

29 июн 2015 в 8:06

2 ответа 2

Сортировка: Сброс на вариант по умолчанию

Для начала, есть разница между immutable-объектом (то есть, неизменяемым), и final-ссылкой.

Ключевое слово final для объектных типов гарантирует неизменяемость лишь ссылки, но не самого объекта. Например, если у вас есть final-ссылка на ArrayList , вы тем не менее можете добавлять в него новые элементы или изменять существующие.

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

Использование неизменяемых объектов даёт много выгод. Например, о таком объекте намного легче судить в ситуации, когда во многих частях программы есть ссылка на него (для изменяемого объекта, любая часть программы может вызвать мутирующую функцию в практически любой момент времени и из любого потока).

Но то, что для нас важно в контексте вопроса — неизменяемые объекты не требуют синхронизации при многопоточном доступе. Вот собственно и вся рекомендация: используйте неизменяемые объекты, и вам не придётся думать о том, что нужно, а что не нужно синхронизировать. Единственная возможная проблема — если вы внутри ещё не отработавшего конструктора публикуете ссылку на объект, через которую к нему может получить доступ кто-нибудь ещё, и увидеть объект в изменяющемся состоянии! (Это бывает не так уж и редко. Например, иногда программист хочет добавить объект в конструкторе в коллекцию всех объектов данного типа.)

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

Обратите внимание, что для полей неизменяемого объекта вы практически обязаны использовать final ! Дело в так называемой безопасной публикации. Смотрите. Инструкции в Java-программе могут быть переставлены как оптимизатором, так и процессором (у Java достаточно слабая модель памяти). Поэтому, если не предпринимать специальных действий, окончание работы конструктора и присвоение значений полям может быть переставлено (но невидимо в рамках текущего потока)! Использование final гарантирует, что такого не произойдёт.