Imagine a bacon-wrapped Ferrari. Still not better than our free technical reports.
See all our reports

10 Reasons Why Java Rocks More Than Ever: Part 4 – The Java Memory Model

I’m taking a few moments to continue my Java’s Rocking series, in between a TEDx talk in Estonia and a very busy Devoxx conference in Belgium.

As a reminder, here are my top 10 favorite things about the Java platform again:

  1. The Java Compiler
  2. The Core API
  3. Open-Source
  4. The Java Memory Model
  5. High-Performance JVM
  6. Bytecode
  7. Intelligent IDEs
  8. Profiling Tools
  9. Backwards Compatibility
  10. Maturity With Innovation

This time I’ll talk in more detail about 4. The Java Memory Model.


What rocks about the Java Memory Model

Parallelism is the current way towards increased computing power and concurrency has been entrenched in our applications for many years, even if it was just to have an event dispatch thread. To allow for a coherent memory view, processors include memory models where barriers can be used to ensure that writes are visible to other threads or processes.

The Java Virtual Machine goes one step further by providing its own additional memory model that is independent of the hardware. As opposed to other languages where concurrency primitives are handled by external libraries (such as Perl, Python and Javascript), Java provides this at its core and it can be used by everything that needs coordination and data consistency. The Java Memory Model has allowed the language, the compiler and the core API to be designed together to provide a stable foundation for concurrent operations and shared state.

Practice makes perfect

Even though the Java Memory Model was there since version 1.0, the early years exposed a few critical problems. The Java community analysed the required improvements in JSR-133 and after several years of hard work, the rock-solid Java Memory Model and concurrency API we know today was released with J2SE 1.5 in 2004. No critical issues requiring more redesign have been identified since.

Java was the first to provide such a comprehensive threading model and now the requirement of standardized memory semantics have been recognized throughout the industry. In 2011, C++11 and C11 added their first take on a memory model, inspired by the work done in Java beforehand.

Building blocks for other parallelism solutions

Getting concurrency right is very hard and different problems can nowadays benefit from different solutions. Instead of using threads, an Actor-based model might be more appropriate, or maybe Software Transactional Memory, or maybe Fork/Join, or maybe different lock implementations, …

It’s very convenient to be able to pick whatever solution is most appropriate for you without having to make sure that your compiler, hardware or libraries are compatible. Since the implementations of these different solutions all rely on the Java Memory Model, the basics are covered and it’s much easier to grab the technology that you need for a particular concurrency problem.

Further Reading

If you’re interested in knowing more about the internal workings and benefits of the Java Memory Model, here are a few links to get you started:

Thanks for checking out this post–leave your comments below, or tweet me @gbevin. Stay tuned for Java’s Rockin’ Reason 5: High-Performance VM!

  • Ted

    Huffing some serious paint here.

  • http://www.zeroturnaround.com/ Toomas Römer

    Care to elaborate?