万字长文！一文彻底搞懂Java—volatile关键字

针对线程安全问题，有没有解决办法呢？

一般情况下，Java 中解决缓存不一致的方法有两种，第一种就是 synchronized 使用的总线锁方式，也就是在总线上声言 LOCK# 信号；第二种就是著名的 MESI 协议。这两种都是硬件层面提供的解决方式。

我们先来说一下第一种总线锁的方式。通过在总线上声言 LOCK# 信号，能够有效地阻塞其他 CPU 对于总线的访问，从而使得总线只能有一个 CPU 访问变量所在的内存。在上面的 i = i + 1 代码示例中，在代码执行的过程中，声言了 LOCK# 信号后，那么只有等待 i = i + 1 的结果执行完毕并应用到内存后，总线锁才会解开，其他 CPU 才能够继续访问内存中的变量，再继续执行后面的代码，这样就解决了缓存不一致问题。

但是上面的方式会有一个问题，由于在锁住总线期间，其他 CPU 无法访问内存，导致效率低下。

在 JDK 1.6 之后，优化了 synchronized 声言 LOCK# 的方式，不再对总线进行锁定，转而采取了对 CPU 缓存行进行锁定，因为本篇文章不是介绍 synchronized 实现细节的文章，所以不再对这种方式进行详细介绍，读者只需要知道在优化之后，synchronized 的性能不再成为并发问题的瓶颈了。

MESI 协议就是缓存一致性协议，即 Modified（被修改）Exclusive（独占的） Shared（共享的） Or Invalid（无效的）。MESI 他的基本思想就是如果发现 CPU 操作的是共享变量，其他 CPU 也会出现这个共享变量的副本，在 CPU 执行代码期间，会发出信号通知其他人 CPU 自己正在修改共享变量，其他 CPU 收到通知后就会把自己的共享变量置为无效状态。

并发编程中的三个主要问题

===============================================================================

可见性问题

在单核 CPU 时代，所有的线程共用一个 CPU，CPU 缓存和内存的一致性问题容易解决，我们还是拿上面的 i = 1 + 1 来举例，CPU 和 内存之间如果用图来表示的话我想会是下面这样。

![(https://upload-images.jianshu.io/upload_images/26303042-a3ff0450c9a71e47.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)

在多核时代，每个核都能够独立地运行一个线程，每个 CPU 都有自己的缓存，这时 CPU 缓存与内存的数据一致性就没那么容易解决了，当多个线程在不同的 CPU 上线时，这些线程使用的是不同的 CPU 缓存。

因为 i 没有经过任何线程安全措施的保护，多个线程会被并发修改 i 的值，所以我们认为 i 不是线程安全的，导致这种结果的出现是由于 aT