An object is considered immutable if its state cannot change after it is constructed. Maximum reliance on immutable objects is widely accepted as a sound strategy for creating simple, reliable code. In some cases, an object is considered immutable even if some internally used attributes change but the object's state appears to be unchanging from an external point of view. For example, an object that uses memoization to cache the results of expensive computations could still be considered an immutable object.
Immutable objects are often useful because they are inherently thread-safe. Other benefits are that they are simpler to understand and reason about and offer higher security than mutable objects.Small immutable objects can easily be copied efficiently, but larger immutable objects require more complicated persistent data structure algorithms to be efficiently copied. Mutable objects are sometimes used instead of immutable objects for performance reasons.
Immutable objects are particularly useful in concurrent applications. Since they cannot change state, they cannot be corrupted by thread interference or observed in an inconsistent state.
Programmers are often reluctant to employ immutable objects, because they worry about the cost of creating a new object as opposed to updating an object in place. The impact of object creation is often overestimated, and can be offset by some of the efficiencies associated with immutable objects. These include decreased overhead due to garbage collection, and the elimination of code needed to protect mutable objects from corruption.
Check here for how immutable objects are thread safe ?
Refer : http://www.javaranch.com/journal/2003/04/immutable.htm
http://docs.oracle.com/javase/tutorial/essential/concurrency/immutable.html
Immutable objects are often useful because they are inherently thread-safe. Other benefits are that they are simpler to understand and reason about and offer higher security than mutable objects.Small immutable objects can easily be copied efficiently, but larger immutable objects require more complicated persistent data structure algorithms to be efficiently copied. Mutable objects are sometimes used instead of immutable objects for performance reasons.
Immutable objects are particularly useful in concurrent applications. Since they cannot change state, they cannot be corrupted by thread interference or observed in an inconsistent state.
Programmers are often reluctant to employ immutable objects, because they worry about the cost of creating a new object as opposed to updating an object in place. The impact of object creation is often overestimated, and can be offset by some of the efficiencies associated with immutable objects. These include decreased overhead due to garbage collection, and the elimination of code needed to protect mutable objects from corruption.
Check here for how immutable objects are thread safe ?
Refer : http://www.javaranch.com/journal/2003/04/immutable.htm
http://docs.oracle.com/javase/tutorial/essential/concurrency/immutable.html
No comments:
Post a Comment