首先，volatile的英文本义是“挥发、不稳定的”，延伸意义为敏感的。在Java中提供的是一种稍弱的同步机制，即volatile变量，用来确保将变量的更新操作通知到其他线程。
当把变量声明为volatile类型后，编译器与运行时都会注意到这个变量是共享的。也就是在使用volatile关键字时，该关键字可以确保对一个变量的更新对其他线程马上可见。因此不会将该变量上的操作与其他内存操作一起重排序。
volatile变量不会被缓存在寄存器或者其他处理器不可见的地方，而是会把值刷新回主内存。因此在读取volatile类型的变量时总会返回最新写入的值。
volatile用于保证在多线程环境下共享变量的可见性。通过增加内存屏障防止多个指令之间的重排序。
可见性，是指当某一个线程对共享变量的修改，其他线程可以立刻看到修改之后的值。类似于synchronized，但不具备synchronized的互斥性，所以对volatile变量的操作并非都具有原子性。具体来说就是，当线程写入了volatile变量值时就等价于线程退出了synchronized同步块(把写入工作内存的变量值同步到主内存)，读取volatile变量值时就相当于进入同步块(先清空本地内存变量值，再从主内存获取最新值)
补充一点的是对于基本类型的修改可以在随后对多个线程的读保持一致，但是对于引用类型如数组，实体bean，仅仅保证引用的可见性，但并不保证引用内容的可见性。
其实这个可见性问题，我认为本质上是由几个方面造成的。
CPU层面的高速缓存，在CPU里面设计了三级缓存去解决CPU运算效率和内存IO效率问题，但是带来的就是缓存一致性问题。而在多线程并行执行的情况下，缓存一致性就会导致可见性问题。
所以，对于增加了volatile关键字修饰的共享变量，JVM虚拟机会自动增加一个#Lock汇编指令。这个指令会根据CPU型号自动添加总线锁/缓存锁。
总线锁是锁定了CPU的前端总线，从而导致在同一时刻只能有一个线程和内存通信，这样就避免了多线程并发造成的可见性。
缓存锁是对总线锁的优化，因为总线锁导致了CPU的使用率大幅度下降，所以缓存锁只针对CPU三级缓存中的目标数据加锁。缓存锁是使用MESI缓存一致性来实现的。
指令重排序，就是指令的编写顺序和执行顺序不一致，在多线程环境下导致可见性问题。指令重排序本质上是一种性能优化的手段。
CPU层面的优化，针对MESI协议的更进一步优化去提升CPU的利用率，引入了StroreBuffer机制，而这一种优化机制会导致CPU的乱序执行。当然为了避免这样的问题，CPU提供了内存屏障指令，上层应用可以在合适的地方插入内存屏障来避免CPU指令重排序问题。
编译器的优化，编译器在编译的过程中，在不改变单线程语义和程序正确性的前提下，对指令进行合理的重排序优化来提升性能。
所以，如果对共享变量增加了volatile关键字，那么在编译器层面就不会触发编译器优化，同时在JVM里面会插入内存屏障指令拉避免重排序问题。
当然，除了volatile以外，从JDK5开始，JMM就使用了一种Happens-Before模型去描述多线程之间的内存可见性问题。
如果两个操作之间具备Happens-Before关系，那么意味着这两个操作具备可见性关系，不需要再额外去考虑增加volatile关键字来提供可见性保障。
注意📢
仅当volatile变量能简化代码的实现以及对同步策略的验证时，才应该使用它们。如果在验证正确性时需要对可见性进行复杂的判断，那么就不要使用volatile变量。
volatile变量的正确使用方式包括：确保它们自身状态的可见性，确保它们所引用对象的状态的可见性，以及标识一些重要的程序生命周期事件的发生(初始化或关闭)。
简单来说就是，写入变量值不依赖变量的当前值时。因为如果依赖当前值，将是获取-计算-写入三步操作，这三步操作不是原子性的，而volatile不保证原子性；读写变量值时没有加锁。因为加锁本身已经保证了内存可见性，这时候不需要把变量声明为volatile的。
