volatile和synchronized特点 首先需要理解线程安全的两个方面：
- 执行控制
- 内存可见。
执行控制的目的是控制代码执行（顺序）及是否可以并发执行。 内存可见控制的是线程执行结果在内存中对其它线程的可见性。根据Java内存模型的实现，线程在具体执行时，会先拷贝主存数据到线程本地（CPU缓存），操作完成后再把结果从线程本地刷到主存。
volatile基本介绍:
volatile可以看成是synchronized的一种轻量级的实现，但volatile并不能完全代替synchronized，volatile有synchronized可见性的特性，但没有synchronized原子性的特性。可见性即用volatile关键字修饰的成员变量表明该变量不存在工作线程的副本，线程每次直接都从主内存中读取，每次读取的都是最新的值，这也就保证了变量对其他线程的可见性。另外，使用volatile还能确保变量不能被重排序，保证了有序性。
volatile比synchronized编程更容易且开销更小，但具有一点的使用局限性，使用要相当小心，不能当锁使用。volatile不会像synchronized一样阻塞程序，如果是读操作远多于写操作的情况可以建议使用volatile，它会有更好的性能。
Java volatile关键字:
volatile解决的问题是多个线程的内存可见性问题，在并发环境下，每个线程都会有自己的工作空间，每个线程只能访问各自的工作空间，而一些共享变量会被加载到每个线程的工作空间中，所以这里面就有一个问题，内存中的数据什么时候被加载到线程的工作缓存中，而线程工作空间中的内容什么时候会回写到内存中去。这两个步骤处理不当就会造成内存可加性问题，也就是数据的不一致，比如某个共享变量被线程A修改了，但是没有回写到内存中去，而线程B在加载了内存中的数据之后读取到的共享变量是脏数据，正确的做法应该是线程A的修改应该对线程B是可见的，更为通用一些，就是在并发环境下共享变量对多个线程是一致的。
对于内存可见性的一点补充是，之所以会造成多个线程看到的共享变量的值不一样，是因为线程在占用CPU时间的时候，cpu为了提高处理速度不会直接和内存交互，而是会先将内存中的共享内容读取到内部缓存中（L1，L2），然后cpu在处理的过程中就只会和内部缓存交互，在多核心的机器中这样的处理方式就会造成内存可见性问题。
volatile可以解决并发环境下的内存可见性问题，只需要在共享变量前面加上volatile关键字就可以解决，但是需要说明的是，volatile仅仅是解决内存可见性问题，对于像i++这样的问题还是需要使用其他的方式来保证线程安全。使用volatile解决内存可见性问题的原理是，如果对被volatile修饰的共享变量执行写操作的话，JVM就会向cpu发送一条Lock前缀的指令，cpu将会这个变量所在的缓存行（缓存中可以分配的最小缓存单位）写回到内存中去。但是在多处理器的情况下，将某个cpu上的缓存行写回到系统内存之后，其他cpu上该变量的缓存还是旧的，这样再进行后面的操作的时候就会出现问题，所以为了使得所有线程看到的内容都是一致的，就需要实现缓存一致性协议，cpu将会通过监控总线上传递过来的数据来判断自己的缓存是否过期，如果过期，就需要使得缓存失效，如果cpu再来访问该缓存的时候，就会发现缓存失效了，这时候就会重新从内存加载缓存。
总结一下，volatile的实现原则有两条：
1、JVM的Lock前缀的指令将使得cpu缓存写回到系统内存中去
2、为了保证缓存一致性原则，在多cpu的情景下，一个cpu的缓存回写内存会导致其他的cpu上的缓存都失效，再次访问会重新从系统内存加载新的缓存内容。
共享对象的可见性
当多个线程同时操作同一个共享对象时，如果没有合理的使用volatile和synchronization关键字，一个线程对共享对象的更新有可能导致其它线程不可见。
想象一下我们的共享对象存储在主存，一个CPU中的线程读取主存数据到CPU缓存，然后对共享对象做了更改，但CPU缓存中的更改后的对象还没有flush到主存，此时线程对共享对象的更改对其它CPU中的线程是不可见的。最终就是每个线程最终都会拷贝共享对象，而且拷贝的对象位于不同的CPU缓存中。
下图展示了上面描述的过程。左边CPU中运行的线程从主存中拷贝共享对象obj到它的CPU缓存，把对象obj的count变量改为2。但这个变更对运行在右边CPU中的线程不可见，因为这个更改还没有flush到主存中：
要解决共享对象可见性这个问题，我们可以使用java volatile关键字。 Java’s volatile keyword. volatile 关键字可以保证变量会直接从主存读取，而对变量的更新也会直接写到主存。volatile原理是基于CPU内存屏障指令实现的，后面会讲到。
竞争现象
如果多个线程共享一个对象，如果它们同时修改这个共享对象，这就产生了竞争现象。
如下图所示，线程A和线程B共享一个对象obj。假设线程A从主存读取Obj.count变量到自己的CPU缓存，同时，线程B也读取了Obj.count变量到它的CPU缓存，并且这两个线程都对Obj.count做了加1操作。此时，Obj.count加1操作被执行了两次，不过都在不同的CPU缓存中。
如果这两个加1操作是串行执行的，那么Obj.count变量便会在原始值上加2，最终主存中的Obj.count的值会是3。然而下图中两个加1操作是并行的，不管是线程A还是线程B先flush计算结果到主存，最终主存中的Obj.count只会增加1次变成2，尽管一共有两次加1操作。
要解决上面的问题我们可以使用java synchronized代码块。synchronized代码块可以保证同一个时刻只能有一个线程进入代码竞争区，synchronized代码块也能保证代码块中所有变量都将会从主存中读，当线程退出代码块时，对所有变量的更新将会flush到主存，不管这些变量是不是volatile类型的。
内存屏障（Memory Barrier ）
上面讲到了，通过内存屏障可以禁止特定类型处理器的重排序，从而让程序按我们预想的流程去执行。内存屏障，又称内存栅栏，是一个CPU指令，基本上它是一条这样的指令：
保证特定操作的执行顺序。
影响某些数据（或则是某条指令的执行结果）的内存可见性。
编译器和CPU能够重排序指令，保证最终相同的结果，尝试优化性能。插入一条Memory Barrier会告诉编译器和CPU：不管什么指令都不能和这条Memory Barrier指令重排序。
Memory Barrier所做的另外一件事是强制刷出各种CPU cache，如一个Write-Barrier（写入屏障）将刷出所有在Barrier之前写入 cache 的数据，因此，任何CPU上的线程都能读取到这些数据的最新版本。
这和java有什么关系？上面java内存模型中讲到的volatile是基于Memory Barrier实现的。
如果一个变量是volatile修饰的，JMM会在写入这个字段之后插进一个Write-Barrier指令，并在读这个字段之前插入一个Read-Barrier指令。这意味着，如果写入一个volatile变量，就可以保证：
一个线程写入变量a后，任何线程访问该变量都会拿到最新值。
在写入变量a之前的写入操作，其更新的数据对于其他线程也是可见的。因为Memory Barrier会刷出cache中的所有先前的写入。
参考
https://blog.csdn.net/suifeng3051/article/details/52611310
https://www.cnblogs.com/wk-missQ1/p/12889974.html
