How does immutability work as a concurrency strategy, and what actually makes a class truly immutable?

A genuinely immutable object requires zero synchronization to use safely, because its state can never change after construction, which means it can be freely shared between any number of threads without any risk of a race condition. Several conditions are needed to make a class truly immutable: the class itself should be declared final so it cannot be subclassed in a way that breaks the immutability guarantee; every field should be private and final; the class should expose no setter methods, so nothing can mutate its state after construction; the constructor should take defensive copies of any mutable objects passed in, for example this.list = List.copyOf(list); and any getter that would otherwise return a reference to internal mutable state should also return a defensive copy. Java records automatically satisfy most of these requirements out of the box. Well-known examples of immutable classes in the JDK include BigInteger, String, and LocalDate. The main tradeoff is that every "modification" actually creates a brand-new object, which can add meaningful garbage collection pressure in workloads that mutate very frequently.