可见性问题的原因：
1.JVM内存结构：
JVM的内存结构分为主内存（heap）和工作区内存。
主内存可以存放多线程共享的变量，尽管如此，处于cpu运行效率的考虑，多线程执行的时候对于用到的共享变量，会在工作区内存中保存各自的副本，不同线程是无法直接访问之间的工作区内存的，线程间数据的通讯只能通过主内存。这就是多线程可见性问题的根源。
2.JIT（编译器）优化：
jvm其实并不是完全的编译型脚本，java代码的编译过程如下：
1）先经过编译器编译
2）jvm通过loader加载到内存中对编译后的指令解释执行，遇到2种情况会对部分指令重排序（即重编译）：
- 多次循环
- 反复调用
策略大致就是类似先把赋值指令放到前面。
在多线程情况下就会可能遇到A线程对主内存的变量赋值了，但是因为指令重排序，B线程早已执行过都读取变量操作，导致2个线程中变量值没有同步。
可见性解决方案：
synchronized修饰变量读写的代码块。
使用lock，lock和synchronized本质都是通过锁的机制先限制并发行，然后根据规则【对一个变量执行unlock操作之前，必须先把此变量同步回主内存中(执行store和write操作)】保证了数据的可见性。
final修饰的属性：final修饰的属性不允许重排序，只能在初始化的时候赋值。
对变量使用volatile修饰符，volatile修饰符读取变量时，会强制从主内存中读取，同时在更改了变量时，强制要求回写回主内存。
使用J.U.C（Java.util.concurrent）并发编程包。
原子操作：
在多线程并发操作的时候，即使对变量加了volatile，结果还是达不到预期，下面有个例子：
好吧，最终结果非常玄幻...
为什么会这样，因为多线程在取值，计算，更新值的过程中原子性被破坏。所谓原子性，是要求在整个执行过程中，变量没有发生变化。从上例来看，有些操作太快结果被慢的线程覆盖掉了。通俗点说，菜要一道一道的做，不能因为着急上一道菜还没出锅就直接开始炒下一盘。
解决方案：
解决这个问题首先想到的就是加锁。
利用CAS机制：Compare And Swap ,原理就是先读取后计算，然后再回来写数据的时候要先判断原变量值是否被更改，没有改过就把计算结果写入。
sun.misc.unsafe类中提供了一系列方法如compareAndSwapInt()、compareAndSwapLong()等实现了CAS（cpu硬件本身就支持这种操作）。使用需要传2个值，一个是旧值，另一个是需要替换的值。jvm不推荐直接使用这些api，在处理并发计算型任务还是应该使用J.U.C。J.U.C提供了很多封装的类型，例如AtomicInteger、AtomicArray，核心原理其实还是CAS。
CAS的原理就是操作前先记录变量的值，等处理完了要update之前先看看这个变量有没有被更改，没有则更新这个变量，有更改则不更新。
CAS的问题：
1）我们如果使用循环+CAS的方式实现的第一个问题是，自旋意味着线程一直处于争抢cup资源的状态，容易对CPU资源造成浪费。
2）CAS只能针对一个变量操作，不能用于多变量的原子操作，实用性不太好。
3）最严重的问题是ABA问题：ABA问题的原因是对同一个变量的操作不同线程速率是不一样的，有可能线程A读到变量并处理的过程中，线程B已经对此变量做过多次读写，虽然变量A开始写入结果的时候CAS检查并没有问题，但是实际上这个变量确实已经变化过了。我们通常使用的共享资源很多都是引用类型，经历了ABA的对象谁能保证还是当初的那个对象呢~
ABA问题是使用CAS机制伴随的问题，解决办法是使用AtomicMarkableReference或者AtomicStampedReference，前者内部加入了一个boolean类型的标记，用来判断当前CAS操作是否是最新，后者内部加入了int类型的版本号，同样用来判断当前操作是否是最新的。
关于线程安全还是不安全场景：
多线程更新共享资源的时候才可能出现线程安全问题，单线程不存在线程安全问题。
栈封闭时，不会在线程之间共享的变量都是线程安全的。
局部对象在栈内存的是引用，其实还是存在主内存区里，如果对象只在方法内传递，不共享使用，那么也是线程安全的。
ThreadLocal本身不存在线程安全问题，因为不同线程使用的是不同的资源，本身操作的资源是自己的副本。
参考文章：
https://zhuanlan.zhihu.com/p/31505222?from_voters_page=true
https://blog.csdn.net/qq_33394088/article/details/78657141
