A New Concurrency Model in Java

Things have changed considerably in the last few years in terms of how we write code in concurrent models.

In the past we always had a tendency to share state and use complex concurrency mechanisms to synchronize the threads to allow them fair use of the resources in our application, those were the times when reading “Java Concurrency in practice” was almost a must for many Java developers in our industry that had to deal with concurrent tasks.

Now the paradigm has shifted completely to an approach that makes a lot more sense. This paradigm is mainly composed of three principles: non-shared state, immutability, and non-blocking operations.

Non-shared state + immutability

Although I still see some developers (wrongly) using this approach, what we used to do previously was to have components with shared state and implement mechanisms to synchronize the access to this state. For instance, the use of synchronized or atomic variables in Java caused other threads requesting access to that resource to remain blocked until the resource was released. That’s quite bad, isn’t it?

In the silly example shown below, if multiple threads were trying to call the method pleaseBlockMe they’d remain blocked waiting to gain the lock to be able to execute the method, leading to very bad performance and quite possibly thread starvation in our thread pool.

This approach was quite complex because by sharing state the developer had to think hard and be always alert as to how a shared resource was being accessed to avoid race conditions, deadlocks, and any other possible issues.

So that’s why the community came up with a completely new and much simpler approach that consists precisely in avoiding that complexity. The best way to solve concurrency synchronization complexity is by completely avoiding it, so the idea is that every thread creates a new “one-time” immutable object and the application will use other, simpler means to update the application state. Makes…