JUC并发编程(14.Java线程）

红太狼 2023-09-24 20:00 54阅读 0赞

本章内容

1.  CAS 与 volatile
2.  原子整数
3.  原子引用
4.  原子累加器
5.  Unsafe  
    ![在这里插入图片描述][79bab9b0d2384bfc94450319f04027ec.png]

# 1.共享模型之无锁 #

## 1)问题提出 ##

有如下需求，保证 `account.withdraw`取款方法的线程安全

interface Account {
        
    	// 获取余额
    	Integer getBalance();
    	// 取款
    	void withdraw(Integer amount);
    	/**
    	* 方法内会启动 1000 个线程，每个线程做 -10 元 的操作
    	* 如果初始余额为 10000 那么正确的结果应当是 0
    	*/
    	static void demo(Account account) {
        
    	List<Thread> ts = new ArrayList<>();
    	long start = System.nanoTime();
    	for (int i = 0; i < 1000; i++) {
        
    		ts.add(new Thread(() -> {
        
    		account.withdraw(10);
    	}));
    	}
    	ts.forEach(Thread::start);
    	ts.forEach(t -> {
        
    		try {
        
    			t.join();
    		} catch (InterruptedException e) {
        
    			e.printStackTrace();
    		}
    		});
    		long end = System.nanoTime();
    		System.out.println(account.getBalance()
    		+ " cost: " + (end-start)/1000_000 + " ms");
    	}
    }

原有实现并不是线程安全的

class AccountUnsafe implements Account {
        
    	private Integer balance;
    	public AccountUnsafe(Integer balance) {
        
    		this.balance = balance;
    	}
    	@Override
    	public Integer getBalance() {
        
    		return balance;
    	}
    	@Override
    	public void withdraw(Integer amount) {
        
    		balance -= amount;
    	}
    }

执行测试代码

public static void main(String[] args) {
        
    	Account.demo(new AccountUnsafe(10000));
    }

执行结果

330 cost: 306 ms

## 2)为什么不安全 ##

`withdraw`方法

public void withdraw(Integer amount) {
        
    balance -= amount;
    }

对应的字节码

ALOAD 0 // <- this
    ALOAD 0
    GETFIELD cn/itcast/AccountUnsafe.balance : Ljava/lang/Integer; // <- this.balance
    INVOKEVIRTUAL java/lang/Integer.intValue ()I // 拆箱
    ALOAD 1 // <- amount
    INVOKEVIRTUAL java/lang/Integer.intValue ()I // 拆箱
    ISUB // 减法
    INVOKESTATIC java/lang/Integer.valueOf (I)Ljava/lang/Integer; // 结果装箱
    PUTFIELD cn/itcast/AccountUnsafe.balance : Ljava/lang/Integer; // -> this.balance

多线程执行流程

ALOAD 0 // thread-0 <- this
    ALOAD 0
    GETFIELD cn/itcast/AccountUnsafe.balance // thread-0 <- this.balance
    INVOKEVIRTUAL java/lang/Integer.intValue // thread-0 拆箱
    ALOAD 1 // thread-0 <- amount
    INVOKEVIRTUAL java/lang/Integer.intValue // thread-0 拆箱
    ISUB // thread-0 减法
    INVOKESTATIC java/lang/Integer.valueOf // thread-0 结果装箱
    PUTFIELD cn/itcast/AccountUnsafe.balance // thread-0 -> this.balance
    ALOAD 0 // thread-1 <- this
    ALOAD 0
    GETFIELD cn/itcast/AccountUnsafe.balance // thread-1 <- this.balance
    INVOKEVIRTUAL java/lang/Integer.intValue // thread-1 拆箱
    ALOAD 1 // thread-1 <- amount
    INVOKEVIRTUAL java/lang/Integer.intValue // thread-1 拆箱
    ISUB // thread-1 减法
    INVOKESTATIC java/lang/Integer.valueOf // thread-1 结果装箱
    PUTFIELD cn/itcast/AccountUnsafe.balance // thread-1 -> this.balance

*  单核的指令交错
 *  多核的指令交错

## 3)解决思路-锁 ##

首先想到的是给 Account 对象加锁

class AccountUnsafe implements Account {
        
    	private Integer balance;
    	public AccountUnsafe(Integer balance) {
        
    		this.balance = balance;
    	}
    	@Override
    	public synchronized Integer getBalance() {
        
    		return balance;
    	}
    	@Override
    	public synchronized void withdraw(Integer amount) {
        
    		balance -= amount;
    	}
    }

结果为

0 cost: 399 ms

## 4)解决思路-无锁 ##

class AccountSafe implements Account {
        
    	private AtomicInteger balance;
    	public AccountSafe(Integer balance) {
        
    		this.balance = new AtomicInteger(balance);
    	}
    	@Override
    	public Integer getBalance() {
        
    		return balance.get();
    	}
    	@Override
    	public void withdraw(Integer amount) {
        
    		while (true) {
        
    			int prev = balance.get();
    			int next = prev - amount;
    			if (balance.compareAndSet(prev, next)) {
        
    			break;
    		}
    	}
    	// 可以简化为下面的方法
    	// balance.addAndGet(-1 * amount);
    	}
    }

执行测试代码

public static void main(String[] args) {
        
    Account.demo(new AccountSafe(10000));
    }

某次的执行结果

0 cost: 302 ms

# 2. CAS 与 volatile #

前面看到的 `AtomicInteger` 的解决方法，内部并没有用锁来保护共享变量的线程安全。那么它是如何实现的呢？

public void withdraw(Integer amount) {
        
    	while(true) {
        
    	// 需要不断尝试，直到成功为止
    	while (true) {
        
    	// 比如拿到了旧值 1000
    		int prev = balance.get();
    		// 在这个基础上 1000-10 = 990
    		int next = prev - amount;
    		/*
    		compareAndSet 正是做这个检查，在 set 前，先比较 prev 与当前值
    		- 不一致了，next 作废，返回 false 表示失败
    		比如，别的线程已经做了减法，当前值已经被减成了 990
    		那么本线程的这次 990 就作废了，进入 while 下次循环重试
    		- 一致，以 next 设置为新值，返回 true 表示成功
    		*/
    		if (balance.compareAndSet(prev, next)) {
        
    			break;
    		}
    	}
    	}
    }

其中的关键是 `compareAndSet`，它的简称就是 `CAS （也有 Compare And Swap 的说法）`，它必须是`原子操作`。

![在这里插入图片描述][5a1a2300af174b228f8f58ff1e077e6d.png]

> 注意

*  其实 `CAS 的底层是 lock cmpxchg 指令`（X86 架构），在`单核 CPU`和`多核 CPU` 下都能够保证【比较-交换】的原子性。
 *  在多核状态下，某个核执行到带 lock 的指令时，CPU 会让总线锁住，当这个核把此指令执行完毕，再开启总线。这个过程中不会被线程的调度机制所打断，保证了多个线程对内存操作的准确性，是原子的。

## 1)慢动作分析 ##

public class SlowMotion {
        
    	public static void main(String[] args) {
        
    	AtomicInteger balance = new AtomicInteger(10000);
    	int mainPrev = balance.get();
    	log.debug("try get {}", mainPrev);
    	new Thread(() -> {
        
    		sleep(1000);
    		int prev = balance.get();
    		balance.compareAndSet(prev, 9000);
    		log.debug(balance.toString());
    	}, "t1").start();
    	sleep(2000);
    	log.debug("try set 8000...");
    	boolean isSuccess = balance.compareAndSet(mainPrev, 8000);
    	log.debug("is success ? {}", isSuccess);
    	if(!isSuccess){
        
    		mainPrev = balance.get();
    		log.debug("try set 8000...");
    		isSuccess = balance.compareAndSet(mainPrev, 8000);
    		log.debug("is success ? {}", isSuccess);
    	}
    	}
    	private static void sleep(int millis) {
        
    		try {
        
    			Thread.sleep(millis);
    		} catch (InterruptedException e) {
        
    			e.printStackTrace();
    		}
    	}
    }

2019-10-13 11:28:37.134 [main] try get 10000
    2019-10-13 11:28:38.154 [t1] 9000
    2019-10-13 11:28:39.154 [main] try set 8000...
    2019-10-13 11:28:39.154 [main] is success ? false
    2019-10-13 11:28:39.154 [main] try set 8000...
    2019-10-13 11:28:39.154 [main] is success ? true

## 2)volatile ##

获取共享变量时，为了`保证该变量的可见性`，需要使用 `volatile` 修饰。  
它可以用来`修饰成员变量`和`静态成员变量`，他可以`避免线程从自己的工作缓存中查找变量的值`，必须到主存中获取它的值，`线程操作 volatile 变量都是直接操作主存`。`即一个线程对 volatile 变量的修改，对另一个线程可见`。

> 注意  
> volatile 仅仅保证了`共享变量的可见性`，让其它线程能够看到最新值，`但不能解决指令交错问题（不能保证原子性）`

CAS 必须借助 volatile 才能读取到`共享变量的最新值`来实现【比较并交换】的效果

## 3)为什么无锁效率高 ##

*  `无锁情况下`，即使重试失败，线程始终在高速运行，`没有停歇`，而 `synchronized 会让线程在没有获得锁的时候，发生上下文切换，进入阻塞`。打个比喻
 *  线程就好像高速跑道上的赛车，高速运行时，速度超快，一旦发生上下文切换，就好比赛车要减速、熄火，等被唤醒又得重新打火、启动、加速… 恢复到高速运行，代价比较大
 *  但`无锁情况下，因为线程要保持运行，需要额外 CPU 的支持`，CPU 在这里就好比高速跑道，没有额外的跑道，线程想高速运行也无从谈起，虽然不会进入阻塞，但由于没有分到时间片，仍然会进入`可运行状态`，还是会`导致上下文切换`。  
    ![在这里插入图片描述][ef9f4a908a38473eb8a19e68931ab6ed.png]

## 4)CAS 的特点 ##

结合 `CAS` 和 `volatile` 可以实现`无锁并发`，适用于`线程数少、多核 CPU` 的场景下。

*  `CAS` 是基于`乐观锁的思想`：最乐观的估计，`不怕别的线程来修改共享变量，就算改了也没关系，我吃亏点再重试`。
 *  `synchronized` 是基于`悲观锁的思想`：最悲观的估计，`得防着其它线程来修改共享变量`，我上了锁你们都别想改，我改完了解开锁，你们才有机会。
 *  `CAS 体现的是无锁并发、无阻塞并发`，请仔细体会这两句话的意思
    
     *  因为没有使用 synchronized，所以`线程不会陷入阻塞`，这是效率提升的因素之一
     *  但如果竞争激烈，可以想到重试必然频繁发生，反而效率会受影响

[79bab9b0d2384bfc94450319f04027ec.png]: https://img-blog.csdnimg.cn/79bab9b0d2384bfc94450319f04027ec.png
[5a1a2300af174b228f8f58ff1e077e6d.png]: https://img-blog.csdnimg.cn/5a1a2300af174b228f8f58ff1e077e6d.png
[ef9f4a908a38473eb8a19e68931ab6ed.png]: https://img-blog.csdnimg.cn/ef9f4a908a38473eb8a19e68931ab6ed.png