Java Threading Under The Hood


java openjdk internals concurrency threading scheduling monitor lock wait notify

Work in progress. Do tell me if you notice anything amiss, but do not be surprised.

In the previous article, we have talked about how JMM abstractions map to hardware. This time, we will look into threading. If you wish to have a better idea of what things like inflated monitors, biased locking, thread parking or lock contention are, this post is for you. Like the last time, it will contain two sections: a general overview of what should be happening, and then some hands-on OpenJDK fun.

The Theoretical Stuff

Most of the time, whenever we have some concurrently executing code, we also have the need to somehow communicate between them. There are many forms this communication may take, we will only concentrate on some of those.

  • Visibility: assuming that the concurrently executing processes (not in the sense of a UNIX process, mind you) have some shared state, we need the processes to see each other’s changes to that state. This was discussed the last time in sufficient detail
  • Atomicity: we might need to change the state atomically, i.e. in such a way that no other process may jump in the middle of our operation, and screw things up
  • Mutual Exclusion: we might also desire to
P.S. This is the translation of my earlier blog entry in Russian, which has been reviewed by Aleksey Shipilёv, so thank him.

CC0 Freely use anything from this website in any way you can imagine