java并发编程 -2- 并发问题以及volatile、sync
1 背景
咱们的计算机有3大重要组成：CPU、内存、硬盘。而这三个组成的速度差别是非常明显的，CPU>内存>硬盘，根据木桶原理，硬盘的读写理所应当地成为程序的瓶颈。为了均衡这三者，并且更高效地利用CPU，咱们的操作系统和java编译器做了如下动作：
- CPU增加了缓存，以均衡和内存之间的速度差异，
- 操作系统通过进程和线程对CPU的分时复用，让CPU利用率更高。
- 编译器优化了代码的执行顺序。
这三点的确达到了想要的效果，但是，同时也带来了一些并发问题：
1.1 多核心CPU缓存导致可见性问题
image.png
在单核时代，如果不考虑线程切换的前提下，CPU有缓存其实是没有问题的，线程1和线程2都是操作的CPU里缓存的共享变量A，那，所以如果线程1修改了A的值，线程2是马上可以知道的，我们称其为可见性。
image.png
但是进入了多核时代，问题就出来了，线程1和线程2可能分别操作的是不同CPU里缓存的共享变量，当A修改了cpu1里的共享变量的值的时候，线程2是不知道的，直到该值通过同步给了内存，再同步给了CPU2。
public class CountExample {
private long count=0;
public void add10K(){
for(int i=1;i<=10000;i++){
this.count++;
}
}
public long getCount() {
return count;
}
}
@Test
public void cpuCacheTest() throws InterruptedException {
CountExample countExample=new CountExample();
Thread t1=new Thread(()->{
countExample.add10K();
});
Thread t2=new Thread(()->{
countExample.add10K();
});
//启动
t1.start();
t2.start();
//等待两个线程结束
t1.join();
t2.join();
log.info(countExample.getCount()+"");
}
image.png
上面这段代码可以演示可见性问题：两个线程分别对共享变量进行10000次+1操作，结果并不是我们期望得到的20000，而是10000到20000之间的随机数。因为可能发送这种情况：当内存里的值是0的时候，cpu1和cpu2都会把0读到自己缓存里，然后加1，同步给内存，最后内存拿到的就是1，不是2。
那上面的代码在单核上面跑，就没问题了吗？？很遗憾，还是有问题。原因这部分代码还有我们马上会说到的原子性问题
1.2 线程切换导致的原子性问题。
什么是原子性操作：不可分割的操作叫做原子性操作。也就是要么都成功，要么都失败，不可能成功了一半。
上面的代码的 count++这个操作时原子性操作吗？ 答案是：否。 它对于java语言来说，是一个操作，但是对于操作系统来说，它是分为了3个步骤：
1、把count的值读取到寄存器，也就是缓存。
2、在寄存器把count的值+1.
3、把寄存器的值同步给内存。
由于我们线程因为分时复用机制而切换，对于2个线程来说，这3步可能发生如下情况：
image.png
最后拿到的结果还是1，而不是我们期望的2。
1.3 编译优化导致的有序性问题
编译优化会为我们做什么事情？
编译器会根据自己的判断，把它认为顺序无关的两行代码交换执行顺序。这会带来什么问题呢？举个栗子：
public class SingletomExamle {
private static SingletomExamle singletomExamle;
private SingletomExamle(){
super();
};
public static SingletomExamle getInstance(){
if(singletomExamle==null){
synchronized (SingletomExamle.class){
if(singletomExamle==null){
singletomExamle=new SingletomExamle();
}
}
}
return singletomExamle;
}
}
这是一个典型的双重检查单例模式：1、私有的变量和构造函数。2、获取对象的方法先判断是否为空，如果为空，则通过一个同步块去创建一个对象，为了防止获取到锁的时候，别的线程已经创建成功了对象，同步块里又一次做了非空判断。
看上去完美无缺！ 但是，还是有问题。
这里的问题出在了new SingletomExample 这一句代码上。这句代码在我们的想象中，会是这样执行：
1、分配一块内存 M。
2、在M上初始化对象SingletomExample。
3、把singletomExamle指向M的地址。
由于2和3在编译器看来其实是顺序无关的，所以它交换了他们的执行顺序：
1、分配一块内存 M。
2、把singletomExamle指向M的地址。
3、在M上初始化对象SingletomExample。
导致了可能发生下面这种情况：
image.png
当线程1还没有初始化对象SingletomExample，但是已经把instants指向M地址，线程2的instants==null会返回true。那线程2会拿到一个还没有被初始化的instants对象，导致使用的时候出问题。
2 volatile
volatile这个关键字，会带来两个效果：
1、禁用cpu缓存。
2、禁用编译器优化。
所以，volatile是可以解决1.1的缓存问题以及1.3的有序性问题的，比如1.3的代码如果加上volatile就完美了：
public class SingletomExamle {
private volatile static SingletomExamle singletomExamle;
private SingletomExamle(){
super();
};
public static SingletomExamle getInstance(){
if(singletomExamle==null){
synchronized (SingletomExamle.class){
if(singletomExamle==null){
singletomExamle=new SingletomExamle();
}
}
}
return singletomExamle;
}
}
3 synchronized
synchronized 会解决原子性的问题，同时cpu缓存和内存的同步也在这个原子操作之内，所以也解决了可见性问题。比如1.1的代码如果我们家上锁，就一定能得到20000：
public class CountExample {
private long count=0;
public synchronized void add10K(){
for(int i=1;i<=10000;i++){
this.count++;
}
}
public long getCount() {
return count;
}
}
@Test
public void cpuCacheTest() throws InterruptedException {
CountExample countExample=new CountExample();
Thread t1=new Thread(()->{
countExample.add10K();
});
Thread t2=new Thread(()->{
countExample.add10K();
});
//启动
t1.start();
t2.start();
//等待两个线程结束
t1.join();
t2.join();
log.info(countExample.getCount()+"");
}
image.png
3.1 synchronized的基本用法
class X {
// 修饰非静态方法
synchronized void foo() {
// 临界区
}
// 修饰静态方法
synchronized static void bar() {
// 临界区
}
// 修饰代码块
Object obj = new Object()；
void baz() {
synchronized(obj) {
// 临界区
}
}
}
1、对于静态方法的加锁，相当于：synchronized(X.class)，锁的是整个类。
2、对于非静态方法的加锁，相当于:synchronized(this),锁的是当前对象。
3、对于代码块的加锁，锁的是传入的obj。
那么这里的参数（X.class、this、obj）到底是啥意思的？
它是这个所起作用的范围，比如你锁掉了X.class，那所有调用X.class的静态加锁方法的线程都会一直等待这把锁：
@Slf4j
public class SyncUseExample {
private static String value;
public static synchronized String getValue(){
try {
Thread.sleep(3000);
} catch (InterruptedException e) {
log.error("exception",e);
}
return value;
}
public static synchronized void setValue(String v){
value=v;
}
}
@Test
public void syncUseTest() throws InterruptedException {
Thread t1=new Thread(()->{
log.info("t1 start");
SyncUseExample.getValue();
log.info("t1 end");
});
Thread t2=new Thread(()->{
log.info("t2 start");
SyncUseExample.setValue("1000");
log.info("t2 end");
});
//启动
t1.start();
t2.start();
t1.join();
t2.join();
}
image.png
我们可以看到，线程 t2 "陪"着 t1 sleep了3秒钟，因为他们都是静态方法，所以都是同一把锁（SyncUseExample.class）
我们改成非静态方法，且不同对象再试试：
@Slf4j
public class SyncUseExample {
private String value;
public synchronized String getValue(){
try {
Thread.sleep(3000);
} catch (InterruptedException e) {
log.error("exception",e);
}
return value;
}
public synchronized void setValue(String v){
value=v;
}
}
@Test
public void syncUseTest() throws InterruptedException {
SyncUseExample e1=new SyncUseExample();
SyncUseExample e2=new SyncUseExample();
Thread t1=new Thread(()->{
log.info("t1 start");
e1.getValue();
log.info("t1 end");
});
Thread t2=new Thread(()->{
log.info("t2 start");
e2.setValue("1000");
log.info("t2 end");
});
//启动
t1.start();
t2.start();
t1.join();
t2.join();
}
image.png
因为线程t1 锁的是 e1对象，线程t2使用的是e2对象，所以，t2的执行，并不会等待t1锁的释放。
3.2 锁最合理的范围
弄清楚锁的作用范围，我们再来讨论什么才是最合理的作用范围。锁的范围太小了，不能保证原子性，锁的范围太大了，会把操作都弄成串行操作，影响性能。所以，一定要根据业务实际情况来定锁的范围。以银行转帐举个栗子： A账户转帐给账户B，B账户转账给账户C,每个账户最开始都是200块：
public class SyncExample {
public int money=200;
public void transfer(SyncExample target,int amt){
this.money=this.money-amt;
target.money=target.money+amt;
}
}
@Test
public void syncTest() throws InterruptedException {
while (true){
SyncExample A=new SyncExample();
SyncExample B=new SyncExample();
SyncExample C=new SyncExample();
Thread t1=new Thread(()->{
A.transfer(B,100);
});
Thread t2=new Thread(()->{
B.transfer(C,100);
});
t1.start();
t2.start();
t1.join();
t2.join();
if(A.money!=100||B.money!=200||C.money!=300){
log.info("A:"+A.money);
log.info("B:"+B.money);
log.info("C:"+C.money);
log.info("--------------------");
}
}
}
image.png
这是没加锁的时候，跑一段时间会出现的情况：由于没有锁住B账户，所以线程t1的和t2可能同时拿到B=200的初始状态进行操作，那结果就是其中一个的操作结果被后完成的那个覆盖，那B账户最终结果可能是100 也可能是300，而不是我们期望的200。
那我们把transfer方法加上锁呢：
public class SyncExample {
public int money=200;
public synchronized void transfer(SyncExample target,int amt){
this.money=this.money-amt;
target.money=target.money+amt;
}
}
结果跑一段时间：
image.png
还是有问题，我们不是加了锁了么，为什么呢？
我们前面说过，非静态方法，锁的是当前实例对象，也就是说，t1锁的是账户A！并不是账户B，所以对于账户B来说，跟没加一样！
所以我们的目标是，锁账户B：
public class SyncExample {
public int money=200;
public void transfer(SyncExample target,int amt){
synchronized(SyncExample.class){
this.money=this.money-amt;
target.money=target.money+amt;
}
}
这样就没有并发问题了。 但是，我们锁的范围明显太大了，导致如果账户A向B转账，C向D转账这两个完全可以一起执行的操作都会变成串行操作。
所以，我们只需要 用两把锁掉转账双方即可：
public class SyncExample {
public int money=200;
public void transfer(SyncExample target,int amt){
synchronized(this){
synchronized (target){
this.money=this.money-amt;
target.money=target.money+amt;
}
}
}
}
锁的范围刚刚好！完美！ 但是，新的问题来了，这个代码会造成死锁。如果A转给B，同时B转给A，他们都执行了synchronized(this)这行代码,A锁住了自己，B锁住了自己，同时A等待B锁的释放，B等待A锁的释放。。。。。
关于死锁，我们下一节接着讲。
下一章 java并发编程 - 3 - 死锁问题
