Two things:

1) If Contact is stored in a Map, please override equals() & hashCode().

2) Collections.EMPTY_MAP is already immutable, no need to re-wrap it in the constructor.

Cheers.

A much better example of such a structures would be a tree-based map (a balanced tree in particular would only incur O(log(n)) node copies instead of O(n) of hash table).

Still, if the persistent map above is merely to used to avoid synchronization issues, and not to be able to access historical versions of a structure, then it is unnecessarily wasteful. Assuming you need a Map with the ability to capture proper snapshots, so CHM is out: if a Map is shared, fine, make that immutable. If any thread needs to update that shared instance, sure, protect it with a lock or so. But if a thread wants to access the map, and then modify it locally (in your example, by calling getContacts() and then immutablePut etc), it is much more efficient to copy the map *once* (using the immutable Map from contacts) into a regular (“ephemeral”) HashMap for further updates – no need to continuously copy a thread-local value if you don’t need the persistency.

Dimitris

This post was mentioned on Twitter by fshehadeh: RT: @objectpartners: From the Blog: Immutable Data Structures in Concurrent Java Applications http://ow.ly/16tjYL...

Immutability certainly makes things much easier.

Some weird effects happen when we modify the state of keys in collections – they tend to disappear completely, together with their values, only to reappear later when the map is rehashed. Depends on the map implementation of course.

We probably also need an atomic “replace” method that removes the old contact and puts in a new one (also immutable). Otherwise there would be no way to change your email address.

Keep up the articles, I’m looking forward to the next one!

Heinz

You are correct in that there is some performance overhead. This is just a shallow copy however so its not a big impact unless either the map is huge or it is updated often. The overhead is outweighed by the safety of the methodology. This is a common paradigm in functional programming that is starting to make its way into OOP due in no small part to the creation of Scala.

Ultimately you are correct in that you should always weigh the costs of different implementations. I’m not intending to imply that you should always use immutable data structures. Only to present another tool for your development toolbox.

I like the idea of using immutable data structures for simple classes, but for a collection this could incur a pretty large performance hit. Compare the performance of immutablePut() to this:

synchronized(contactMap) {
sendMessages(Map contactMap);
}

When taking over someone else’s code I like to take inventory of where in the code shared, mutable state exists. If contactMap is not shared state somewhere in the call stack above the call to sendMessages() then there’s no problem and no reason to incur the costs of ImmutableMap. If it is shared then you need to weigh the costs involved.

Taking inventory of shared state is complicated by the situation where a local variable is turned into shared state like this:

….
Map localMap = new TreeMap();
….
someInstance.setMap(localMap);

The call to setMap() could result in localMap now being an instance variable of someInstance.

Ideally when writing concurrent code this kind of thing would be documented in a shared state inventory, but I’m dreaming.