Страницы

Поиск по вопросам

вторник, 26 ноября 2019 г.

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


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

Можете ли Вы пояснить на примерах или подсказать адекватные источники, где раскрыты рекомендации по использованию неизменяемых объектов в контексте многопоточности?
    


Ответы

Ответ 1



Для начала, есть разница между immutable-объектом (то есть, неизменяемым), и final-ссылкой. Ключевое слово final для объектных типов гарантирует неизменяемость лишь ссылки но не самого объекта. Например, если у вас есть final-ссылка на ArrayList, вы тем не менее можете добавлять в него новые элементы или изменять существующие. В случае же immutable-объекта объект после окончания конструктора не изменяется вообще Одного лишь модификатора final для этого недостаточно, необходимо, чтобы все подбъекты были тоже неизменяемыми. Вы в принципе можете держать внутри ссылку на изменяемый объект, но обращаться с ним так, чтобы он не менялся. Использование неизменяемых объектов даёт много выгод. Например, о таком объекте намног легче судить в ситуации, когда во многих частях программы есть ссылка на него (для изменяемого объекта, любая часть программы может вызвать мутирующую функцию в практически любой момент времени и из любого потока). Но то, что для нас важно в контексте вопроса — неизменяемые объекты не требуют синхронизаци при многопоточном доступе. Вот собственно и вся рекомендация: используйте неизменяемы объекты, и вам не придётся думать о том, что нужно, а что не нужно синхронизировать Единственная возможная проблема — если вы внутри ещё не отработавшего конструктора публикуете ссылку на объект, через которую к нему может получить доступ кто-нибудь ещё, и увидеть объект в изменяющемся состоянии! (Это бывает не так уж и редко. Например, иногда программист хочет добавить объект в конструкторе в коллекцию всех объектов данного типа.) Следует различать действительно неизменяемые объекты, и объекты, имеющие лишь интерфей «только для чтения». При чтении объект тем не менее может менять свою внутреннюю структур (например, кэшировать самый свежий запрос данных). Такие объекты не являются в строгом смысле неизменяемыми, и не могут быть использованы из разных потоков без предосторожностей. (Поэтому, если ваш объект включает другие объекты, убедитесь, что документация гарантирует их неизменяемость!) Обратите внимание, что для полей неизменяемого объекта вы практически обязаны использоват final! Дело в так называемой безопасной публикации. Смотрите. Инструкции в Java-программ могут быть переставлены как оптимизатором, так и процессором (у Java достаточно слабая модель памяти). Поэтому, если не предпринимать специальных действий, окончание работы конструктора и присвоение значений полям может быть переставлено (но невидимо в рамках текущего потока)! Использование final гарантирует, что такого не произойдёт.

Ответ 2



Immutable объект - это объект, состояние которого после создания невозможно изменить В случае Java это значит что все поля экземпляра у класс отмечены как final и являются примитивами или тоже immutable типами. Пример: public class ImmutablePoint { private final int x; private final int y; private final String description; public ImmutablePoint(int x, int y, String description) { this.x = x; this.y = y; this.description = description; } } После создания экземпляра ImmutablePoint его модификация невозможна. Простейший пример immutable класса из JDK это String. Любые методы, которые вы вызовит на строке (например description.toLowerCase()) вернут новую строку, а не модифицируют исходную. Пример mutable класс из JDK - Date. Например myDate.setHours(x) модифицирует са экземпляр myDate! В случае многопоточного программирования преимущества immutable классов очевидны после создания объекты можно передавать другим потокам и они всегда будут в актуально состоянии. Т.е. вам не надо проверять не устарело ли состояние вашего экземпляра и н модифицировал ли его другой поток пока вы с ним работаете. Например, у вас есть метод bill(Date endDate), в нём вы наивно проверяете соответствие endDate каким-то предварительным условиям и начинаете с ней работать. В этот момент другой поток может изменить endDate, например установит её глубоко в прошлое. Последствия могут быть самыми удивительными.

Комментариев нет:

Отправить комментарий