Changing immutable objects how does this work?

Question

I have seen examples where even though the object is immutable there are situations in which we need to update some fields and as I understand it, the object is passed to a constructor which makes a copy with updated values but the original is not changed. Fine, but what if two threads want to do this? Do we not run into synchronization problems if they both are changing the same field? And how if now there are new objects made (rather than a changed original) do multiple threads know that the values of fields have changed?

I have seen many examples of how to make an immutable class but it is not clear to me how updating attributes works in a multithreaded environment, how synchronization is not required and as I mentioned above, how to determine what object now represents the current state.

Here is an article in which changing an immutable object is discussed: https://jlordiales.me/2012/12/24/the-ins-and-outs-of-immutability/

Answer 1

Fine, but what if two threads want to do this?

Then one thread makes one change (and gets one version of the object) and another thread makes another change (and gets a different, independent version of the object).

Do we not run into synchronization problems if they both are changing the same field?

Nope, because each thread gets their own copy of the object.

And how if now there are new objects made (rather than a changed original) do multiple threads know that the values of fields have changed?

They don't. That's the point.

how to determine what object now represents the current state.

And that's the gotcha. Immutability works great when things are values, or when things really are independent. But if you have an object that represents a single record - say from a database - then changes need to be merged back into that single record. That can be last in wins. That can be some manner of versioning/timestamping. There's lots of options with various tradeoffs.

But the key bit is that synchronization only needs to happen at that last step where the changes are merged and actually take effect on the single source of truth.

Answer 2

The article you linked talks about using the Builder Pattern to create an object. There's no conceptual difference between doing that and using a constructor. You simply treat all of the steps in the Builder as a single operation.

During the build process, you're not mutating an immutable object, because the object is not considered completely built until you call Build() on the builder, at which point you then have a fully constructed, immutable object.

This is also true of constructors. Many constructors have several steps within the body of the constructor method. All of these steps must be completed before the object is considered fully constructed and a usable immutable object results.

---

If you want to make a new immutable object from an existing immutable object with some of the values changed, what you now need is a new constructor or builder that takes an existing object as a parameter, and then set all of the attributes in the constructor or builder that you want to change.

For example:

public BookBuilder(Book book) {
    this.isbn = book.getIsbn();
    this.publicationYear = book.getPublicationYear();
    this.reviews = book.getReviews();
}

And then

Book originalBook = getRandomBook();

Book modifiedBook = new 
BookBuilder(originalBook).isbn("123456").publicationYear(2011).build();

The builder creates a copy of the original book, calls the methods in your fluent interfaces to set the desired fields to new values, and then the build() method freezes the new object in some way so that it becomes immutable.

Note that the author makes two concessions:

1. The builder is not thread safe, and
2. You still have to make copies of objects.

When you use constructors, you can set and change final or readonly members until the constructor finishes executing, at which point these members become unchangeable.