多线程与高并发——并发编程（2）
文章目录
- 二、并发编程的三大特性
-
- 1 原子性
-
- 1.1 什么是原子性
- 1.2 怎么保证原子性
-
- 1.2.1 synchronized
- 1.2.2 CAS
- 1.2.3 Lock 锁
- 1.2.4 ThreadLocal
- 2 可见性
-
- 2.1 什么是可见性
- 2.2 解决可见性的方式
-
- 2.2.1 volatile
- 2.2.2 synchronized
- 2.2.3 Lock
- 2.2.4 final
- 3 有序性
-
- 3.1 什么是有序性
- 3.2 as-if-serial
- 3.3 happens-before
- 3.4 volatile
二、并发编程的三大特性
1 原子性
1.1 什么是原子性
- JMM（Java Memory Model）。不同的硬件和不同的操作系统在内存上的操作有一定的差异，Java 为了解决相同代码在不同操作系统上出现的各种问题，用 JMM 屏蔽掉各种硬件和操作系统带来的差异，让 Java 的并发编程可以做到跨平台。
- JMM 规定所有变量都会存储在主内存中，在操作的时候，需要从主内存中复制一份到线程内存(CPU内存)，在线程内部做计算，然后回写到主内存中(不一定!!)
- 原子性的定义：原子性是指一个操作是不可分割的、不可中断的，一个线程在执行时，另一个线程不会影响到它。
- 并发编程的原子性用代码阐述：
private static int count;
public static void main(String[] args) throws InterruptedException {
Thread t1 = new Thread(() -> {
for (int i = 0; i < 100; i++) {
increment();
}
});
Thread t2 = new Thread(() -> {
for (int i = 0; i < 100; i++) {
increment();
}
});
t1.start();
t2.start();
t1.join();
t2.join();
System.out.println(count);
}
private static void increment() {
try {
Thread.sleep(10);
} catch (InterruptedException e) {
e.printStackTrace();
}
count++;
}
- 当前程序，多线程操作共享数据时，预期的结果与最终的结果不符。
- 原子性：多线程操作临界资源，预期结果与最终结果一致。
- 通过这个程序的分析，可以查看出，++ 操作一共分为三步：① 线程从主内存拿到数据并保存到 CPU 的寄存器中，② 在寄存器中进行 +1 操作，③ 最终将结果写回到主内存中。
1.2 怎么保证原子性
1.2.1 synchronized
- 因为 ++操作可以从指令中查看到
- 可以在方法上追加 synchronized 关键字或者采用同步代码块的形式来保证原子性。synchronized 可以避免多线程同时操作临界资源，在同一时间点，只会有一个线程正在操作临界资源。
1.2.2 CAS
什么是CAS？
- CAS 即 Compare And Swap 也就是比较和交换，是一条 CPU 的并发原语。
- 它在替换内存的某个位置的值时，首先查看内存中的值与预期值是否一致，如果一致，那么执行替换操作，这个操作是一个原子操作。
- Java中基于Unsafe类提供了对 CAS 操作的方法，JVM会帮助我们将方法实现 CAS 汇编指令。但是要清楚 CAS 只是比较和交换，在获取原值的这个操作上，需要自己实现。
private static AtomicInteger count = new AtomicInteger(0);
public static void main(String[] args) throws InterruptedException {
Thread t1 = new Thread(() -> {
for (int i = 0; i < 100; i++) {
count.incrementAndGet();
}
});
Thread t2 = new Thread(() -> {
for (int i = 0; i < 100; i++) {
count.incrementAndGet();
}
});
t1.start();
t2.start();
t1.join();
t2.join();
System.out.println(count);
}
- Doug Lea 在 CAS 的基础上帮助我们实现了一些原子类，其中就包括现在看到的 AtomicInteger，还有其他很多原子类…
- CAS的缺点：CAS 只能保证对一个变量的操作是原子性的，无法实现对多行代码实现原子性。
- CAS的问题一：ABA问题
- 可以引入版本号的方式，来解决ABA的问题，Java中提供了一个类在CAS时，针对各个版本追加版本号的操作：AtomicStampeReference。
public static void main(String[] args) throws InterruptedException {
AtomicStampedReference<String> reference = new AtomicStampedReference<>("A", 1);
String oldValue = reference.getReference();
int oldVersion = reference.getStamp();
boolean result = reference.compareAndSet(oldValue, "B", oldVersion, oldVersion + 1);
System.out.println("修改1版本的:" + result);
result = reference.compareAndSet("B", "C", 1, 2);
System.out.println("修改2版本的:" + result);
}
- CAS的问题二：自旋时间过长问题
- 可以指定CAS一共循环多少次，如果超过这个次数，直接失败、或者挂起线程（自旋锁、自适应自旋锁）
- 可以在CAS一次失败后，将这个操作暂存起来，后面需要获取结果时，将暂存操作全部执行，再返回最后的结果。比如：LongAdder。
1.2.3 Lock 锁
- Lock锁是在JDK1.5由Doug Lea研发的，它的性能相比 synchronized在JDK1.5时期，性能好了很多。但是在JDK1.6对synchronized优化之后，性能相差不大，但是如果涉及到并发比较多时， 推荐使用 ReentrantLock，性能会更好。
- 实现方式：
private static int count;
private static ReentrantLock lock = new ReentrantLock();
public static void increment() {
lock.lock();
try {
count++;
Thread.sleep(10);
} catch (InterruptedException e) {
e.printStackTrace();
} finally {
lock.unlock();
}
}
public static void main(String[] args) throws InterruptedException {
Thread t1 = new Thread(() -> {
for (int i = 0; i < 100; i++) {
increment();
}
});
Thread t2 = new Thread(() -> {
for (int i = 0; i < 100; i++) {
increment();
}
});
t1.start();
t2.start();
t1.join();
t2.join();
System.out.println(count);
}
- ReentrantLock 可以直接对比 synchronized，在功能上来说都是锁。但是 ReentrantLock 的功能性相比 synchronized 更加丰富。
- ReentrantLock 底层是基于AQS实现的，有一个基于 CAS 维护的 state 变量来实现锁的操作。
1.2.4 ThreadLocal
- Java 中的四种引用类型，分别是：强、软、弱、虚。在 Java 中最常用的就是强引用，把一个对象赋给另一个引用变量（User user = new User()），这个引用变量就是一个强引用。当一个对象被强引用变量引用时，它始终处于可达状态，它是不能被垃圾回收机制回收的，即使该对象以后永远都不会被用到，JVM也不会回收。因此，强引用时造成Java内存泄漏的主要原因之一。
- 其次是软引用（SoftReference），对于只有软引用的对象来说，当系统内存充足时不会被回收，当系统内存空间不足时被回收。软引用通常用在对内存敏感的程序中，作为缓存使用。
- 然后是弱引用，它比软引用的生存期更短，对于只有弱引用的对象来说，只要垃圾回收机制一运行，不管JVM内存是否充足，都会回收该对象占用的内存。可以解决内存泄漏问题，ThreadLocal 就是基于弱引用来解决内存泄漏问题。（针对 Entry 中的key）
- 最后是虚引用，它不能单独使用，必须和引用队列联合使用。虚引用的主要作用是跟踪对象被垃圾回收的状态，不过在开发中，我们用的更多的还是强引用。
ThreadLocal 保证原子性的方式，是不让多线程去操作临界资源，而是让每个线程去操作属于自己的数据。
- 代码实现：
static ThreadLocal tl1 = new ThreadLocal();
static ThreadLocal tl2 = new ThreadLocal();
public static void main(String[] args) throws InterruptedException {
tl1.set("123");
tl2.set("456");
Thread t1 = new Thread(() -> {
System.out.println("t1:" + tl1.get()); // null
System.out.println("t1:" + tl2.get()); // null
});
t1.start();
System.out.println("main:" + tl1.get()); // 123
System.out.println("main:" + tl2.get()); // 456
}
ThreadLocal实现原理：
- 每个线程Thread中都存储着一个成员变量，ThreadLocalMap；
- ThreadLocal本身不存储数据，它更像是一个工具类，基于 ThreadLocal 去操作 ThreadLocalMap；
- ThreadLocalMap 本身就是基于 Entry[] 实现的，因为一个线程可以绑定多个 ThreadLocal，这样一来，可能需要存储多个数据，所以采用 Entry[] 的形式实现；
- 每个线程都有自己独立的 ThreadLocalMap，再基于 ThreadLocalMap 对象本身作为 key，对 value 进行存取；
- ThreadLocalMap 的key是一个弱引用，弱引用的特点是，GC发生时必须被回收。这里是为了在 ThreadLocalMap 对象失去引用后，如果 key 的引用是强引用，会导致 ThreadLocal 对象无法被回收。
ThreadLocal 内存泄漏问题：
- 如果 ThreadLocal 引用丢失，key 因为是弱引用会被 GC 回收掉，如果同时线程还没有被回收，就会导致内存泄漏，内存中的 value 无法被回收，同时也无法被获取到。
- 解决办法：只需要在使用完毕 ThreadLocal 对象之后，及时的调用 remove 方法，移除 Entry 即可。
2 可见性
2.1 什么是可见性
可见性问题是基于 CPU 位置出现的，CPU 处理速度非常快，相对CPU而言，去主内存获取数据这个事情太慢了，CPU提供了 L1、L2、L3 三级缓存，每次去主内存拿完数据后，就会存储到 CPU 的三级缓存，每次去三级缓存拿数据，效率肯定会提升。
但这就带来问题，现在CPU都是多核，每个线程的工作内存（CPU三级缓存）都是独立的， 会告知每个线程中做修改时，只改自己的工作内存，没有及时的同步到主内存中，导致数据不一致的问题。
- 可见性问题的代码逻辑：
private static boolean flag = true;
public static void main(String[] args) throws InterruptedException {
Thread t1 = new Thread(() -> {
while (flag) {
// ...
}
System.out.println("t1线程结束");
});
t1.start();
Thread.sleep(10);
flag = false;
System.out.println("主线程将flag改为false");
}
2.2 解决可见性的方式
2.2.1 volatile
volatile 是一个关键字，用来修饰成员变量。如果属性被 volatile 修改，相当于会告诉CPU，对当前属性的操作，不允许使用CPU缓存，必须去主内存操作。
volatile的内存语义：
- volatile属性被写：当写一个volatile变量时，JMM会将当前线程对应的 CPU 缓存及时的刷新到主内存中；
- volatile属性被读：当读一个volatile变量时，JMM会将对应的CPU缓存中的内存设置为无效，必须去主内存中重新读取共享变量。
其实加了volatile就是告诉CPU，对当前属性的读写操作，不允许使用 CPU 缓存，加了 volatile 修饰的属性，会在转为汇编指令后，追加一个 lock 的前缀，CPU执行这个指令时，对于带有 lock 前缀的会做两个事情：
- 将当前处理缓存行的数据写回到主内存；
- 这个写回的数据，在其他CPU内行的缓存中，直接无效。
总结：volatile就是让 CPU 每次操作这个数据时，必须立即同步到主内存，以及从主内存读取数据。
private volatile static boolean flag = true;
public static void main(String[] args) throws InterruptedException {
Thread t1 = new Thread(() -> {
while (flag) {
// ...
}
System.out.println("t1线程结束");
});
t1.start();
Thread.sleep(10);
flag = false;
System.out.println("主线程将flag改为false");
}
2.2.2 synchronized
synchronized也可以解决可见性问题，synchronized的内存语义：
- 如果涉及到 synchronized 的同步代码块或者同步方法，获取锁资源之后，将内部涉及到的变量从 CPU 缓存中移除，必须去主内存中重新拿数据；而且在释放锁之后，会立即将CPU缓存中的数据同步到主内存。
private static boolean flag = true;
public static void main(String[] args) throws InterruptedException {
Thread t1 = new Thread(() -> {
while (flag) {
synchronized (MyTest.class) {
// ...
}
// System.out.println(); // 打印方法内部也使用了synchronized
}
System.out.println("t1线程结束");
});
t1.start();
Thread.sleep(10);
flag = false;
System.out.println("主线程将flag改为false");
}
2.2.3 Lock
Lock锁保证可见性的方式和 synchronized完全不同，synchronized基于它的内存语义，在获取锁和释放锁时，对CPU缓存做了一个同步到主内存的操作。
Lock锁时基于volatile实现的，Lock锁内部再进行加锁和释放锁时，会对一个由volatile修饰的state属性进行加减操作。
如果对volatile修饰的属性进行写操作，CPU会执行带有lock前缀的指令，CPU会降修改后的数据，从CPU缓存立即同步到主内存，同时也会将其他属性也立即同步到主内存中。还会降其他CPU缓存行中的这个数据设置为无效，必须重新去主内存中拉取。
private static boolean flag = true;
private static Lock lock = new ReentrantLock();
public static void main(String[] args) throws InterruptedException {
Thread t1 = new Thread(() -> {
while (flag) {
lock.lock();
try {
// ...
} finally {
lock.unlock();
}
}
System.out.println("t1线程结束");
});
t1.start();
Thread.sleep(10);
flag = false;
System.out.println("主线程将flag改为false");
}
2.2.4 final
final修饰的属性，在运行期间是不允许修改的，这样一来，就间接保证了可见性，所有多线程读取 final 属性，值肯定是一样的。
final并不是说每次取数据从主内存读取，也没这个必要，而且final和volatile不允许同时修饰一个变量。
final修饰的内容已经不允许再次别写了，而 volatile 是保证每次读写数据去主内存读取，并且volatile会影响一定的性能，就不需要同时修饰。
3 有序性
3.1 什么是有序性
在Java中，.java 文件中的内容会被编译，在执行前需要再次转为 CPU 可以识别的指令，CPU在执行这些指令时，为了提升执行效率，在不影响最终结果的前提下（满足一下要求），会对指令进行重排。
指令乱序执行的原因，是为了尽可能的发挥 CPU 的性能。Java 中的程序是乱序执行的，验证乱序执行效果：
static int a, b, x, y;
public static void main(String[] args) throws InterruptedException {
for (int i = 0; i < Integer.MAX_VALUE; i++) {
a = 0;
b = 0;
x = 0;
y = 0;
Thread t1 = new Thread(() -> {
a = 1;
x = b;
});
Thread t2 = new Thread(() -> {
b = 1;
y = a;
});
t1.start();
t2.start();
t1.join();
t2.join();
if (x == 0 && y == 0) {
System.out.println("第" + i + "次，x = " + x + ", y = " + y);
}
}
}
DCL 单例模式由于指令重排序可能出现问题：线程可能会拿到没有初始化的对象，导致在使用时，由于内部属性为默认值，导致出现一些不必要的问题：
public class MyTest {
private static volatile MyTest test;
private MyTest() {}
public static MyTest getInstance() {
// B
if (test == null) {
synchronized (MyTest.class) {
if (test == null) {
// A: 开辟空间、test指向地址、初始化
test = new MyTest();
}
}
}
return test;
}
}
3.2 as-if-serial
as-if-serial语义：不论指令如何重排序，需要保证单线程的程序执行结果是不变的。而且如果存在依赖关系，那么也不可以做指令重排。
// 这种情况肯定不能做指令重排
int i = 0;
i++;
// 这种情况肯定不能做指令重排序
int j = 200;
j * 100;
j + 100;
// 这里即便出现了指令重排，也不可以影响最终的结果，20100
3.3 happens-before
具体规则：
- 单线程happen-before原则：在同一个线程中，书写在前面的操作happen-before后面的操作。
- 锁的happen-before原则：同一个锁的unlock操作happen-before此锁的lock操作。
- volatile的happen-before原则： 对一个volatile变量的写操作happen-before对此变量的任意操作。
- happen-before的传递性原则： 如果A操作 happen-before B操作，B操作happen-before C操作，那么A操作happen-before C操作。
- 线程启动的happen-before原则：同一个线程的start方法happen-before此线程的其它方法。
- 线程中断的happen-before原则：对线程interrupt方法的调用happen-before被中断线程的检测到中断发送的代码。
- 线程终结的happen-before原则：线程中的所有操作都happen-before线程的终止检测。
- 对象创建的happen-before原则：一个对象的初始化完成先于他的finalize方法调用。
**JMM 只有不出现上述 8 种情况时，才不会触发指令重排效果。**不需要过分的关注happens-before原则，只需要可以写出线程安全的代码就可以了。
3.4 volatile
如果需要让程序对某一个属性的操作不出现指令重排，除了满足 happens-before 原则之外，还可以基于 volatile 修饰属性，从而对这个属性的操作，就不会出现指令重排问题。
volatile如何实现的禁止指令重排？
- 内存屏障概念，可以将内存屏障看成一条指令。
- volatile会在两个操作之间，添加一道指令，这个指令就可以避免上下执行的其它指令进行重排序。