了解线程安全有两个方面很重要。
- 执行控制，以及
- 内存可见性
第一个与控制代码何时执行（包括执行指令的顺序）以及它是否可以并发执行有关，第二个与何时其他人可以看到已完成的内存中的效果有关线程。因为每个 CPU 在它和主内存之间都有多个级别的缓存，所以在不同 CPU 或内核上运行的线程在任何给定时间都可以看到不同的“内存”，因为线程被允许获取和处理主内存的私有副本。
使用synchronized 可以防止任何其他线程获得监视器（或锁）同一个对象，从而防止所有受同步保护的代码块在同一个对象上同时执行。同步也创建了一个“happens-before”内存屏障，导致内存可见性约束，使得在某个线程释放锁之前所做的任何事情出现给随后获取的另一个线程相同的锁在获得锁之前已经发生。实际上，在当前的硬件上，这通常会导致在获取监视器时刷新 CPU 缓存并在释放监视器时写入主内存，这两者都是（相对）昂贵的。
另一方面，使用volatile 会强制对 volatile 变量的所有访问（读取或写入）都发生在主内存中，从而有效地将 volatile 变量排除在 CPU 缓存之外。这对于一些只要求变量的可见性正确且访问顺序不重要的操作很有用。使用 volatile 还会更改对 long 和 double 的处理，以要求对它们的访问是原子的；在某些（较旧的）硬件上，这可能需要锁定，但在现代 64 位硬件上则不需要。在 Java 5+ 的新 (JSR-133) 内存模型下，volatile 的语义已得到加强，在内存可见性和指令顺序方面几乎与同步一样强大（参见 http://www.cs.umd.edu/users/pugh/java/memoryModel/jsr-133-faq.html#volatile）。出于可见性的目的，对 volatile 字段的每次访问都相当于半个同步。
在新的内存模型下，volatile 变量之间不能相互重新排序仍然是事实。不同之处在于，现在重新排序围绕它们的正常字段访问不再那么容易了。写入易失性字段与释放监视器具有相同的记忆效应，从易失性字段读取具有与监视器获取相同的记忆效应。实际上，由于新的内存模型对 volatile 字段访问与其他字段访问（无论是否为 volatile）的重新排序设置了更严格的限制，因此线程 A 在写入 volatile 字段 f 时可见的任何内容都对线程 @987654330 可见@当它读取f时。
-- JSR 133 (Java Memory Model) FAQ
因此，现在两种形式的内存屏障（在当前 JMM 下）都会导致指令重新排序屏障，从而阻止编译器或运行时跨屏障重新排序指令。在旧的 JMM 中，volatile 并没有阻止重新排序。这可能很重要，因为除了内存屏障之外，唯一的限制是，对于任何特定线程，代码的净效果与指令在精确的它们在源中出现的顺序。
volatile 的一个用途是动态重新创建共享但不可变的对象，许多其他线程在其执行周期的特定点获取对该对象的引用。需要其他线程在重新创建的对象发布后开始使用它，但不需要完全同步的额外开销以及随之而来的争用和缓存刷新。
// Declaration
public class SharedLocation {
static public SomeObject someObject=new SomeObject(); // default object
}
// Publishing code
// Note: do not simply use SharedLocation.someObject.xxx(), since although
// someObject will be internally consistent for xxx(), a subsequent
// call to yyy() might be inconsistent with xxx() if the object was
// replaced in between calls.
SharedLocation.someObject=new SomeObject(...); // new object is published
// Using code
private String getError() {
SomeObject myCopy=SharedLocation.someObject; // gets current copy
...
int cod=myCopy.getErrorCode();
String txt=myCopy.getErrorText();
return (cod+" - "+txt);
}
// And so on, with myCopy always in a consistent state within and across calls
// Eventually we will return to the code that gets the current SomeObject.
特别是谈到您的“读-更新-写”问题。考虑以下不安全的代码：
public void updateCounter() {
if(counter==1000) { counter=0; }
else { counter++; }
}
现在，在 updateCounter() 方法不同步的情况下，两个线程可能同时进入它。在可能发生的许多排列中，一个是线程 1 对 counter==1000 进行测试并发现它为真，然后被挂起。然后线程 2 进行相同的测试，并且也认为它是真的并被挂起。然后线程 1 恢复并将计数器设置为 0。然后线程 2 恢复并再次将计数器设置为 0，因为它错过了线程 1 的更新。即使没有如我所描述的那样发生线程切换，也可能发生这种情况，而仅仅是因为两个不同的计数器缓存副本存在于两个不同的 CPU 内核中，并且每个线程都在单独的内核上运行。就此而言，一个线程的计数器值可能是一个值，而另一个线程的计数器值可能是完全不同的值，这仅仅是因为缓存。
在这个例子中重要的是变量 counter 从主存读取到缓存中，在缓存中更新，并且仅在稍后发生内存障碍或何时发生的某个不确定点写回主存其他东西需要缓存内存。使计数器volatile 不足以保证此代码的线程安全，因为对最大值的测试和分配是离散操作，包括作为一组非原子read+increment+write 机器指令的增量，例如： /p>
MOV EAX,counter
INC EAX
MOV counter,EAX
仅当对它们执行的所有操作都是“原子”操作时，可变变量才有用，例如我的示例，其中对完全形成的对象的引用仅被读取或写入（而且，实际上，它通常只从一个点写入）。另一个示例是支持写入时复制列表的易失性数组引用，前提是该数组只能通过首先获取引用的本地副本来读取。