The immutable version adds an overhead compared with the mutable version because it is necessary to create a new instance of the class as a result of calling the absolute, negate, add, or sub methods. The previously analyzed mutable class named Vector3D just changed the values for the fields, and it wasn't necessary to generate a new instance. Hence, the memory footprint for the immutable version is higher than the mutable version.

The immutable class named ImmutableVector3d has both a memory and performance overhead compared with the mutable version. It is more expensive to create a new instance than to change the values of a few fields. However, as previously explained, when we work with concurrent code, it makes sense to pay for the extra overhead to avoid potential issues caused by mutable objects. We just have to make sure we analyze the advantages and tradeoffs in order to decide which is the most convenient way...