使用volatile的一个常见示例是使用volatile布尔变量作为终止线程的标志。如果您已经启动了一个线程，并且希望能够安全地从另一个线程中断它，您可以让线程定期检查标志。要阻止它，将标志设置为true。通过将标志设置为易失性，可以确保正在检查它的线程在下次检查时看到它已经设置好，甚至不必使用同步块。

Volatile变量基本上用于主共享缓存线上的即时更新(刷新)，以便立即将更改反映到所有工作线程。

虽然我在这里提到的答案中看到了许多很好的理论解释，但我在这里添加了一个实际的例子来解释:

1.

代码在不使用volatile的情况下运行

public class VisibilityDemonstration {

private static int sCount = 0;

public static void main(String[] args) {
    new Consumer().start();
    try {
        Thread.sleep(100);
    } catch (InterruptedException e) {
        return;
    }
    new Producer().start();
}

static class Consumer extends Thread {
    @Override
    public void run() {
        int localValue = -1;
        while (true) {
            if (localValue != sCount) {
                System.out.println("Consumer: detected count change " + sCount);
                localValue = sCount;
            }
            if (sCount >= 5) {
                break;
            }
        }
        System.out.println("Consumer: terminating");
    }
}

static class Producer extends Thread {
    @Override
    public void run() {
        while (sCount < 5) {
            int localValue = sCount;
            localValue++;
            System.out.println("Producer: incrementing count to " + localValue);
            sCount = localValue;
            try {
                Thread.sleep(1000);
            } catch (InterruptedException e) {
                return;
            }
        }
        System.out.println("Producer: terminating");
    }
}
}

在上面的代码中，有两个线程——生产者和消费者。

生产者线程在循环中迭代5次(睡眠时间为1000毫秒或1秒)。在每次迭代中，生产者线程将sCount变量的值增加1。因此，在所有迭代中，生产者将sCount的值从0更改为5

使用者线程处于一个常量循环中，每当sCount的值发生变化时，它就会打印，直到值达到5为止。

两个循环同时开始。因此，生产者和消费者都应该将sCount的值打印5次。

输出

Consumer: detected count change 0
Producer: incrementing count to 1
Producer: incrementing count to 2
Producer: incrementing count to 3
Producer: incrementing count to 4
Producer: incrementing count to 5
Producer: terminating

分析

In the above program, when the producer thread updates the value of sCount, it does update the value of the variable in the main memory(memory from where every thread is going to initially read the value of variable). But the consumer thread reads the value of sCount only the first time from this main memory and then caches the value of that variable inside its own memory. So, even if the value of original sCount in main memory has been updated by the producer thread, the consumer thread is reading from its cached value which is not updated. This is called VISIBILITY PROBLEM .

2.

代码使用volatile运行

在上面的代码中，用下面的代码替换声明了sCount的代码行:

private volatile  static int sCount = 0;

输出

Consumer: detected count change 0
Producer: incrementing count to 1
Consumer: detected count change 1
Producer: incrementing count to 2
Consumer: detected count change 2
Producer: incrementing count to 3
Consumer: detected count change 3
Producer: incrementing count to 4
Consumer: detected count change 4
Producer: incrementing count to 5
Consumer: detected count change 5
Consumer: terminating
Producer: terminating

分析

当我们声明一个变量为volatile时，这意味着所有对这个变量的读写操作都将直接进入主存。这些变量的值永远不会被缓存。

由于sCount变量的值永远不会被任何线程缓存，消费者总是从主内存中读取sCount的原始值(在那里由生产者线程更新)。因此，在这种情况下，输出是正确的，两个线程都打印了5次不同的sCount值。

通过这种方式，volatile关键字解决了可见性问题。

如果您有一个多线程系统，这些多线程处理一些共享数据，这些线程将在它们自己的缓存中加载数据。如果我们不锁定资源，在一个线程中所做的任何更改都不会在另一个线程中可用。

使用锁定机制，我们可以添加对数据源的读/写访问。如果一个线程修改了数据源，该数据将存储在主存中而不是它的缓存中。当其他线程需要这个数据时，它们将从主存中读取它。这将显著增加延迟。

为了减少延迟，我们将变量声明为volatile。这意味着无论何时变量的值在任何处理器中被修改，其他线程都将被迫读取它。它仍然有一些延迟，但比从主存中读取要好。

…volatile修饰符保证任何读取字段的线程都能看到最近写入的值。——乔希·布洛赫 如果您正在考虑使用volatile，请仔细阅读java.util.concurrent包，它处理原子行为。 维基百科上关于单例模式的帖子显示了volatile的使用。

是的，我经常使用它——它对多线程代码非常有用。你指的那篇文章很好。不过有两件重要的事情要记住:

You should only use volatile if you completely understand what it does and how it differs to synchronized. In many situations volatile appears, on the surface, to be a simpler more performant alternative to synchronized, when often a better understanding of volatile would make clear that synchronized is the only option that would work. volatile doesn't actually work in a lot of older JVMs, although synchronized does. I remember seeing a document that referenced the various levels of support in different JVMs but unfortunately I can't find it now. Definitely look into it if you're using Java pre 1.5 or if you don't have control over the JVMs that your program will be running on.