目录

前言：

常见锁策略

CAS

CAS应用场景

标准库中基于CAS实现的原子类介绍

代码实现

ABA问题

Synchronized原理

锁升级

锁消除

锁粗化

小结：

前言：

    通过这篇文章可以更加深入理解锁内部的一些实现原理，以及怎样描述一把锁。还有典型的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() {@Overridepublic 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() {@Overridepublic 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）如果加锁开锁又加锁，这个期间时间间隔很短（几乎没有可以并发的代码），那么就可以考虑增大锁粒度（扩大范围），因为加锁开锁也是需要消耗系统资源的。

小结：

    与大家共勉一句名言：少年不负岁月长，彼方尚有荣光在！