Russel Winder

How many Java programmers manage—or even think about—stack use during their programming? More or less none. The vast majority of Java programmers leave stack management to the compiler and runtime system.

How many Java programmers manage—or even think about—heap use during their programming? Very few. The majority of Java programmers assume the garbage collection system will deal with all heap management.

So why are so many Java programmers managing all their threads manually? Because that is what they were taught to do. From the beginning, Java supported shared memory multithreading, which was almost certainly a big error.

Almost all that most Java programmers know about concurrency and parallelism is founded on the theory of constructing operating systems from the 1960s. If you are writing an operating system then this is all good stuff, but are most Java programs actually operating systems? No. So a rethink is in order.

If your code has any synchronized statements, locks, mutexes—all the paraphernalia of operating systems—then in all likelihood, you are doing it wrong. This is the wrong level of abstraction for most Java programmers. Just as stack space and heap space are managed resources, threads should be considered managed resources. Instead of creating threads explicitly and managing them, construct tasks and submit them to a thread pool. Tasks should be single threaded—obviously! If you have many tasks that need to communicate with one another, then rather than using shared memory, use a thread-safe queue instead.

All of this was already known in the 1970s, culminating in Sir Charles Antony (Tony) Richard Hoare creating Communicating Sequential Processes (CSP) as an algebra for describing concurrent and parallel computation. Sadly, it was ignored by the majority of programmers in the rush to use shared memory multithreading, with every program being a new operating system. During the 2000s, though, many looked to get back to sequential processes communicating. Perhaps the most high profile advocate of this in recent years has been the Go programming language. It is all about sequential processes communicating, made to execute via an underlying thread pool.

Many use the terms actors, dataflow, CSP, or active objects, all of which are variations on the sequential process and communication theme. Akka, Quasar, and GPars are all frameworks providing various forms of task over a thread pool. The Java platform comes with the Fork/Join framework, which can be used explicitly and also underpins the Streams library, the revolution of Java introduced in Java 8.

Threads as a managed resource is the correct level of abstraction for the vast majority of Java programmers. Actors, dataflow, CSP, and active objects are the abstractions for the vast majority of programmers to use. Giving up manual control over threads releases Java programmers to write simpler, more comprehensible, more maintainable systems.