During my recent week at the JavaOne conference, I attended several sessions dealing with issues of concurrency in programming. What started as a cursory interest, turned into a strong desire to really understand these problems at a deeper level. But I’m still really a noob when it comes to this stuff, so I figure this is a great time to try to explain it to other beginners.

Ok, let’s start with the basics, what is concurrency and why should you care? Well according to Wikipedia concurrency is

a property of systems in which several computations are executing simultaneously, and potentially interacting with each other. The computations may be executing on multiple cores in the same chip, preemptively time-shared threads on the same processor, or executed on physically separated processors.

Unless you’re writing applications that only have a few simultaneous users, chances are you will use the threading features of java to try and take advantage of the performance benefits of asynchronous processing. Even if you are writing a simple MVC style web app, that servlet container is going to be multi-threaded and you could encounter concurrency issues in your servlet code. The problem is, when we’re coding our app, it’s only ever exercised in a single-user scenario. And you can’t really write unit tests to check the behavior of multi-threaded areas of your code. Therefore, concurrency issues tend to not be identified during testing. Usually they appear as strange, random bugs during periods of heavy load, and cannot be reliably reproduced. Awesome. I love those.

So how do we identify the areas of our application that are susceptible to concurrency issues, and how do we code for them? Those are some pretty tough questions, I’ve found. Maybe by the end of this series we’ll have some answers. In the simplest of terms, managing concurrency means managing the shared state in your application, more specifically, mutable shared state. That really means any instance or static class level fields that are not declared as final. (There are some nuances to the use of the final keyword, but let’s keep it easy for now).
To control concurrency issues, follow 3 rules:

• Don’t share state across threads. This is done by encapsulating your state. In the simplest example, this means that class fields are private and access is limited to one or two methods. This will make it easier to create code that is thread-safe.
• Make your state immutable. If the value of your fields cannot be changed, you are already thread-safe! Consider exposing read-only versions of your objects when possible.
• Finally, synchronize access. Only allow a single thread to access your state at any given time. Most concurrency discussion centers around locking and synchronization.

What does it mean to synchronize access? Synchronization is about controlling access to state and is handled primarily through locks. Proper synchronization guarantees 2 things:

• Mutual Exclusion – this guarantees that only one thread can hold a given lock, and therefore only one thread has access to the locked state(data).
• Visibility – this guarantees that as a thread releases a lock, any changes made to shared variables, the mutable shared state, will be immediately seen by all threads, most importantly the next thread acquiring the lock. This ensures that no threads see stale data.

So, concurrent programming in a nutshell:

Limit the mutable state (data that can be changed) in your objects. When allowing others to access and change your objects state, control that state using proper synchronization.

So that’s the absolute basics on concurrency, but what about Java?
The fundamental power of java is its memory model and the threading facilities that are built into the language. Along with thread support are many mechanisms to correctly handle concurrent operations. And this will be the subject of the rest of this blog series. Stay tuned.