并发编程实战(一)
并发编程的三个核心问题:
- 分工 : 高效的拆解任务分给线程
- 同步 : 线程之间的协作
- 互斥 : 保证同一时刻只允许一个线程访问共享资源
这个其实不难理解,做个简单的比喻,我们团队做一个项目的时候肯定是先分配任务(分工),然后等到任务完成进行合并对接(同步),在开发过程中,使用版本控制工具访问,一个代码只能被一个人修改,否则会报错,需要meger(互斥).
学习攻略:
- 跳出来,看全景
- 钻进去,看本质
核心: 分工(拆分) - 同步(一个线程执行完成如何通知后续任务的线程开始工作) - 互斥(同一时刻,只允许一个线程访问共享变量)
全景:
本质 : 知其然知其所以然,有理论做基础.技术的本质是背后的理论模型
并发编程为啥好难?
我从我的角度看,一个是并发编程的API不是很了解,第二个就是出现了问题不会解决,如果说还有,那就是是在不知道并发编程是用来干啥的?有什么用?
每一中技术的出现都有他出现的必然性,对于并发来说无疑是提高性能,那单线程为啥就不能提高性能,原因就在于CPU,内存和IO设备三者的速度差异太大,举个例子来说: CPU一天,内存一年,IO一百年; 而木桶理论告诉我们程序的性能是由短板决定,所以只要合理的平衡三者的速度差异,就可以提高性能.
并发编程问题的源头
- 缓存导致的可见性: 对于单CPU来说,缓存是可见的,也就是说多个线程同时操作,CPU会从内存读取数据,线程更新数据到CPU,CPU写入内存,线程和CPU进行交互,这个操作每个线程之间是可见的.
但是对于多CPU来说,多个线程操作不同的CPU,不同的CPU操作同一个内存,这会导致操作的不可见性,就出现了问题.(说下可见性的概念: 一个线程对共享变量的修改,另一个线程能够立刻看到,这就是可见性) - 线程切换带来的原子性问题: 原子性是一个或多个操作在CPU执行的过程中不被中断的特性. 那为什么会中断呢?原因就在于提高性能,就和现在的计算机一样,是分时间片来进行任务切换,同时听歌和敲代码,看似是同时发生,其实不是,知识任务之间切换的非常快,做到了看似同时进行.
在高级程序中,一个看似简单的操作可能需要多条CPU指令来完成,不如说count += 1;CPU指令至少三个,从内存中拿到count值到寄存器,在寄存器中进行加一操作,将结果写入内存,这个过程中可能会发生任务间的切换,比如说另一个线程在写入内存前有进行了一次++操作,这个时候结果就不是想要的结果了,可能例子不合适,但是这个意思就是这个. 而原子性就是保证高级语言层面保证操作的原子性. - 编译优化的有序性问题: 有序性指的是程序按照代码的先后顺序执行. 看起来没问题,本来就应该这样,其实不然,在JVM的知识中有一个叫重排序,就是编译器为了优化性能,有时会改变程序中语句的先后顺序,大部分情况下编译器调整后的顺序是不会影响程序的最终结果,不过也有特殊情况,如下:
public class Singleton {
static Singleton instance;
static Singleton getInstance(){
if (instance == null) {
synchronized(Singleton.class) {
if (instance == null)
instance = new Singleton();
}
}
return instance;
}
}
上面是经典的双重检查创建单例对象,在我们的印象中new的操作应该是: 分配内存,在内存上初始化对象,地址赋值. 实际上优化后是: 分配内存,地址赋值,初始化. 优化后的顺序就会出现问题,地址赋值后发生了线程切换,这时候其他线程读取到了对象不为null,但是实际上只有地址,这个时候访问成员变量就会出现空指针异常,这个就是编译优化可能会出现的问题.
也就是说,很多的并发Bug是由可见性,原子性,有序性的原理造成的,从这三个方面去考虑,可以理解诊断很大部分一部分Bug. 缓存导致可见性问题,线程切换带来的原子性,编译优化带来的有序性,本质都是提高程序性能,但是在带来性能的时候可能也会出现其他问题,所以在运用一项技术的时候一定要清楚它带来的问题是什么,以及如何实现.
Java内存模型: 解决可见性和有序性问题
可见性的原因是缓存,有序性的原因是编译优化,那解决的最直接的办法就是禁用缓存和编译优化,但是有缓存和编译优化的目的是提高程序性能,禁用了程序的性能如何保证? 合理的方案是按需禁用缓存和编译优化,Java内存模型规范了JVM如何提供按需禁用缓存和编译优化的方法,具体的,这些方法包括volatile,synchronized和final三个关键字,以及六项Happens-Before规则
volatile的困惑
volatile关键字用来声明变量,告诉编译器这个变量的读写不能使用CPU缓存,必须从内存中读写.
// 以下代码来源于【参考 1】
class VolatileExample {
int x = 0;
volatile boolean v = false;
public void writer() {
x = 42;
v = true;
}
public void reader() {
if (v == true) {
// 这里 x 会是多少呢？
}
}
}
上面的代码x的值是多少呢?直觉上应该是42,但是在jdk1.5之前,可能的值是0或者42,1.5之后就是42,为什么?原因是变量x可能被CPU缓存而导致可见性问题,也就是x=42可能不被v=true可见,那Java的内存模型在1.5版本之后是如何解决的呢? 就是Happens-before规则.
Happens-Before规则
Happens-before指的是前一个操作的结果对后续操作是可见的,具体如下.
1. 程序的顺序性规则
这个规则说的是在一个线程中,按照程序顺序,前面的操作Happens-Before于后续的任意操作. 简单理解就是: 程序前面对于某个变量的修改一定是对后续操作可见的.也就是前面的代码x=42对于v=true是可见的.
2. volatile变量规则
这条规则指的是对一个volatile变量的写操作,Happens-Before于后续对这个volatile变量的读操作,即volatile变量的写操作对于读操作是可见的.
3. 传递性
这条规则指的是A Happens-Before C,且B Happens-Before C,那么A Happens-Before C,如下图:
这样就很明显了,x=42 Happens-Before v=true,写v=true Happens-Before 读v=true,那也就是说x=42 Happens Before 读v=true,这样下来,其他线程就可以看到x=42这个操作了.
4. 管程中锁的规则
这个规则是指对一个锁的解锁Happens-Before与后续对这个锁的加锁. 管程是一种通用的同步原语,在Java中指的就是synchronized,synchronized是Java里对管程的实现.管程中的锁在Java中是隐式实现的,也就是进入同步块之前,会自动加锁,而在代码块执行完后自动释放锁,加锁以及解锁都是编译器帮我们实现的.
synchronized (this) { // 此处自动加锁
// x 是共享变量, 初始值 =10
if (this.x < 12) {
this.x = 12;
}
} // 此处自动解锁
5. 线程start()规则
这个是线程启动的,指的是主线程A启动子线程B,子线程B能够看到主线程在启动子线程B前的操作.
Thread B = new Thread(()->{
// 主线程调用 B.start() 之前
// 所有对共享变量的修改，此处皆可见
// 此例中，var==77
});
// 此处对共享变量 var 修改
var = 77;
// 主线程启动子线程
B.start();
6. 线程join()规则
这条规则是关于线程等待的.它是指主席爱能成A通过调用子线程B的join方法,子线程B执行完成之后,主线程可以看到子线程中的操作.这里指的是对共享变量的操作.
Thread B = new Thread(()->{
// 此处对共享变量 var 修改
var = 66;
});
// 例如此处对共享变量修改，
// 则这个修改结果对线程 B 可见
// 主线程启动子线程
B.start();
B.join()
// 子线程所有对共享变量的修改
// 在主线程调用 B.join() 之后皆可见
// 此例中，var==66
Final
final修饰变量是告诉编译器: 这个变量生而不变,可以可劲儿优化.在 1.5 以后 Java 内存模型对 final 类型变量的重排进行了约束。现在只要我们提供正确构造函数没有“逸出”，就不会出问题了。下面的例子,在构造函数里将this赋值给全局变量global.obj,这就是逸出(逸出就是对象还没有构造完成,就被发布出去),线程global.obj读取到x有可能读到0.
// 以下代码来源于【参考 1】
final int x;
// 错误的构造函数
public FinalFieldExample() {
x = 3;
y = 4;
// 此处就是讲 this 逸出，
global.obj = this;
}
在 Java 语言里面，Happens-Before 的语义本质上是一种可见性，A Happens-Before B 意味着 A 事件对 B 事件来说是可见的，无论 A 事件和 B 事件是否发生在同一个线程里。例如 A 事件发生在线程 1 上，B 事件发生在线程 2 上，Happens-Before 规则保证线程 2 上也能看到 A 事件的发生。
互斥锁: 解决原子性问题
前面看了Java的内存模型,解决了可见性和编译优化的重排序问题,哪还有一个原子性如何解决?答案就是使用互斥锁实现.
先探究源头,long在32位机器上操作可能出现Bug,原因是线程的切换,那只要保证同一时刻只有一个线程执行,就可以了,这就是互斥.
互斥锁模型:
Java中如何实现这种互斥锁呢?
Java语言提供的锁技术: synchronized
java中的synchronized关键字就是锁的一种实现,synchronized关键字可以用来修饰方法,也可以用来修饰代码块,如下:
class X {
// 修饰非静态方法
synchronized void foo() {
// 临界区
}
// 修饰静态方法
synchronized static void bar() {
// 临界区
}
// 修饰代码块
Object obj = new Object()；
void baz() {
synchronized(obj) {
// 临界区
}
}
}
先说一下那个加锁和释放锁,synchronized并没有显示的进行这一操作,而是编译器会在synchronized修饰的方法或代码块前后自动加锁lock()和解锁unlock(),不需要编程人员手动加锁和释放锁(省的忘记,程序员很忙的).
synchronized锁的规则是什么: 当修饰静态方法的时候,锁定的是当前的类对象. 修饰非静态方法和代码块的时候,锁定的是当前的对象this.如下
class X {
// 修饰静态方法
synchronized(X.class) static void bar() {
// 临界区
}
}
class X {
// 修饰非静态方法
synchronized(this) void foo() {
// 临界区
}
}
案例深入理解:
下面的代码可以解决多线程问题吗?
class SafeCalc {
long value = 0L;
long get() {
return value;
}
synchronized void addOne() {
value += 1;
}
}
答案是并不可以,原因是虽然对addOne进行了加锁操作(对一个锁的解锁Happens-Before于后续对这个锁的加锁),保证了后续addOne的操作的共享变量是可以看到前面addOne操作后的共享变量的值,但是get方法却没有,多个线程get方法可能获取到的值相同,addOne()之后就会乱套,所以并不能解决.那下面的代码可以解决问题吗?
class SafeCalc {
long value = 0L;
synchronized long get() {
return value;
}
synchronized void addOne() {
value += 1;
}
}
这种是可以解决多线程问题,也就是可以解决多个线程操作同一个对象的并发问题.那如果要解决多个线程操作不同对象的并发问题呢?
锁和受保护资源的关系
受保护资源和锁之间的关联关系是N:1的关系.也就是说一个锁可以保护多个受保护的资源,这个就是现实生活中的包场,但是我觉得这个也要分情况,多个受保护的资源和锁之间一定要有关系,不然锁不起作用就麻烦了,举个例子来说就是自己家门的锁肯定保护自己东西,不能用自己家门的锁去保护别人家的东西.
下面的例子:
class SafeCalc {
static long value = 0L;
synchronized long get() {
return value;
}
synchronized static void addOne() {
value += 1;
}
}
分析如图:
所以说addOne对value的修改对临界区get()没有可见性保证,会导致并发问题.将get方法也改为静态的就可以解决了.
synchronized 是 Java 在语言层面提供的互斥原语，其实 Java 里面还有很多其他类型的锁，但作为互斥锁，原理都是相通的：锁，一定有一个要锁定的对象，至于这个锁定的对象要保护的资源以及在哪里加锁 / 解锁，就属于设计层面的事情了。
互斥锁: 如何用一把锁保护多个资源
受保护的资源和锁之间合理的关联关系应该是N:1的关系.使用一把锁保护多个资源也是分情况的,在于多个资源之间存不存在关系,这是要分情况讨论的.
保护没有关联关系的多个资源
举个例子来说明,Account类有两个成员变量,分别是账户余额balance和账户密码password. 取款和查看余额会访问balance,创建一个final对象balLock来作为balance的锁;更改密码和查看密码会操作password,创建一个final对象pwLock来作为password的锁.不同的资源用不同的锁保护.代码示例如下:
class Account {
// 锁：保护账户余额
private final Object balLock
= new Object();
// 账户余额
private Integer balance;
// 锁：保护账户密码
private final Object pwLock
= new Object();
// 账户密码
private String password;
// 取款
void withdraw(Integer amt) {
synchronized(balLock) {
if (this.balance > amt){
this.balance -= amt;
}
}
}
// 查看余额
Integer getBalance() {
synchronized(balLock) {
return balance;
}
}
// 更改密码
void updatePassword(String pw){
synchronized(pwLock) {
this.password = pw;
}
}
// 查看密码
String getPassword() {
synchronized(pwLock) {
return password;
}
}
}
那还有没有其他的解决方案? 可以使用this来进行加锁,但是这种情况性能会很差,因为password和balance使用同一把锁,操作也就串行了,使用两把锁,password和balance的操作是可以并行的,用不同的锁对受保护资源进行精细化关系,能够提升性能.这个叫细粒度锁
保护有关联关系的多个资源
如果多个资源之间有关联关系,那就比较复杂,经典的转账问题.看下面代码可能发生并发问题吗?
class Account {
private int balance;
// 转账
synchronized void transfer(
Account target, int amt){
if (this.balance > amt) {
this.balance -= amt;
target.balance += amt;
}
}
}
开起来没问题,其实不然,只对当前对象进行了加锁,那目标对象的访问呢?也就是说当前的对象是无法保护target.balance的.
上面的案例两个人之间的转账或许没有问题,但是涉及三个人呢?
这个时候B的余额可能为100,也可能为300,看哪个执行在后了.那应该如何解决这种有关联的资源呢,找公共的锁就可以,也就是要锁能覆盖所有受保护资源,解决方案其实不少,如下
class Account {
private Object lock；
private int balance;
private Account();
// 创建 Account 时传入同一个 lock 对象
public Account(Object lock) {
this.lock = lock;
}
// 转账
void transfer(Account target, int amt){
// 此处检查所有对象共享的锁
synchronized(lock) {
if (this.balance > amt) {
this.balance -= amt;
target.balance += amt;
}
}
}
}
这个解决方案缺点在于需要传入共享的lock,还有一种方案
class Account {
private int balance;
// 转账
void transfer(Account target, int amt){
synchronized(Account.class) {
if (this.balance > amt) {
this.balance -= amt;
target.balance += amt;
}
}
}
}
这个是不是很简单.
上图展示了如何使用共享的锁来保护不同对象的临界区.
解决原子性问题,是要保证中间状态对外不可见.
