之前我们所了解的属于多线程的初阶内容。今天开始，我们进入多线程进阶的学习。
锁的策略
乐观锁 悲观锁
这不是两把具体的锁，应该叫做“两类锁”
乐观锁：预测锁竞争不是很激烈（这里做的工作可能就会少一些）
悲观锁，预测锁竞争会很激烈（这里的工作可能就会多一些）
这里都不绝对，悲观和乐观，唯一的区分主要就是看预测锁竞争激烈程度的结论~
轻量级锁 重量级锁
轻量级锁加锁解锁开销比较小~效率更高~
重量级锁加锁解锁开销比较大~效率更低~
多数情况下，乐观锁也是一个轻量级锁
多数情况下，悲观锁也是一个重量级锁
自旋锁 挂起等待锁
自旋锁，是一种典型的轻量级锁：当某个线程没有申请到锁的时候，该线程不会被挂起，而是每隔一段时间检测锁是否被释放。如果锁被释放了，那就竞争锁；如果没有释放，过一会儿再来检测。
挂起等待锁，是一种典型的重量级锁：当某个线程没有申请到锁的时候，此时该线程会被挂起，即加入到等待队列等待。当锁被释放的时候，就会被唤醒，重新竞争锁。
也就是说自旋锁在申请锁的过程中会一直重复申请，会占用大量的cpu资源。挂起等待锁也就可以把cpu省下来干别的事情~
互斥锁 读写锁
互斥锁：像synchronized这样的锁，提供加锁和解锁两个操作~
如果一个线程加锁了，另一个线程也尝试加锁就会阻塞等待~
读写锁：只有一组操作中有读也有写，才会产生竞争。
公平锁 非公平锁
此处应该把公平定义成“先来后到”。
操作系统和Java synchronized 原生都是“非公平锁”。操作系统这里的针对加锁的控制，本身就非常依赖线程调度顺序，这个调度顺序是随机的，不会考虑到这个线程等待多久了~
要想实现公平锁，就得在这个基础上，引入额外的东西（比如一个给锁排序的队列）
可重入锁 不可重入锁
不可重入锁：针对同一个线程连续加锁多次，会出现死锁
可重入锁：针对同一个线程连续加锁多滴，不会出现死锁
synchronized
1.synchronized既是一个悲观锁，又是一个乐观锁。
synchronized默认是一个乐观锁，但是如果发现当前锁竞争比较激烈，就会变成悲观锁。
2.synchronized既是一个轻量级锁，也是一个重量级锁。
synchronized默认是一个轻量级锁，如果发现当前锁竞争比较激烈，就会转换成重量级锁。
3.synchronized这里的轻量级锁，是基于自旋锁的方式来实现的。
synchronized这里的重量级锁，是基于挂起等待锁的方式来实现的。
4.synchronized不是读写锁
5.synchronized是非公平锁
6.synchronized是可重入锁
总结：上述谈到的6种锁策略，可以视为是“锁的形容词”。
CAS
CAS全称Compare and swap，字面意思“比较和交换”
一个 CAS 涉及到以下操作：
我们假设内存中的原数据V，旧的预期值A，需要修改的新值B。
1. 比较 A 与 V 是否相等。（比较）
2. 如果比较相等，将 B 写入 V。（交换）
3. 返回操作是否成功。
最重要的是：CAS的操作是原子的！
CAS的过程并非是通过一段代码实现的，而是通过一条CPU指令完成的。
既然是原子的，那么就可以一定程度上处理线程安全问题~
boolean CAS(address, expectValue, swapValue) {
if (&address == expectedValue) {
&address = swapValue;
return true;
}
return false;
}
通过一段伪代码（不能编译运行，只是表达了一个大概的逻辑）可以更好地理解CAS。
CAS的应用场景
1.实现原子类：Java标准库里提供的类
标准库中提供了 java.util.concurrent.atomic 包,，里面的类都是基于这种方式来实现的.。典型的就是 AtomicInteger 类。其中的 getAndIncrement 相当于 i++ 操作。
AtomicInteger atomicInteger = new AtomicInteger(0);
// 相当于 i++
atomicInteger.getAndIncrement();
伪代码：
class AtomicInteger{ private int value; public int getAndIncrement(){ int oldvalue = value; while(CAS(value,oldvalue,oldvalue+1) != true){ oldvalue = value; } return oldvalue; } }此处为伪代码可以把oldvalue理解成为寄存器里的值。
我们就拿伪代码来说明：
正常情况下，oldValue应该和value是一样的值，紧接着这里会产生CAS，把oldValue + 1写到value中去。
但是：可能会执行完把value的值写到oldvalue（寄存器）这一步后，线程发生切换了，另一个线程也进行修改了value的值
此时这个线程回来后，通过CAS判定，就认为value和oldvalue不相等了。
于是就返回false，不进行任何交换。进入循环，循环内部重新读取value的值到oldvalue中去。
此时在比较，发现相等了，进行CAS操作，并返回true，就不进入循环结束了。
原子类这里的实现，每次修改之前，再确认一下这个值是否符合要求。
通过形如上述代码就可以实现一个原子类，不需要使用重量级锁,就可以高效的完成多线程的自增操作。
2.实现自旋锁
自旋锁伪代码：
public class SpinLock {
private Thread owner = null;
public void lock(){
// 通过 CAS 看当前锁是否被某个线程持有.
// 如果这个锁已经被别的线程持有, 那么就自旋等待.
// 如果这个锁没有被别的线程持有, 那么就把 owner 设为当前尝试加锁的线程.
while(!CAS(this.owner, null, Thread.currentThread())){
}
}
public void unlock (){
this.owner = null;
}
}
while循环中：监测当前的owner是否是null，如果是null，就进行交换，也就是把当前线程的引用赋值给owner 。如果赋值成功，此时循环结束，加锁完成了。
如果当前锁，已经被别的线程占用了，CAS就会发现,，this.owner 不是null，CAS就不会产生赋值,也同时返回false.循环继续执行，并进行下次判定....
ABA问题
CAS在运行中的核心：检查value和oldValue是否一致。如果一致，就视为value 中途没有被修改过，所以进行下一步交换操作是没问题的。
但是这里的一致，可能是没改过，也可能是改过，但是改回来了。
把value的值设为A的话，CAS判定value为A，此时可能确实value始终是A，也可能是value本来是A，被改成了B，又被还原成了A。
ABA这个情况，大部分情况下其实是不会对代码产生太大影响的，但是不排除一些极端情况，也是可能造成影响的。
假设我有 100 存款.。我想从 ATM 取 50 块钱，取款机创建了两个线程，并发的来执行 -50 操作，我们期望一个线程执行 -50 成功， 另一个线程 -50 失败。 如果使用 CAS 的方式来完成这个扣款过程就可能出现问题。
正常的过程
1) 存款 100。线程1 获取到当前存款值为 100，期望更新为 50; 线程2 获取到当前存款值为 100,，期望更新为 50。
2) 线程1 执行扣款成功，存款被改成 50。线程2阻塞等待中。
3) 轮到线程2执行了，发现当前存款为 50，和之前读到的 100 不相同，执行失败。
异常的过程
1) 存款 100。线程1 获取到当前存款值为 100，期望更新为 50；线程2 获取到当前存款值为 100,，期望更新为 50。
2) 线程1执行扣款成功，存款被改成 50。线程2阻塞等待中。
3) 在线程2执行之前，我的朋友正好给滑稽转账 50，账户余额变成 100 。
4) 轮到线程2 执行了，发现当前存款为100，和之前读到的100相同，再次执行扣款操作
这个时候扣款就被执行了两次。
解决办法
给要修改的值，引入版本号。在 CAS 比较数据当前值和旧值的同时，也要比较版本号是否符合预期。CAS 操作在读取旧值的同时，也要读取版本号。真正修改的时候，如果当前版本号和读到的版本号相同，则修改数据，并把版本号 + 1 。如果当前版本号高于读到的版本号，操作失败(认为数据已经被修改过了)。
synchronized原理
两个线程，针对一个对象加锁，就会产生阻塞等待。
synchronized内部其实还有一些优化机制，存在的目的就是为了让这个锁更高效，更好用。
1.锁升级、锁膨胀
1）无锁 2）偏向锁 3）轻量级锁 4）重量级锁
synchronized(locker){
}当代码执行到这个代码块中之后，加锁过程会经历前面说的这几个阶段：
偏向锁：
进行加锁的时候，首先会进入到偏向锁的状态。偏向锁的过程就是：“非必要，不加锁”。
synchronized的时候，并不是真的加锁，先偏向锁状态，做个标记（这个过程是非常轻量的），如果整个使用锁的过程中，都没有出现锁竞争，在synchronized执行完之后，取消偏向锁即可。
（反正也没有锁竞争，这样就开销最低了~）
但是如果使用过程中，另一个线程也尝试加锁，在它加锁之前，迅速地把偏向锁升级成真正的加锁状态，另一个线程也就只能阻塞等待了~
轻量级锁：
当synchronized发生锁竞争的时候，就会从偏向锁，升级成轻量级锁。
此时，synchronized相当于是通过自旋的方式来进行加锁的。刚才那个CAS那里的那个伪代码一样~
synchronized内部的自旋循环中，有个计数器，记录了循环了多少次/多久了，达到一定程度，就结束循环，执行重量级锁的逻辑。
重量级锁：
此时如果线程进行了重量级锁的加锁，并且发生锁竞争，此时线程就会被放到阻塞队列中，暂时不参与CPU调度了~
然后锁被释放了这个线程才有机会被调度到，并且有机会获取到锁。
锁降级：
锁能升级了，但是不能降级。只有锁升级，没有锁降级。除非是另外搞一个对象，重复刚才的从偏向锁开始升级的过程~
2.锁消除
编译器智能的判定，看当前的代码是否是真的要加锁，如果这个场景不需要加锁，程序猿也加了，就自动把锁给干掉~~
StringBuffer关键方法都带有synchronized。
但是如果在单线程中使用StringBuffer, synchronized 加了也白加，此时编译器就会直接把这些加锁操作干掉了。
3.锁粗化
锁的粒度：synchronized包含的代码越多，粒度就越粗，包含的代码就越少，粒度就越细。
通常情况下，认为锁的粒度细一点比较好。加锁的部分，是不能并发执行的。锁的粒度越细，能并发的代码就越多，反之就越少。
但是有些情况下，锁的粒度粗一些反而更好~
