攻略大全
1. 粘贴攻略
1.1 Java内置锁的核心原理
Java内置锁是一个互斥锁，这就意味着最多只有一个线程能够获得该锁，当线程B尝试去获得线程A持有的内置锁时，线程B必须等待或者阻塞，直到线程A释放这个锁，如果线程A不释放这个锁，那么线程B将永远等待下去。
Java中每个对象都可以用作锁，这些锁称为内置锁。线程进入同步代码块或方法时会自动获得该锁，在退出同步代码块或方法时会释放该锁。获得内置锁的唯一途径就是进入这个锁保护的同步代码块或方法。
1.1.1 线程安全问题
当多个线程并发访问某个Java对象（Object）时，无论系统如何调度这些线程，也无论这些线程将如何交替操作，这个对象都能表现出一致的、正确的行为，那么对这个对象的操作是线程安全的。如果这个对象表现出不一致的、错误的行为，那么对这个对象的操作不是线程安全的，发生了线程的安全问题。
1.1.1.1 自增运算不是线程安全的
1.线程安全小实验
CountDownLatch（倒数闩）是一个非常实用的等待多线程并发的工具类。调用线程可以在倒数闩上进行等待，一直等待倒数闩的次数减少到0，才继续往下执行。每一个被等待的线程执行完成之后进行一次倒数。所有被等待的线程执行完成之后，倒数闩的次数减少到0，调用线程可以往下执行，从而达到并发等待的效果。
2.原因分析：自增运算符不是线程安全的
实际上，一个自增运算符是一个复合操作，至少包括三个JVM指令：“内存取值”“寄存器增加1”和“存值到内存”。这三个指令在JVM内部是独立进行的，中间完全可能会出现多个线程并发进行。
“内存取值”“寄存器增加1”和“存值到内存”这三个JVM指令本身是不可再分的，它们都具备原子性，是线程安全的，也叫原子操作。但是，两个或者两个以上的原子操作合在一起进行操作就不再具备原子性了。比如先读后写，就有可能在读之后，其实这个变量被修改了，出现读和写数据不一致的情况。
1.1.1.2 临界区资源与临界区代码段
临界区资源表示一种可以被多个线程使用的公共资源或共享数据，但是每一次只能有一个线程使用它。一旦临界区资源被占用，想使用该资源的其他线程则必须等待。
在并发情况下，临界区资源是受保护的对象。
临界区代码段（Critical Section）是每个线程中访问临界资源的那段代码，多个线程必须互斥地对临界区资源进行访问。线程进入临界区代码段之前，必须在进入区申请资源，申请成功之后执行临界区代码段，执行完成之后释放资源。
竞态条件（Race Conditions）可能是由于在访问临界区代码段时没有互斥地访问而导致的特殊情况。如果多个线程在临界区代码段的并发执行结果可能因为代码的执行顺序不同而不同，我们就说这时在临界区出现了竞态条件问题。
为了避免竞态条件的问题，我们必须保证临界区代码段操作具备排他性。这就意味着当一个线程进入临界区代码段执行时，其他线程不能进入临界区代码段执行。
在Java中，使用synchronized关键字还可以使用Lock显式锁实例，或者使用原子变量（Atomic Variables）对临界区代码段进行排他性保护。
1.2 synchronized关键字
每个Java对象都隐含有一把锁，这里称为Java内置锁（或者对象锁、隐式锁）。使用synchronized（syncObject）调用相当于获取syncObject的内置锁，所以可以使用内置锁对临界区代码段进行排他性保护。
1.2.1 synchronized同步方法
synchronized关键字是Java的保留字，当使用synchronized关键字修饰一个方法的时候，该方法被声明为同步方法。
在方法声明中设置synchronized同步关键字，保证其方法的代码执行流程是排他性的。任何时间只允许一个线程进入同步方法（临界区代码段），如果其他线程需要执行同一个方法，那么只能等待和排队。
1.2.2 synchronized同步块
将synchronized加在方法上，如果其保护的临界区代码段包含的临界区资源（要求是相互独立的）多于一个，就会造成临界区资源的闲置等待，进而会影响临界区代码段的吞吐量。为了提升吞吐量，可以将synchronized关键字放在函数体内，同步一个代码块。
在synchronized同步块后边的括号中是一个syncObject对象，代表着进入临界区代码段需要获取syncObject对象的监视锁，或者说将syncObject对象监视锁作为临界区代码段的同步锁。由于每一个Java对象都有一把监视锁，因此任何Java对象都能作为synchronized的同步锁。
synchronized方法和synchronized同步块的区别：
synchronized方法是一种粗粒度的并发控制，某一时刻只能有一个线程执行该synchronized方法；
而synchronized代码块是一种细粒度的并发控制，处于synchronized块之外的其他代码是可以被多个线程并发访问的。
在一个方法中，并不一定所有代码都是临界区代码段，可能只有几行代码会涉及线程同步问题。所以synchronized代码块比synchronized方法更加细粒度地控制了多个线程的同步访问。
synchronized方法和synchronized代码块有什么联系呢？
在Java的内部实现上，synchronized方法实际上等同于用一个synchronized代码块，这个代码块包含同步方法中的所有语句，然后在synchronized代码块的括号中传入this关键字，使用this对象锁作为进入临界区的同步锁。
1.2.3 静态的同步方法
Java有两种对象：Object实例对象和Class对象。
每个类运行时的类型信息用Class对象表示，它包含与类名称、继承关系、字段、方法有关的信息。JVM将一个类加载入自己的方法区内存时，会为其创建一个Class对象，对于一个类来说其Class对象是唯一的。
Class类没有公共的构造方法，Class对象是在类加载的时候由Java虚拟机调用类加载器中的defineClass方法自动构造的，因此不能显式地声明一个Class对象。
将Object对象的监视锁叫作对象锁，将Class对象的监视锁叫作类锁。当synchronized关键字修饰static方法时，同步锁为类锁；当synchronized关键字修饰普通的成员方法（非静态方法）时，同步锁为对象锁。
由于类的对象实例可以有很多，但是每个类只有一个Class实例，因此使用类锁作为synchronized的同步锁时会造成同一个JVM内的所有线程只能互斥地进入临界区段。
所以，使用synchronized关键字修饰static方法是非常粗粒度的同步机制。
通过synchronized关键字所抢占的同步锁什么时候释放呢？一种场景是synchronized块（代码块或者方法）正确执行完毕，监视锁自动释放；另一种场景是程序出现异常，非正常退出synchronized块，监视锁也会自动释放。所以，使用synchronized块时不必担心监视锁的释放问题。
1.3 生产者-消费者问题
生产者-消费者问题的关键是：
（1）保证生产者不会在缓冲区满时加入数据，消费者也不会在缓冲区空时消耗数据。
（2）保证在生产者加入过程、消费者消耗过程中，不会产生错误的数据和行为。
在生产者-消费者模式中，至少有以下关键点：
（1）生产者与生产者之间、消费者与消费者之间，对数据缓冲区的操作是并发进行的。
（2）数据缓冲区是有容量上限的。数据缓冲区满后，生产者不能再加入数据；数据缓冲区空时，消费者不能再取出数据。
（3）数据缓冲区是线程安全的。在并发操作数据缓冲区的过程中，不能出现数据不一致的情况；或者在多个线程并发更改共享数据后，不会造成出现脏数据的情况。
（4）生产者或者消费者线程在空闲时需要尽可能阻塞而不是执行无效的空操作，尽量节约CPU资源。
1.4 Java对象结构与内置锁
1.4.1 Java对象结构
Java对象（Object实例）结构包括三部分：对象头、对象体和对齐字节，具体如图所示。
1.Java对象（Object实例）的三部分
（1）对象头
对象头包括三个字段，第一个字段叫作Mark Word（标记字），用于存储自身运行时的数据，例如GC标志位、哈希码、锁状态等信息。
第二个字段叫作Class Pointer（类对象指针），用于存放方法区Class对象的地址，虚拟机通过这个指针来确定这个对象是哪个类的实例。
第三个字段叫作Array Length（数组长度）。如果对象是一个Java数组，那么此字段必须有，用于记录数组长度的数据；如果对象不是一个Java数组，那么此字段不存在，所以这是一个可选字段。
（2）对象体
对象体包含对象的实例变量（成员变量），用于成员属性值，包括父类的成员属性值。这部分内存按4字节对齐。
（3）对齐字节
对齐字节也叫作填充对齐，其作用是用来保证Java对象所占内存字节数为8的倍数。HotSpot VM的内存管理要求对象起始地址必须是8字节的整数倍。对象头本身是8的倍数，当对象的实例变量数据不是8的倍数时，便需要填充数据来保证8字节的对齐。
2.对象结构中核心字段的作用
（1）Mark Word（标记字）字段主要用来表示对象的线程锁状态，另外还可以用来配合GC存放该对象的hashCode。
（2）Class Pointer（类对象指针）字段是一个指向方法区中Class信息的指针，意味着该对象可随时知道自己是哪个Class的实例。
（3）Array Length（数组长度）字段占用32位（在32位JVM中）字节，这是可选的，只有当本对象是一个数组对象时才会有这个部分。
（4）对象体用于保存对象属性值，是对象的主体部分，占用的内存空间大小取决于对象的属性数量和类型。
（5）对齐字节并不是必然存在的，也没有特别的含义，它仅仅起着占位符的作用。当对象实例数据部分没有对齐（8字节的整数倍）时，就需要通过对齐填充来补全。
3.对象结构中的字段长度
Mark Word、Class Pointer、Array Length等字段的长度都与JVM的位数有关。
Mark Word的长度为JVM的一个Word（字）大小，也就是说32位JVM的MarkWord为32位，64位JVM的Mark Word为64位。Class Pointer（类对象指针）字段的长度也为JVM的一个Word（字）大小，即32位JVM的Mark Word为32位，64位JVM的Mark Word为64位。所以，在32位JVM虚拟机中，Mark Word和Class Pointer这两部分都是32位的；在64位JVM虚拟机中，Mark Word和Class Pointer这两部分都是64位的。
对于对象指针而言，如果JVM中的对象数量过多，使用64位的指针将浪费大量内存，通过简单统计，64位JVM将会比32位JVM多耗费50%的内存。为了节约内存可以使用选项+UseCompressedOops开启指针压缩。
UseCompressedOops中的Oop为Ordinary object pointer（普通对象指针）的缩写。如果开启UseCompressedOops选项，以下类型的指针将从64位压缩至32位：
- Class对象的属性指针（静态变量）。
- Object对象的属性指针（成员变量）。
- 普通对象数组的元素指针。
当然，也不是所有的指针都会压缩，一些特殊类型的指针不会压缩，比如指向PermGen（永久代）的Class对象指针（JDK 8中指向元空间的Class对象指针）、本地变量、堆栈元素、入参、返回值和NULL指针等。
在堆内存小于32GB的情况下，64位虚拟机的UseCompressedOops选项是默认开启的，该选项表示开启Oop对象的指针压缩会将原来64位的Oop对象指针压缩为32位。
1.4.2 Mark Word的结构信息
Java内置锁涉及很多重要信息，这些都存放在对象结构中，并且存放于对象头的Mark Word字段中。
Mark Word的位长度不会受到Oop对象指针压缩选项的影响。
Java内置锁的状态总共有4种，级别由低到高依次为：无锁、偏向锁、轻量级锁和重量级锁，并且4种状态会随着竞争的情况逐渐升级，而且是不可逆的过程，即不可降级，也就是说只能进行锁升级（从低级别到高级别）。
1.不同锁状态下的Mark Word字段结构
Mark Word字段的结构与Java内置锁的状态强相关。为了让Mark Word字段存储更多的信息，JVM将Mark Word最低两个位设置为Java内置锁状态位。
不同锁状态下的32位Mark Word结构：
不同锁状态下的64位Mark Word结构：
2.64位Mark Word的构成
（1）lock：锁状态标记位，占两个二进制位，由于希望用尽可能少的二进制位表示尽可能多的信息，因此设置了lock标记。该标记的值不同，整个Mark Word表示的含义就不同。
（2）biased_lock：对象是否启用偏向锁标记，只占1个二进制位。为1时表示对象启用偏向锁，为0时表示对象没有偏向锁。
lock和biased_lock两个标记位组合在一起共同表示Object实例处于什么样的锁状态。二者组合的含义具体如表2-3所示。
（3）age：4位的Java对象分代年龄。在GC中，对象在Survivor区复制一次，年龄就增加1。当对象达到设定的阈值时，将会晋升到老年代。默认情况下，并行GC的年龄阈值为15，并发GC的年龄阈值为6。由于age只有4位，因此最大值为15，这就是-XX:MaxTenuringThreshold选项最大值为15的原因。
（4）identity_hashcode：31位的对象标识HashCode（哈希码）采用延迟加载技术，当调用Object.hashCode()方法或者System.identityHashCode()方法计算对象的HashCode后，其结果将被写到该对象头中。当对象被锁定时，该值会移动到Monitor（监视器）中。
（5）thread：54位的线程ID值为持有偏向锁的线程ID。
（6）epoch：偏向时间戳。
（7）ptr_to_lock_record：占62位，在轻量级锁的状态下指向栈帧中锁记录的指针。
（8）ptr_to_heavyweight_monitor：占62位，在重量级锁的状态下指向对象监视器的指针。
1.4.3 使用JOL工具查看对象的布局
对象一旦生成了哈希码，它就无法进入偏向锁状态。也就是说，只要一个对象已经计算过哈希码，它就无法进入偏向锁状态。当一个对象当前正处于偏向锁状态，并且需要计算其哈希码的话，它的偏向锁会被撤销，并且锁会膨胀为重量级锁。
1.4.4 大小端问题
有关字节序列的存放格式目前有两大阵营：第一大阵营是PowerPC系列CPU，采用大端模式存放数据；第二大阵营是X86系列CPU，采用小端模式存放数据。
（1）大端模式是指数据的高字节保存在内存的低地址中，而数据的低字节保存在内存的高地址中。大端存放模式有点类似于把数据当作字符串顺序处理：地址由小向大增加，而数据从高位往低位放。
（2）小端模式是指数据的高字节保存在内存的高地址中，而数据的低字节保存在内存的低地址中，这种存储模式将地址的高低和数据位权有效地结合起来，高地址部分权值高，低地址部分权值低，此模式和日常的数字计算在方向上是一致的。
举一个例子，如果我们将十六进制数0X1234abcd写入以0x0000开始的内存地址中，两种模式的结果如表2-5所示。
在处理器（即CPU）的计算过程中，因为使用小端模式在数据类型转换的时候（尤其是指针转换）不用考虑地址问题，所以小端模式是处理器的主流字节存放模式。JVM所采用的字节存放模式是小端模式。
由于所有网络协议都是采用大端模式来传输数据的，因此有时也会把大端模式称为“网络字节序”。当两台采用不同字节存放模式的主机通信时，在发送数据之前，都必须经过字节次序转换，转成“网络字节序”（大端模式）后再进行传输。
1.4.5 无锁、偏向锁、轻量级锁和重量级锁
在JDK 1.6版本之前，所有的Java内置锁都是重量级锁。重量级锁会造成CPU在用户态和内核态之间频繁切换，所以代价高、效率低。
JDK 1.6版本为了减少获得锁和释放锁所带来的性能消耗，引入了偏向锁和轻量级锁的实现。所以，在JDK 1.6版本中内置锁一共有4种状态：无锁状态、偏向锁状态、轻量级锁状态和重量级锁状态，这些状态随着竞争情况逐渐升级。
内置锁可以升级但不能降级，意味着偏向锁升级成轻量级锁后不能再降级成偏向锁。这种能升级却不能降级的策略，其目的是提高获得锁和释放锁的效率。
1.无锁状态
Java对象刚创建时还没有任何线程来竞争，说明该对象处于无锁状态（无线程竞争它），这时偏向锁标识位是0，锁状态是01。无锁状态下对象的Mark Word如图2-7所示。
2.偏向锁状态
偏向锁是指一段同步代码一直被同一个线程所访问，那么该线程会自动获取锁，降低获取锁的代价。如果内置锁处于偏向状态，当有一个线程来竞争锁时，先用偏向锁，表示内置锁偏爱这个线程，这个线程要执行该锁关联的同步代码时，不需要再做任何检查和切换。偏向锁在竞争不激烈的情况下效率非常高。
偏向锁状态的Mark Word会记录内置锁自己偏爱的线程ID，内置锁会将该线程当作自己的熟人。偏向锁状态下对象的MarkWord如图2-8所示。
3.轻量级锁状态
当有两个线程开始竞争这个锁对象时，情况就发生变化了，不再是偏向（独占）锁了，锁会升级为轻量级锁，两个线程公平竞争，哪个线程先占有锁对象，锁对象的Mark Word就指向哪个线程的栈帧中的锁记录。轻量级锁状态下对象的Mark Word如图2-9所示。
当锁处于偏向锁，又被另一个线程企图抢占时，偏向锁就会升级为轻量级锁。企图抢占的线程会通过自旋的形式尝试获取锁，不会阻塞抢锁线程，以便提高性能。
自旋原理非常简单，如果持有锁的线程能在很短时间内释放锁资源，那么那些等待竞争锁的线程就不需要进行内核态和用户态之间的切换来进入阻塞挂起状态，它们只需要等一等（自旋），等持有锁的线程释放锁后即可立即获取锁，这样就避免了用户态和内核态切换的消耗。
但是，线程自旋是需要消耗CPU的，如果一直获取不到锁，那么线程也不能一直占用CPU自旋做无用功，所以需要设定一个自旋等待的最大时间。 JVM对于自旋周期的选择，JDK 1.6之后引入了适应性自旋锁，适应性自旋锁意味着自旋的时间不是固定的，而是由前一次在同一个锁上的自旋时间以及锁的拥有者的状态来决定的。线程如果自旋成功了，下次自旋的次数就会更多，如果自旋失败了，自旋的次数就会减少。
如果持有锁的线程执行的时间超过自旋等待的最大时间仍没有释放锁，就会导致其他争用锁的线程在最大等待时间内还是获取不到锁，自旋不会一直持续下去，这时争用线程会停止自旋进入阻塞状态，该锁膨胀为重量级锁。
4.重量级锁状态
重量级锁会让其他申请的线程之间进入阻塞，性能降低。重量级锁也叫同步锁，这个锁对象Mark Word再次发生变化，会指向一个监视器对象，该监视器对象用集合的形式来登记和管理排队的线程。重量级锁状态下对象的Mark Word如图2-10所示。
1.5 偏向锁的原理
偏向锁主要解决无竞争下的锁性能问题，所谓的偏向就是偏心，即锁会偏向于当前已经占有锁的线程。
1.5.1 偏向锁的核心原理
偏向锁的核心原理是：如果不存在线程竞争的一个线程获得了锁，那么锁就进入偏向状态，此时Mark Word的结构变为偏向锁结构，锁对象的锁标志位（lock）被改为01，偏向标志位（biased_lock）被改为1，然后线程的ID记录在锁对象的MarkWord中（使用CAS操作完成）。以后该线程获取锁时判断一下线程ID和标志位，就可以直接进入同步块，连CAS操作都不需要，这样就省去了大量有关锁申请的操作，从而也就提升了程序的性能。
偏向锁的主要作用是消除无竞争情况下的同步原语，进一步提升程序性能，所以，在没有锁竞争的场合，偏向锁有很好的优化效果。但是，一旦有第二条线程需要竞争锁，那么偏向模式立即结束，进入轻量级锁的状态。
假如在大部分情况下同步块是没有竞争的，那么可以通过偏向来提高性能。即在无竞争时，之前获得锁的线程再次获得锁时会判断偏向锁的线程ID是否指向自己，如果是，那么该线程将不用再次获得锁，直接就可以进入同步块；如果未指向当前线程，当前线程就会采用CAS操作将Mark Word中的线程ID设置为当前线程ID，如果CAS操作成功，那么获取偏向锁成功，执行同步代码块，如果CAS操作失败，那么表示有竞争，抢锁线程被挂起，撤销占锁线程的偏向锁，然后将偏向锁膨胀为轻量级锁。
偏向锁的缺点：如果锁对象时常被多个线程竞争，偏向锁就是多余的，并且其撤销的过程会带来一些性能开销。
1.5.2 偏向锁的膨胀和撤销
假如有多个线程来竞争偏向锁，此对象锁已经有所偏向，其他的线程发现偏向锁并不是偏向自己，就说明存在了竞争，尝试撤销偏向锁（很可能引入安全点），然后膨胀到轻量级锁。
1.偏向锁的撤销
偏向锁撤销的开销花费还是挺大的，其大概过程如下：
（1）在一个安全点停止拥有锁的线程。
（2）遍历线程的栈帧，检查是否存在锁记录。如果存在锁记录，就需要清空锁记录，使其变成无锁状态，并修复锁记录指向的Mark Word，清除其线程ID。
（3）将当前锁升级成轻量级锁。
（4）唤醒当前线程。
所以，如果某些临界区存在两个及两个以上的线程竞争，那么偏向锁反而会降低性能。在这种情况下，可以在启动JVM时就把偏向锁的默认功能关闭。
撤销偏向锁的条件：
（1）多个线程竞争偏向锁。
（2）调用偏向锁对象的hashcode()方法或者System.identityHashCode()方法计算对象的HashCode之后，将哈希码放置到Mark Word中，内置锁变成无锁状态，偏向锁将被撤销。
2.偏向锁的膨胀
如果偏向锁被占据，一旦有第二个线程争抢这个对象，因为偏向锁不会主动释放，所以第二个线程可以看到内置锁偏向状态，这时表明在这个对象锁上已经存在竞争了。JVM检查原来持有该对象锁的占有线程是否依然存活，如果挂了，就可以将对象变为无锁状态，然后进行重新偏向，偏向为抢锁线程。
如果JVM检查到原来的线程依然存活，就进一步检查占有线程的调用堆栈是否通过锁记录持有偏向锁。如果存在锁记录，就表明原来的线程还在使用偏向锁，发生锁竞争，撤销原来的偏向锁，将偏向锁膨胀（INFLATING）为轻量级锁。
3.偏向锁的好处
经验表明，其实大部分情况下进入一个同步代码块的线程都是同一个线程。这也是JDK会引入偏向锁的原因。所以，总体来说，使用偏向锁带来的好处还是大于偏向锁撤销和膨胀所带来的代价。
1.6 轻量级锁的原理
引入轻量级锁的主要目的是在多线程竞争不激烈的情况下，通过CAS机制竞争锁减少重量级锁产生的性能损耗。重量级锁使用了操作系统底层的互斥锁（Mutex Lock），会导致线程在用户态和核心态之间频繁切换，从而带来较大的性能损耗。
1.6.1 轻量级锁的核心原理
轻量锁存在的目的是尽可能不动用操作系统层面的互斥锁，因为其性能比较差。线程的阻塞和唤醒需要CPU从用户态转为核心态，频繁地阻塞和唤醒对CPU来说是一件负担很重的工作。同时我们可以发现，很多对象锁的锁定状态只会持续很短的一段时间，例如整数的自加操作，在很短的时间内阻塞并唤醒线程显然不值得，为此引入了轻量级锁。轻量级锁是一种自旋锁，因为JVM本身就是一个应用，所以希望在应用层面上通过自旋解决线程同步问题。
轻量级锁的执行过程：在抢锁线程进入临界区之前，如果内置锁（临界区的同步对象）没有被锁定，JVM首先将在抢锁线程的栈帧中建立一个锁记录（Lock Record），用于存储对象目前Mark Word的拷贝，这时的线程堆栈与内置锁对象头大致如图2-11所示。
然后抢锁线程将使用CAS自旋操作，尝试将内置锁对象头的Mark Word的ptr_to_lock_record（锁记录指针）更新为抢锁线程栈帧中锁记录的地址，如果这个更新执行成功了，这个线程就拥有了这个对象锁。然后JVM将Mark Word中的lock标记位改为00（轻量级锁标志），即表示该对象处于轻量级锁状态。抢锁成功之后，JVM会将Mark Word中原来的锁对象信息（如哈希码等）保存在抢锁线程锁记录的Displaced Mark Word（可以理解为放错地方的Mark Word）字段中，再将抢锁线程中锁记录的owner指针指向锁对象。
在轻量级锁抢占成功之后，锁记录和对象头的状态如图2-12所示。
锁记录是线程私有的，每个线程都有自己的一份锁记录，在创建完锁记录后，会将内置锁对象的Mark Word复制到锁记录的Displaced Mark Word字段。这是为什么呢？因为内置锁对象的Mark Word的结构会有所变化，Mark Word将会出现一个指向锁记录的指针，而不再存着无锁状态下的锁对象哈希码等信息，所以必须将这些信息暂存起来，供后面在锁释放时使用。
1.6.2 轻量级锁的分类
轻量级锁主要有两种：普通自旋锁和自适应自旋锁。
1.普通自旋锁
所谓普通自旋锁，就是指当有线程来竞争锁时，抢锁线程会在原地循环等待，而不是被阻塞，直到那个占有锁的线程释放锁之后，这个抢锁线程才可以获得锁。
锁在原地循环等待的时候是会消耗CPU的，就相当于在执行一个什么也不干的空循环。所以轻量级锁适用于临界区代码耗时很短的场景，这样线程在原地等待很短的时间就能够获得锁了。
默认情况下，自旋的次数为10次，用户可以通过-XX:PreBlockSpin选项来进行更改。
2.自适应自旋锁
所谓自适应自旋锁，就是等待线程空循环的自旋次数并非是固定的，而是会动态地根据实际情况来改变自旋等待的次数，自旋次数由前一次在同一个锁上的自旋时间及锁的拥有者的状态来决定。自适应自旋锁的大概原理是：
（1）如果抢锁线程在同一个锁对象上之前成功获得过锁，JVM就会认为这次自旋很有可能再次成功，因此允许自旋等待持续相对更长的时间。
（2）如果对于某个锁，抢锁线程很少成功获得过，那么JVM将可能减少自旋时间甚至省略自旋过程，以避免浪费处理器资源。
自适应自旋解决的是“锁竞争时间不确定”的问题。自适应自旋假定不同线程持有同一个锁对象的时间基本相当，竞争程度趋于稳定。总的思想是：根据上一次自旋的时间与结果调整下一次自旋的时间。
JDK 1.6的轻量级锁使用的是普通自旋锁，且需要使用-XX:+UseSpinning选项手工开启。JDK 1.7后，轻量级锁使用自适应自旋锁，JVM启动时自动开启，且自旋时间由JVM自动控制。
轻量级锁也被称为非阻塞同步、乐观锁，因为这个过程并没有把线程阻塞挂起，而是让线程空循环等待。
1.6.3 轻量级锁的膨胀
轻量级锁的问题在哪里呢？虽然大部分临界区代码的执行时间都是很短的，但是也会存在执行得很慢的临界区代码。临界区代码执行耗时较长，在其执行期间，其他线程都在原地自旋等待，会空消耗CPU。因此，如果竞争这个同步锁的线程很多，就会有多个线程在原地等待继续空循环消耗CPU（空自旋），这会带来很大的性能损耗。
轻量级锁的本意是为了减少多线程进入操作系统底层的互斥锁（Mutex Lock）的概率，并不是要替代操作系统互斥锁。所以，在争用激烈的场景下，轻量级锁会膨胀为基于操作系统内核互斥锁实现的重量级锁。
1.7 重量级锁的原理
在JVM中，每个对象都关联一个监视器，这里的对象包含Object实例和Class实例。监视器是一个同步工具，相当于一个许可证，拿到许可证的线程即可进入临界区进行操作，没有拿到则需要阻塞等待。重量级锁通过监视器的方式保障了任何时间只允许一个线程通过受到监视器保护的临界区代码。
1.7.1 重量级锁的核心原理
JVM中每个对象都会有一个监视器，监视器和对象一起创建、销毁。监视器相当于一个用来监视这些线程进入的特殊房间，其义务是保证（同一时间）只有一个线程可以访问被保护的临界区代码块。
本质上，监视器是一种同步工具，也可以说是一种同步机制，主要特点是：
（1）同步。监视器所保护的临界区代码是互斥地执行的。一个监视器是一个运行许可，任一线程进入临界区代码都需要获得这个许可，离开时把许可归还。
（2）协作。监视器提供Signal机制，允许正持有许可的线程暂时放弃许可进入阻塞等待状态，等待其他线程发送Signal去唤醒；其他拥有许可的线程可以发送Signal，唤醒正在阻塞等待的线程，让它可以重新获得许可并启动执行。
在Hotspot虚拟机中，监视器是由C++类ObjectMonitor实现的，ObjectMonitor类定义在ObjectMonitor.hpp文件中。
Cxq、EntryList、WaitSet这三个队列的说明如下：
（1）Cxq：竞争队列（Contention Queue），所有请求锁的线程首先被放在这个竞争队列中。
（2）EntryList：Cxq中那些有资格成为候选资源的线程被移动到EntryList中。
（3）WaitSet：某个拥有ObjectMonitor的线程在调用Object.wait()方法之后将被阻塞，然后该线程将被放置在WaitSet链表中。
1.Cxq
Cxq并不是一个真正的队列，只是一个虚拟队列，原因在于Cxq是由Node及其next指针逻辑构成的，并不存在一个队列的数据结构。每次新加入Node会在Cxq的队头进行，通过CAS改变第一个节点的指针为新增节点，同时设置新增节点的next指向后续节点；从Cxq取得元素时，会从队尾获取。显然，Cxq结构是一个无锁结构。
因为只有Owner线程才能从队尾取元素，即线程出列操作无争用，当然也就避免了CAS的ABA问题。
在线程进入Cxq前，抢锁线程会先尝试通过CAS自旋获取锁，如果获取不到，就进入Cxq队列，这明显对于已经进入Cxq队列的线程是不公平的。所以，synchronized同步块所使用的重量级锁是不公平锁。
2.EntryList
EntryList与Cxq在逻辑上都属于等待队列。Cxq会被线程并发访问，为了降低对Cxq队尾的争用，而建立EntryList。在Owner线程释放锁时，JVM会从Cxq中迁移线程到EntryList，并会指定EntryList中的某个线程（一般为Head）为OnDeck Thread（Ready Thread）。EntryList中的线程作为候选竞争线程而存在。
3.OnDeck Thread与Owner Thread
JVM不直接把锁传递给Owner Thread，而是把锁竞争的权利交给OnDeck Thread，OnDeck需要重新竞争锁。这样虽然牺牲了一些公平性，但是能极大地提升系统的吞吐量，在JVM中，也把这种选择行为称为“竞争切换”。
OnDeck Thread获取到锁资源后会变为Owner Thread。无法获得锁的OnDeck Thread则会依然留在EntryList中，考虑到公平性，OnDeck Thread在EntryList中的位置不发生变化（依然在队头）。
在OnDeck Thread成为Owner的过程中，还有一个不公平的事情，就是后来的新抢锁线程可能直接通过CAS自旋成为Owner而抢到锁。
4.WaitSet
如果Owner线程被Object.wait()方法阻塞，就转移到WaitSet队列中，直到某个时刻通过Object.notify()或者Object.notifyAll()唤醒，该线程就会重新进入EntryList中。
1.7.2 重量级锁的开销
处于ContentionList、EntryList、WaitSet中的线程都处于阻塞状态，线程的阻塞或者唤醒都需要操作系统来帮忙，Linux内核下采用pthread_mutex_lock系统调用实现，进程需要从用户态切换到内核态。
Linux系统的内核是一组特殊的软件程序，负责控制计算机的硬件资源，例如协调CPU资源、分配内存资源，并且提供稳定的环境供应用程序运行。
应用程序的活动空间为用户空间，应用程序的执行必须依托于内核提供的资源，包括CPU资源、存储资源、I/O资源等。
用户态与内核态有各自专用的内存空间、专用的寄存器等，进程从用户态切换至内核态需要传递许多变量、参数给内核，内核也需要保护好用户态在切换时的一些寄存器值、变量等，以便内核态调用结束后切换回用户态继续工作。
用户态的进程能够访问的资源受到了极大的控制，而运行在内核态的进程可以“为所欲为”。一个进程可以运行在用户态，也可以运行在内核态，那么肯定存在用户态和内核态切换的过程。进程从用户态到内核态切换主要包括以下三种方式：
（1）硬件中断。硬件中断也称为外设中断，当外设完成用户的请求时会向CPU发送中断信号。
（2）系统调用。其实系统调用本身就是中断，只不过是软件中断，跟硬件中断不同。
（3）异常。如果当前进程运行在用户态，这个时候发生了异常事件（例如缺页异常），就会触发切换。
用户态是应用程序运行的空间，为了能访问到内核管理的资源（例如CPU、内存、I/O），可以通过内核态所提供的访问接口实现，这些接口就叫系统调用。pthread_mutex_lock系统调用是内核态为用户态进程提供的Linux内核态下互斥锁的访问机制，所以使用pthread_mutex_lock系统调用时，进程需要从用户态切换到内核态，而这种切换是需要消耗很多时间的，有可能比用户执行代码的时间还要长。
**由于JVM轻量级锁使用CAS进行自旋抢锁，这些CAS操作都处于用户态下，进程不存在用户态和内核态之间的运行切换，因此JVM轻量级锁开销较小。而JVM重量级锁使用了Linux内核态下的互斥锁，这是重量级锁开销很大的原因。 **
1.8 偏向锁、轻量级锁与重量级锁的对比
总结一下synchronized的执行过程，大致如下：
（1）线程抢锁时，JVM首先检测内置锁对象Mark Word中的biased_lock（偏向锁标识）是否设置成1，lock（锁标志位）是否为01，如果都满足，确认内置锁对象为可偏向状态。
（2）在内置锁对象确认为可偏向状态之后，JVM检查MarkWord中的线程ID是否为抢锁线程ID，如果是，就表示抢锁线程处于偏向锁状态，抢锁线程快速获得锁，开始执行临界区代码。
（3）如果Mark Word中的线程ID并未指向抢锁线程，就通过CAS操作竞争锁。如果竞争成功，就将Mark Word中的线程ID设置为抢锁线程，偏向标志位设置为1，锁标志位设置为01，然后执行临界区代码，此时内置锁对象处于偏向锁状态。
（4）如果CAS操作竞争失败，就说明发生了竞争，撤销偏向锁，进而升级为轻量级锁。
（5）JVM使用CAS将锁对象的Mark Word替换为抢锁线程的锁记录指针，如果成功，抢锁线程就获得锁。如果替换失败，就表示其他线程竞争锁，JVM尝试使用CAS自旋替换抢锁线程的锁记录指针，如果自旋成功（抢锁成功），那么锁对象依然处于轻量级锁状态。
（6）如果JVM的CAS替换锁记录指针自旋失败，轻量级锁就膨胀为重量级锁，后面等待锁的线程也要进入阻塞状态。
总体来说，偏向锁是在没有发生锁争用的情况下使用的；一旦有了第二个线程争用锁，偏向锁就会升级为轻量级锁；如果锁争用很激烈，轻量级锁的CAS自旋到达阈值后，轻量级锁就会升级为重量级锁。
