在并发编程中，我们通常会遇到以下三个问题：原子性问题，可见性问题，有序性问题。
1、原子性 -对应 AQS 原子操作
即一个操作或者多个操作，要么全部执行并且执行的过程不会被任何因素打断，要么就都不执行。
一个很经典的例子就是银行账户转账问题：
比如从账户 A 向账户 B 转 1000 元，那么必然包括 2 个操作：从账户 A 减去 1000 元，往账户 B 加上 1000 元。试想一下，如果这 2 个操作不具备原子性，会造成什么样的后果。假如从账户 A 减去 1000 元之后，操作突然中止。然后又从 B 取出了 500 元，取出 500 元之后，再执行 往账户 B 加上 1000 元 的操作。这样就会导致账户 A 虽然减去了 1000 元，但是账户 B 没有收到这个转过来的 1000 元。
所以这 2 个操作必须要具备原子性才能保证不出现一些意外的问题。
同样地反映到并发编程中会出现什么结果呢？举一个简单的例子：
i = 0; //1
j = i ; //2
i++; //3
i = j + 1; //4
上面四个操作，有哪个几个是原子操作，那几个不是？如果不是很理解，可能会认为都是原子性操作，其实只有 1 才是原子操作，其余均不是。
1在Java中，对基本数据类型的变量和赋值操作都是原子性操作；
2中包含了两个操作：读取i，将i值赋值给j
3中包含了三个操作：读取i值、i + 1 、将+1结果赋值给i；
4中同三一样
在单线程环境下我们可以认为整个步骤都是原子性操作，但是在多线程环境下则不同，Java 只保证了基本数据类型的变量和赋值操作才是原子性的（注：在 32 位的 JDK 环境下，对 64 位数据的读取不是原子性操作，如 long、double）。
要想在多线程环境下保证原子性，则可以通过锁、synchronized 来确保。volatile 是无法保证复合操作的原子性。
Java 中的 CAS 机制只能保证共享变量操作的原子性，而不能保证代码块的原子性。（锁的粒度）
粒度越小，性能越高，若要锁代码块，就用 synchronized，锁升级（偏向锁）-》对变量 CAS-》对代码块 synchronized 重量级锁）
加锁虽然有了安全性，但是必然会导致性能下降，为了性能，优化锁：1. 锁的粒度，比如轻量级锁、重量级锁 2. 锁的阻塞等待：有些线程多次进入，优先分配如偏向锁，自旋锁、可重入锁、公平锁非公平锁 3. 锁的切换需要导致上下文切换，消耗性能，这部分无法解决
JAVA 多线程，面试官喜欢问的东西 “CAS 和 AQS”
2、可见性 - -对应锁、ThreadLocal相关知识
可见性是指当多个线程访问同一个变量时，一个线程修改了这个变量的值，其他线程能够立即看得到修改的值。
举个简单的例子，看下面这段代码：
//线程1执行的代码
int i = 0;
i = 10;
//线程2执行的代码
j = i;
假若执行线程 1 的是 CPU1，执行线程 2 的是 CPU2。由上面的分析可知，当线程 1 执行 i = 10 这句时，会先把 i 的初始值加载到 CPU1 的高速缓存中，然后赋值为 10，那么在 CPU1 的高速缓存当中 i 的值变为 10 了，却没有立即写入到主存当中。此时线程 2 执行 j = i，它会先去主存读取 i 的值并加载到 CPU2 的缓存当中，注意此时内存当中 i 的值还是 0，那么就会使得 j 的值为 0，而不是 10。这就是可见性问题，线程 1 对变量 i 修改了之后，线程 2 没有立即看到线程 1 修改的值。
在上面已经分析了，在多线程环境下，一个线程对共享变量的操作对其他线程是不可见的。
对于可见性，Java 提供了 volatile 关键字来保证可见性。当一个共享变量被 volatile 修饰时，它会保证修改的值会立即被更新到主存，当有其他线程需要读取时，它会去内存中读取新值。而普通的共享变量不能保证可见性，因为普通共享变量被修改之后，什么时候被写入主存是不确定的，当其他线程去读取时，此时内存中可能还是原来的旧值，因此无法保证可见性。
另外，通过 synchronized 和 Lock 也能够保证可见性，synchronized 和 Lock 能保证同一时刻只有一个线程获取锁然后执行同步代码，并且在释放锁之前会将对变量的修改刷新到主存当中。因此可以保证可见性。
3、有序性
即程序执行的顺序按照代码的先后顺序执行。
举个简单的例子，看下面这段代码：
int i = 0;
boolean flag = false;
i = 1; //语句1
flag = true; //语句2
上面代码定义了一个 int 型变量，定义了一个 boolean 类型变量，然后分别对两个变量进行赋值操作。从代码顺序上看，语句 1 是在语句 2 前面的，那么 JVM 在真正执行这段代码的时候会保证语句 1 一定会在语句 2 前面执行吗？不一定，为什么呢？这里可能会发生指令重排序（Instruction Reorder）。
下面解释一下什么是指令重排序，一般来说，处理器为了提高程序运行效率，可能会对输入代码进行优化，它不保证程序中各个语句的执行先后顺序同代码中的顺序一致，但是它会保证程序最终执行结果和代码顺序执行的结果是一致的。
比如上面的代码中，语句 1 和语句 2 谁先执行对最终的程序结果并没有影响，那么就有可能在执行过程中，语句 2 先执行而语句 1 后执行。但是要注意，虽然处理器会对指令进行重排序，但是它会保证程序最终结果会和代码顺序执行结果相同，那么它靠什么保证的呢？再看下面一个例子：
int a = 10; //语句1
int r = 2; //语句2
a = a + 3; //语句3
r = a*a; //语句4
这段代码有 4 个语句，那么可能的一个执行顺序是：
语句 2 → 语句 1 → 语句 3 → 语句 4
那么可不可能是这个执行顺序：
语句 2 → 语句 1 → 语句 4 → 语句 3。
不可能，因为处理器在进行重排序时是会考虑指令之间的数据依赖性，如果一个指令 Instruction 2 必须用到 Instruction 1 的结果，那么处理器会保证 Instruction 1 会在 Instruction 2 之前执行。虽然重排序不会影响单个线程内程序执行的结果，但是多线程呢？下面看一个例子：
//线程1:
context = loadContext(); //语句1
inited = true; //语句2
//线程2:
while(!inited ){
sleep()
}
doSomethingwithconfig(context);
上面代码中，由于语句 1 和语句 2 没有数据依赖性，因此可能会被重排序。假如发生了重排序，在线程 1 执行过程中先执行语句 2，而此是线程 2 会以为初始化工作已经完成，那么就会跳出 while 循环，去执行 doSomethingwithconfig(context) 方法，而此时 context 并没有被初始化，就会导致程序出错。
从上面可以看出，指令重排序不会影响单个线程的执行，但是会影响到线程并发执行的正确性。也就是说，要想并发程序正确地执行，必须要保证原子性、可见性以及有序性。只要有一个没有被保证，就有可能会导致程序运行不正确。
在 Java 内存模型中，允许编译器和处理器对指令进行重排序，但是重排序过程不会影响到单线程程序的执行，却会影响到多线程并发执行的正确性。
在 Java 里面，可以通过 volatile 关键字来保证一定的 “有序性”。另外可以通过 synchronized 和 Lock 来保证有序性，很显然，synchronized 和 Lock 保证每个时刻是有一个线程执行同步代码，相当于是让线程顺序执行同步代码，自然就保证了有序性。另外，Java 内存模型具备一些先天的 “有序性”，即不需要通过任何手段就能够得到保证的有序性，这个通常也称为 happens-before 原则。如果两个操作的执行次序无法从 happens-before 原则推导出来，那么它们就不能保证它们的有序性，虚拟机可以随意地对它们进行重排序。