12 posts
Before discussing volatile we need to understand JMM (Java Memory Model) first. Jumping straight to volatile without JMM feels odd, so let's cover JMM. To guarantee correctness of shared memory (visibility, ordering, atomicity), the memory model defines the rules for read/write behavior in multithreaded programs on shared memory systems.
The classic variable operation is increment: turning 1 into 2. Single-threaded, no problem. But the moment two threads operate on the same variable, trouble appears — that's related to Java's memory model, JMM, which I'll cover in the next article on volatile. If thread A already changed the variable to 2 while thread B increments at the same time without seeing that change and also sets it to 2, two increments should give 3 but give 2 instead. That's what brings CAS in.
Surely you've heard plenty of experts talk about AQS. So what is it? From the name AbstractQueuedSynchronizer we can guess it's an abstract queued synchronizer. Every character makes sense on its own; string them together and it stops making sense. Let's break it apart.
This post uses the IP2Location LITE database and queries it by reading the BIN file directly. The code is a trimmed-down version of the official sample, published to Maven Central.
Last time we learned synchronized thread coordination, which is enough to build real things — the most classic being the producer-consumer model. One producer keeps making resources, one consumer keeps taking them, two threads simulating that relationship, like a chef and a server: the chef keeps cooking, and the server takes the dish away once it's plated.
Anyone who's touched multithreading has heard the synchronized keyword. We'll start with a broken example to show what happens without it, fix it with synchronized, and then let synchronized lead us into deadlock.
This tool uses the webmaster tools or open platform APIs of Baidu, Bing and Google to push site updates to search engines immediately, speeding up crawling and indexing.
Let's be clear about this: Java threads have 6 states. Online — including the copy-paste crowd on CSDN who mindlessly repost who-knows-what — everyone says 5. I went and read the docs myself, and I'm certain it's 6.
Last time we looked at the Thread class and the Runnable interface, but that pairing has one problem: no return value. If we want the thread to hand a value back, we need FutureTask and Callable, which is what this post covers.
Last time we talked broadly about why we need multiple threads. Now that we want to study concurrency, let's create threads ourselves and dig into its mysteries.
