典型回答

synchronized 代码块是由一对儿 monitorenter/monitorexit 指令实现的，Monitor 对象是同步的基本实现单元。

在 Java 6 之前，Monitor 的实现完全是依靠操作系统内部的互斥锁，因为需要进行用户态到内核态的切换，所以同步操作是一个无差别的重量级操作。

现代的（Oracle）JDK 中，JVM 对此进行了大刀阔斧地改进，提供了三种不同的 Monitor 实现，也就是常说的三种不同的锁：偏斜锁（Biased Locking）、轻量级锁和重量级锁，大大改进了其性能。

所谓锁的升级、降级，就是 JVM 优化 synchronized 运行的机制，当 JVM 检测到不同的竞争状况时，会自动切换到适合的锁实现，这种切换就是锁的升级、降级。

当没有竞争出现时，默认会使用偏斜锁。JVM 会利用 CAS 操作（compare and swap），在对象头上的 Mark Word 部分设置线程 ID，以表示这个对象偏向于当前线程，所以并不涉及真正的互斥锁。这样做的假设是基于在很多应用场景中，大部分对象生命周期中最多会被一个线程锁定，使用偏斜锁可以降低无竞争开销。

如果有另外的线程试图锁定某个已经被偏斜过的对象，JVM 就需要撤销（revoke）偏斜锁，并切换到轻量级锁实现。轻量级锁依赖 CAS 操作 Mark Word 来试图获取锁，如果重试成功，就使用普通的轻量级锁；否则，进一步升级为重量级锁。

我注意到有的观点认为 Java 不会进行锁降级。实际上据我所知，锁降级确实是会发生的，当 JVM 进入安全点（SafePoint）的时候，会检查是否有闲置的 Monitor，然后试图进行降级。

考点分析

synchronized 的底层实现

理解并发包中 java.util.concurrent.lock 提供的其他锁实现，
毕竟 Java 可不是只有 ReentrantLock 一种显式的锁类型

知识扩展

synchronized 是 JVM 内部的 Intrinsic Lock，所以偏斜锁、轻量级锁、重量级锁的代码实现，并不在核心类库部分，而是在 JVM 的代码中。

synchronized 的底层实现，暂时理解不了。

image.png

ReadWriteLock 是一个单独的接口，它通常是代表了一对儿锁，分别对应只读和写操作，标准类库中提供了再入版本的读写锁实现（ReentrantReadWriteLock），对应的语义和 ReentrantLock 比较相似。

StampedLock 竟然也是个单独的类型，从类图结构可以看出它是不支持再入性的语义的，也就是它 不是以持有锁的线程为单位。（这句话如何理解）

Java 并发包提供的读写锁等扩展了锁的能力，它所基于的原理是多个读操作是不需要互斥的，因为读操作并不会更改数据，所以不存在互相干扰。而写操作则会导致并发一致性的问题，所以写线程之间、读写线程之间，需要精心设计的互斥逻辑。

读写锁看起来比 synchronized 的粒度似乎细一些，但在实际应用中，其表现也并不尽如人意，主要还是因为相对比较大的开销。

JDK 在后期引入了 **StampedLock**，在提供类似读写锁的同时，还支持优化读模式。优化读基于假设，大多数情况下读操作并不会和写操作冲突，其逻辑是先试着读，然后通过 validate 方法确认是否进入了写模式，如果没有进入，就成功避免了开销；如果进入，则尝试获取读锁

  2. public class StampedSample {
  3.   private final StampedLock sl = new StampedLock();
  5.   void mutate() {
  6.       long stamp = sl.writeLock();
  7.       try {
  8.           write();
  9.       } finally {
  10.           sl.unlockWrite(stamp);
  11.       }
  12.   }
  14.   Data access() {
  15.       long stamp = sl.tryOptimisticRead();
  16.       Data data = read();
  17.       if (!sl.validate(stamp)) {
  18.           stamp = sl.readLock();
  19.           try {
  20.               data = read();
  21.           } finally {
  22.               sl.unlockRead(stamp);
  23.           }
  24.       }
  25.       return data;
  26.   }
  27.   // …
  28. }

些显式锁的实现机制，Java 并发包内的各种同步工具，不仅仅是各种 Lock，其他的如Semaphore、CountDownLatch，甚至是早期的FutureTask等，都是基于一种 AQS 框架。

看了大家对自旋锁的评论，我的收获如下:
1.基于乐观情况下推荐使用，即锁竞争不强，锁等待时间不长的情况下推荐使用
2.单cpu无效，因为基于cas的轮询会占用cpu,导致无法做线程切换
3.轮询不产生上下文切换，如果可估计到睡眠的时间很长，用互斥锁更好