目录
前言：
通过这篇文章可以更加深入理解锁内部的一些实现原理，以及怎样描述一把锁。还有典型的CAS问题。
常见锁策略
通过一些锁实现的策略，就可以描述一把具体的锁。
1）乐观锁 vs 悲观锁
乐观锁：预测锁竞争不是很激烈，做的工作少。
悲观锁：预测锁竞争很激烈，做的工作多。
2）轻量级锁 vs 重量级锁
轻量级锁：加锁的开销比较小，效率高。
重量级锁：加锁的开销比较大，效率低。
- 多数情况下，乐观锁是轻量级锁（不完全保证）
- 多数情况下，悲观锁是重量级锁（不完全保证）
3）自旋锁 vs 挂起等待锁
自旋锁：始终监视锁的状态，第一时间就可以获得锁状态，加锁效率比较高（占用大量系统资源）。
挂起等待锁：被动的监视锁的状态，不能第一时间获得锁状态，加锁效率比较低（节省系统资源，可以做些别的事情）
- 自旋锁是典型的一种轻量级锁。
- 挂起等待锁是典型的一种重量级锁。
4）互斥锁 vs 读写锁
互斥锁：提供加锁和解锁两种功能。
读写锁：针对读和写操作区分对待，也可以释放锁。
- 读锁和读锁之间，不存在互斥。
- 读锁和写锁之间，存在互斥。
- 写锁和写锁之间，存在互斥。
5）公平锁 vs 非公平锁
公平锁：针对先来后到体现公平原则。阻塞时间久的线程先获得锁，以时间来排序。
非公平锁：没有先来后到的说法，一起竞争锁。
6）可重入锁 vs 不可重入锁
可重入锁：一个线程针对同一把锁，加锁多次不会产生锁竞争。
不可重入锁：一个线程针对同一把锁，加锁多次，会产生锁竞争，造成阻塞等待。
Synchronized对号入座
1）既是乐观锁也是悲观锁。默认是乐观锁，发现锁竞争比较激烈就会升级为悲观锁。
2）既是轻量级锁也是重量级锁。锁竞争不激烈就是轻量级锁，锁竞争激烈就是重量级锁。
3）当为轻量级锁就是自旋锁，当为重量级锁就是挂起等待锁。
4）是互斥锁。
5）是非公平锁。
6）是可重入锁。
CAS
CAS是一条cpu指令，CAS操作是原子的。比较且交换（cmopare and swap）
CAS应用场景
基于CAS这样一条cpu指令，可具体应用于一些特殊场景中，提升程序效率。
原子类
实现原子类：伪代码，实现加加操作
注意：这里只有当CAS判断相等，且交换成功后，while循环才会结束。这里就算第一个线程执行完load被切换走，当第二个线程在执行CAS（判断value和oldvalue相等，则把oldvalue + 1写入内存），修改了内存中的值。当第一个线程被切换回来时，发现oldvalue和value不相等，则重新读取value的值，然后再执行CAS（判断相等且交换，执行第二次加加操作）。这样就可以保证多线程情况下可以正常进行加加操作。
自旋锁
实现自旋锁（伪代码）
注意：while循环里，不断的执行CAS判断线程是否加锁。线程如果加锁就一直自旋等待，线程一旦释放锁后，立即就可以获得锁的状态。执行CAS获得当前线程的锁。
标准库中基于CAS实现的原子类介绍
Atomic系列：
这里介绍下AtomicInteger的使用，主要是实现多线程下安全的自增自减操作。
1）getAndIncrement()方法：后置加加
2）incrementAndGet()方法：前置加加
3）getAndDecrement()方法：后置减减
4）decrementAndGet()方法：前置减减
代码实现
public class ThreadDemo28 {
public static void main(String[] args) throws InterruptedException {
//原子类，基于CAS实现的原子类，提供了自增自减等操作。多线程下就是线程安全的
AtomicInteger count = new AtomicInteger(0);
Thread t1 = new Thread(new Runnable() {
@Override
public void run() {
for(int i = 0; i < 5000; i++) {
count.getAndIncrement(); //count++
//count.incrementAndGet(); //++count
//count.getAndDecrement(); //count--
//count.decrementAndGet(); //--count
}
}
});
Thread t2 = new Thread(new Runnable() {
@Override
public void run() {
for(int i = 0; i < 5000; i++) {
count.getAndIncrement();
}
}
});
t1.start();
t2.start();
t1.join();
t2.join();
System.out.println(count.get());
}
}
注意：可以清楚看见运行结果是符合预期的。
ABA问题
CAS典型的ABA问题，就是当执行CAS判断的时候（看起来是没有变化），但是这个变量已经修改过了。
示例：
取钱问题。当使用CAS取钱的时候，假设余额有1000，CAS判断余额是否为1000，如果相等，则取500。如果机器卡顿这个人多按了几次，当执行第一次CAS取钱500，在这个瞬间又被转账了500，那么执行下一次CAS就会成功。出现了BUG。
改进方法：
增加版本号，每执行一次CAS版本号就加1，不使用余额判断而去使用版本号。当执行了第一次CAS版本号就改变，当执行第二次CAS发现版本号不一致，那么就不会执行了。也就不会出现BUG了。
Synchronized原理
锁升级
第一阶段：无锁
第二阶段：偏向锁
第三阶段：轻量级锁
第四阶段：重量级锁
1）首先是无锁状态。
2）当代码执行到需要加锁的时候，先设置个标志位（偏向锁）。然后继续执行加锁的这块代码，如果在这个期间没有出现锁竞争，那么当这块代码执行完就只需要清空标志位。如果在这个期间出现了锁竞争，立即就由偏向锁升级为轻量级锁，其他线程就只能阻塞等待了。
3）出现锁竞争由偏向锁升级为轻量级锁。
4）轻量级锁为自旋锁。如果这个时候要获取的锁对象，很长时间都不释放锁，那么就会一直自旋等待。直到一定的时间就会停止自旋（自旋需要消耗系统资源），升级为重量级锁，挂起等待锁。
锁消除
编译器会智能判定，当前代码是否需要加锁，如果不需要但是程序员加了，编译器就会取消这个加锁。
锁粗化
锁粒度：synchronized包含的代码越多锁粒度就越大，反之越小。
1）通常情况下锁粒度细一点比较好，因为加锁的代码无法并发执行，那么并发的代码越多程序效率就越高。
2）如果加锁开锁又加锁，这个期间时间间隔很短（几乎没有可以并发的代码），那么就可以考虑增大锁粒度（扩大范围），因为加锁开锁也是需要消耗系统资源的。
小结：
与大家共勉一句名言：少年不负岁月长，彼方尚有荣光在！