14-线程安全与锁优化
1. 线程安全说明
1.1 定义
笔者认为《Java 并发编程实战（Java Concurrency In Practice）》的作者 Brian Goetz 为“线程安全”做出了一个比较恰当的定义：
“当多个线程同时访问一个对象时，如果不用考虑这些线程在运行时环境下的调度和交替执行，也不需要进行额外的同步，或者在调用方进行任何其他的协调操作，调用这个对象的行为都可以获得正确的结果，那就称这个对象是线程安全的。”
这个定义就很严谨而且有可操作性，它要求线程安全的代码都必须具备一个共同特征：代码本身封装了所有必要的正确性保障手段（如互斥同步等），令调用者无须关心多线程下的调用问题，更无须自己实现任何措施来保证多线程环境下的正确调用。这点听起来简单，但其实并不容易做到，在许多场景中，我们都会将这个定义弱化一些。
如果把“调用这个对象的行为”限定为“单次调用”，这个定义的其他描述能够成立的话，那么就已经可以称它是线程安全了。为什么要弱化这个定义？现在先暂且放下这个问题，稍后再详细探讨。
1.2 Java 线程安全
在 Java 语言中，线程安全具体是如何体现的？有哪些操作是线程安全的？
我们这里讨论的线程安全，将以多个线程之间存在共享数据访问为前提。因为如果根本不存在多线程，又或者一段代码根本不会与其他线程共享数据，那么从线程安全的角度上看，程序是串行执行还是多线程执行对它来说是没有什么区别的。
为了更深入地理解线程安全，在这里我们可以不把线程安全当作一个非真即假的二元排他选项来看待，而是按照线程安全的“安全程度”由强至弱来排序，我们可以将 Java 语言中各种操作共享的数据分为以下 5 类：不可变、绝对线程安全、相对线程安全、线程兼容和线程对立。
1.2.1 不可变
在 Java 语言里面，不可变（Immutable）的对象一定是线程安全的，无论是对象的方法实现还是方法的调用者，都不需要再进行任何线程安全保障措施。在第 10 章里我们讲解“final 关键字带来的可见性”时曾经提到过这一点：只要一个不可变的对象被正确地构建出来（即没有发生 this 引用逃逸的情况），那其外部的可见状态永远都不会改变，永远都不会看到它在多个线程之中处于不一致的状态。“不可变”带来的安全性是最直接、最纯粹的。
Java 语言中，如果多线程共享的数据是一个基本数据类型，那么只要在定义时使用 final 关键字修饰它就可以保证它是不可变的。
如果共享数据是一个对象，由于 Java 语言目前暂时还没有提供值类型的支持，那就需要对象自行保证其行为不会对其状态产生任何影响才行。如果读者没想明白这句话所指的意思，不妨类比 java.lang.String 类的对象实例，它是一个典型的不可变对象，用户调用它的 substring()、replace() 和 concat() 这些方法都不会影响它原来的值，只会返回一个新构造的字符串对象。
保证对象行为不影响自己状态的途径有很多种，最简单的一种就是把对象里面带有状态的变量都声明为 final，这样在构造函数结束之后，它就是不可变的，例如 java.lang.Integer 构造函数，它通过将内部状态变量 value 定义为 final 来保障状态不变。
1.2.2 绝对线程安全
绝对的线程安全能够完全满足 Brian Goetz 给出的线程安全的定义，这个定义其实是很严格的，一个类要达到“不管运行时环境如何，调用者都不需要任何额外的同步措施”可能需要付出非常高昂的，甚至不切实际的代价。
在 Java API 中标注自己是线程安全的类，大多数都不是绝对的线程安全。我们可以通过 Java API 中一个不是“绝对线程安全”的“线程安全类型”来看看这个语境里的“绝对”究竟是什么意思。
如果说 java.util.Vector 是一个线程安全的容器，相信所有的 Java 程序员对此都不会有异议，因为它的 add()、get() 和 size() 等方法都是被 synchronized 修饰的，尽管这样效率不高，但保证了具备原子性、可见性和有序性。不过，即使它所有的方法都被修饰成 synchronized，也不意味着调用它的时候就永远都不再需要同步手段了，请看看如下测试代码。
private static Vector<Integer> vector = new Vector<Integer>();
public static void main(String[] args) {
while (true) {
for (int i = 0; i < 10; i++) {
vector.add(i);
}
Thread removeThread = new Thread(new Runnable() {
@Override
public void run() {
for (int i = 0; i < vector.size(); i++) {
vector.remove(i);
}
}
});
Thread printThread = new Thread(new Runnable() {
@Override
public void run() {
for (int i = 0; i < vector.size(); i++) {
System.out.println((vector.get(i)));
}
}
});
removeThread.start();
printThread.start();
// 不要同时产生过多的线程，否则会导致操作系统假死
while (Thread.activeCount() > 20);
}
}
运行结果如下：
Exception in thread "Thread-132" java.lang.ArrayIndexOutOfBoundsException:
Array index out of range: 17
at java.util.Vector.remove(Vector.java:777)
at org.fenixsoft.mulithread.VectorTest$1.run(VectorTest.java:21)
at java.lang.Thread.run(Thread.java:662)
很明显，尽管这里使用到的 Vector 的 get()、remove() 和 size() 方法都是同步的，但是在多线程的环境中，如果不在方法调用端做额外的同步措施，使用这段代码仍然是不安全的。因为如果另一个线程恰好在错误的时间里删除了一个元素，导致序号 i 已经不再可用，再用 i 访问数组就会抛出一个 ArrayIndexOutOfBoundsException。如果要保证这段代码能正确执行下去，我们不得不把 removeThread 和 printThread 的定义改成如下所示的这样。
Thread removeThread = new Thread(new Runnable() {
@Override
public void run() {
synchronized (vector) {
for (int i = 0; i < vector.size(); i++) {
vector.remove(i);
}
}
}
});
// ===== 必须加入同步保证Vector访问的线程安全性 =====
Thread printThread = new Thread(new Runnable() {
@Override
public void run() {
synchronized (vector) {
for (int i = 0; i < vector.size(); i++) {
System.out.println((vector.get(i)));
}
}
}
});
假如 Vector 一定要做到绝对的线程安全，那就必须在它内部维护一组一致性的快照访问才行，每次对其中元素进行改动都要产生新的快照，这样要付出的时间和空间成本都是非常大的。
1.2.3 相对线程安全
相对线程安全就是我们通常意义上所讲的线程安全，它需要保证对这个对象单次的操作是线程安全的，我们在调用的时候不需要进行额外的保障措施，但是对于一些特定顺序的连续调用，就可能需要在调用端使用额外的同步手段来保证调用的正确性。
在 Java 语言中，大部分声称线程安全的类都属于这种类型，例如 Vector、HashTable、Collections 的 synchronizedCollection() 方法包装的集合等。
1.2.4 线程兼容
线程兼容是指对象本身并不是线程安全的，但是可以通过在调用端正确地使用同步手段来保证对象在并发环境中可以安全地使用。我们平常说一个类不是线程安全的，通常就是指这种情况。Java 类库 API 中大部分的类都是线程兼容的，如与前面的 Vector 和 HashTable 相对应的集合类 ArrayList 和 HashMap 等。
1.2.5 线程对立
线程对立是指不管调用端是否采取了同步措施，都无法在多线程环境中并发使用代码。由于 Java 语言天生就支持多线程的特性，线程对立这种排斥多线程的代码是很少出现的，而且通常都是有害的，应当尽量避免。
一个线程对立的例子是 Thread 类的 suspend() 和 resume() 方法。如果有两个线程同时持有一个线程对象，一个尝试去中断线程，一个尝试去恢复线程，在并发进行的情况下，无论调用时是否进行了同步，目标线程都存在死锁风险——假如 suspend() 中断的线程就是即将要执行 resume() 的那个线程，那就肯定要产生死锁了。也正是这个原因，suspend() 和 resume() 方法都已经被声明废弃了。常见的线程对立的操作还有 System.setIn()、Sytem.setOut() 和 System.runFinalizersOnExit() 等。
2. 线程安全的实现方法
了解过什么是线程安全之后，紧接着的一个问题就是我们应该如何实现线程安全。
2.1 互斥（阻塞）同步
互斥同步（Mutual Exclusion & Synchronization）是一种最常见也是最主要的并发正确性保障手段。
同步是指在多个线程并发访问共享数据时，保证共享数据在同一个时刻只被一条（或者是一些，当使用信号量的时候）线程使用。而互斥是实现同步的一种手段，临界区（Critical Section）、互斥量（Mutex）和信号量（Semaphore）都是常见的互斥实现方式。
因此在“互斥同步”这四个字里面，互斥是因，同步是果；互斥是方法，同步是目的。
2.1.1 synchronized
在 Java 里面，最基本的互斥同步手段就是 synchronized 关键字，这是一种块结构（Block Structured）的同步语法。
synchronized 关键字经过 Javac 编译之后，会在同步块的前后分别形成 monitorenter 和 monitorexit 这两个字节码指令。这两个字节码指令都需要一个 reference 类型的参数来指明要锁定和解锁的对象。
如果 Java 源码中的 synchronized 明确指定了对象参数，那就以这个对象的引用作为 reference；如果没有明确指定，那将根据 synchronized 修饰的方法类型（如实例方法或类方法），来决定是取代码所在的对象实例还是取类型对应的 Class 对象来作为线程要持有的锁。
根据《Java虚拟机规范》的要求，在执行 monitorenter 指令时，首先要去尝试获取对象的锁。
- 如果这个对象没被锁定，或者当前线程已经持有了那个对象的锁，就把锁的计数器的值增加一，而在执行 monitorexit 指令时会将锁计数器的值减一。一旦计数器的值为零，锁随即就被释放了。
- 如果获取对象锁失败，那当前线程就应当被阻塞等待，直到请求锁定的对象被持有它的线程释放为止。
从功能上看，根据以上《Java虚拟机规范》对 monitorenter 和 monitorexit 的行为描述，我们可以得出两个关于 synchronized 的直接推论，这是使用它时需特别注意的：
- 被 synchronized 修饰的同步块对同一条线程来说是可重入的。这意味着同一线程反复进入同步块也不会出现自己把自己锁死的情况。
- 被 synchronized 修饰的同步块在持有锁的线程执行完毕并释放锁之前，会无条件地阻塞后面其他线程的进入。这意味着无法像处理某些数据库中的锁那样，强制已获取锁的线程释放锁；也无法强制正在等待锁的线程中断等待或超时退出。
从执行成本的角度看，持有锁是一个重量级（Heavy-Weight）的操作。
在主流 Java 虚拟机实现中，Java 的线程是映射到操作系统的原生内核线程之上的，如果要阻塞或唤醒一条线程，则需要操作系统来帮忙完成，这就不可避免地陷入用户态到核心态的转换中，进行这种状态转换需要耗费很多的处理器时间。尤其是对于代码特别简单的同步块（譬如被 synchronized 修饰的 getter() 或 setter() 方法），状态转换消耗的时间甚至会比用户代码本身执行的时间还要长。因此才说，synchronized 是 Java 语言中一个重量级的操作。
有经验的程序员都只会在确实必要的情况下才使用这种操作。而虚拟机本身也会进行一些优化，譬如在通知操作系统阻塞线程之前加入一段自旋等待过程，以避免频繁地切入核心态之中。
2.1.2 Lock
从上面的介绍中我们可以看到 synchronized 的局限性，除了 synchronized 关键字以外，自 JDK 5 起（实现了 JSR 166），Java 类库中新提供了 java.util.concurrent 包（下文称 J.U.C 包），其中的 java.util.concurrent.locks.Lock 接口便成了 Java 的另一种全新的互斥同步手段。
基于 Lock 接口，用户能够以非块结构（Non-Block Structured）来实现互斥同步，从而摆脱了语言特性的束缚，改为在类库层面去实现同步。
重入锁（ReentrantLock）是 Lock 接口最常见的一种实现，顾名思义，它与 synchronized 一样是可重入的。在基本用法上，ReentrantLock 也与 synchronized 很相似，只是代码写法上稍有区别而已。不过，ReentrantLock 与 synchronized 相比增加了一些高级功能，主要有以下 3 项：等待可中断、可实现公平锁及锁可以绑定多个条件。
- 等待可中断：是指当持有锁的线程长期不释放锁的时候，正在等待的线程可以选择放弃等待，改为处理其他事情。可中断特性对处理执行时间非常长的同步块很有帮助。
- 公平锁：是指多个线程在等待同一个锁时，必须按照申请锁的时间顺序来依次获得锁；而非公平锁则不保证这一点，在锁被释放时，任何一个等待锁的线程都有机会获得锁。synchronized 中的锁是非公平的，ReentrantLock 在默认情况下也是非公平的，但可以通过带布尔值的构造函数要求使用公平锁。不过一旦使用了公平锁，将会导致 ReentrantLock 的性能急剧下降，会明显影响吞吐量。
- 锁绑定多个条件：是指一个 ReentrantLock 对象可以同时绑定多个 Condition 对象。在 synchronized 中，锁对象的 wait() 跟它的 notify()/notifyAll() 方法配合可以实现一个隐含的条件；如果要和多于一个的条件关联的时候，就不得不额外添加一个锁；而 ReentrantLock 则无须这样做，多次调用 newCondition() 方法即可。
如果需要使用上述功能，使用 ReentrantLock 是一个很好的选择，那如果是基于性能考虑呢？synchronized 对性能的影响，尤其在 JDK 5 之前是很显著的（如下图）。
从上图中可以看出，多线程环境下 synchronized 的吞吐量下降得非常严重，而 ReentrantLock 则能基本保持在同一个相对稳定的水平上。但与其说 ReentrantLock 性能好，倒不如说当时的 synchronized 有非常大的优化余地，后续的技术发展也证明了这一点。当 JDK 6 中加入了大量针对 synchronized 锁的优化措施（下一节我们就会讲解这些优化措施）之后，相同的测试中就发现 synchronized 与 ReentrantLock 的性能基本上能够持平。相信现在阅读本书的读者所开发的程序应该都是使用 JDK 6 或以上版本来部署的，所以性能已经不再是选择 synchronized 或者 ReentrantLock 的决定因素。
根据上面的讨论，ReentrantLock 在功能上是 synchronized 的超集，在性能上又至少不会弱于 synchronized，那 synchronized 修饰符是否应该被直接抛弃，不再使用了呢？当然不是，基于以下理由，笔者仍然推荐在 synchronized 与 ReentrantLock 都可满足需要时优先使用 synchronized：
- synchronized 是在 Java 语法层面的同步，足够清晰，也足够简单。每个 Java 程序员都熟悉 synchronized，但 J.U.C 中的 Lock 接口则并非如此。因此在只需要基础的同步功能，更推荐synchronized。
- Lock 应该确保在 finally 块中释放锁，否则一旦受同步保护的代码块中抛出异常，则有可能永远不会释放持有的锁。这一点必须由程序员自己来保证，而使用 synchronized 的话则可以由 Java 虚拟机来确即使出现异常，锁也能被自动释放。
- 尽管在 JDK 5 时代 ReentrantLock 曾经在性能上领先过 synchronized，但这已经是十多年之前的胜利了。从长远来看，Java 虚拟机更容易针对 synchronized 来进行优化，因为 Java 虚拟机可以在线程和对象的元数据中记录 synchronized 中锁的相关信息，而使用 J.U.C 中的 Lock 的话，Java 虚拟机是很难得知具体哪些锁对象是由特定线程锁持有的。
2.2 非阻塞同步
2.2.1 引入 CAS
互斥同步面临的主要问题是进行线程阻塞和唤醒所带来的性能开销，因此这种同步也被称为「阻塞同步 (Blocking Synchronization)」。
从解决问题的方式上看，互斥同步属于一种“悲观”的并发策略，其总是认为只要不去做正确的同步措施（例如加锁），那就肯定会出现问题，无论共享的数据是否真的会出现竞争，它都会进行加锁（这里讨论的是概念模型，实际上虚拟机会优化掉很大一部分不必要的加锁），这将会导致用户态到核心态转换、维护锁计数器和检查是否有被阻塞的线程需要被唤醒等开销。
随着〈硬件指令集〉的发展，我们已经有了另外一个选择：基于冲突检测的“乐观”并发策略，通俗地说就是不管风险，先进行操作！不怕别的线程来修改共享变量，就算改了也没关系，我吃亏点再重试呗 ~
- 如果没有其他线程争用共享数据，那操作就直接成功了；
- 如果共享的数据的确被争用，产生了冲突，那再进行其他的补偿措施，最常用的补偿措施是不断地重试，直到出现没有竞争的共享数据为止。
这种乐观并发策略的实现不再需要把线程阻塞挂起，因此这种同步操作被称为「非阻塞同步 (Non-Blocking Synchronization)」，使用这种措施的代码也常被称为无锁（Lock-Free）编程。
为什么笔者说使用乐观并发策略需要“硬件指令集的发展”？因为我们必须要求「操作」和「冲突检测」这两个步骤具备原子性！
靠什么来保证原子性？如果这里再使用互斥同步来保证就完全失去意义了，所以我们只能靠硬件来实现这件事情，硬件保证某些从语义上看起来需要多次操作的行为可以只通过一条处理器指令就能完成，这类指令常用的有：
- 测试并设置（Test-and-Set）；
- 获取并增加（Fetch-and-Increment）；
- 交换（Swap）；
- 比较并交换（Compare-and-Swap，下文称 CAS）；
- 加载链接/条件储存（Load-Linked/Store-Conditional，下文称 LL/SC）。
其中，前面的 3 条是 20 世纪就已经存在于大多数指令集之中的处理器指令，后面的两条是现代处理器新增的，而且这两条指令的目的和功能也是类似的。在 IA64、x86 指令集中有用 cmpxchg 指令完成的 CAS 功能，在 SPARC-TSO 中也有用 casa 指令实现的，而在 ARM 和 PowerPC 架构下，则需要使用一对 ldrex/strex 指令来完成 LL/SC 的功能。因为 Java 里最终暴露出来的是 CAS 操作，所以我们以 CAS 指令为例进行讲解。
2.2.2 使用示例
CAS 指令需要有 3 个操作数，分别是内存位置（在 Java 中可以简单地理解为变量的内存地址，用 V 表示）、旧的预期值（用 A 表示）和准备设置的新值（用 B 表示）。CAS 指令执行时，当且仅当 V 符合 A 时，处理器才会用 B 更新 V 的值，否则它就不执行更新。但是，不管是否更新了 V 的值，都会返回 V 的旧值，上述的处理过程是一个原子操作，执行期间不会被其他线程中断。
在 JDK 5 之后，Java 类库中才开始使用 CAS 操作，该操作由 sun.misc.Unsafe 类里面的 compareAndSwapInt() 和 compareAndSwapLong() 等几个方法包装提供。HotSpot 虚拟机在内部对这些方法做了特殊处理，即时编译出来的结果就是一条平台相关的处理器 CAS 指令，没有方法调用的过程，或者可以认为是无条件内联进去了。
不过由于 Unsafe 类在设计上就不是提供给用户程序调用的类（Unsafe::getUnsafe() 的代码中限制了只有启动类加载器 BootstrapClassLoader 加载的 Class 才能访问它），因此在 JDK 9 之前只有 Java 类库可以使用 CAS，譬如 J.U.C 包里面的整数原子类，其中的 compareAndSet() 和 getAndIncrement() 等方法都使用了 Unsafe 类的 CAS 操作来实现。而如果用户程序也有使用 CAS 操作的需求，那要么就采用反射手段突破 Unsafe 的访问限制，要么就只能通过 Java 类库 API 来间接使用它。直到 JDK 9 之后，Java 类库才在 VarHandle 类里开放了面向用户程序使用的 CAS 操作。
下面笔者将用一段在前面章节中没有解决的问题代码来介绍如何通过 CAS 操作避免阻塞同步。那段代码里我们曾经通过 20 个线程自增 10000 次的操作来证明 volatile 变量不具备原子性，那么如何才能让它具备原子性呢？之前我们的解决方案是把 race++ 操作或 increase() 方法用同步块包裹起来，这毫无疑问是一个解决方案，但是如果改成如下所示的写法，效率将会提高许多。
public class AtomicTest {
public static AtomicInteger race = new AtomicInteger(0);
public static void increase() {
race.incrementAndGet();
}
private static final int THREADS_COUNT = 20;
public static void main(String[] args) throws Exception {
Thread[] threads = new Thread[THREADS_COUNT];
for (int i = 0; i < THREADS_COUNT; i++) {
threads[i] = new Thread(new Runnable() {
@Override
public void run() {
for (int i = 0; i < 10000; i++) {
increase();
}
}
});
threads[i].start();
}
while (Thread.activeCount() > 1)
Thread.yield();
System.out.println(race);
}
}
使用 AtomicInteger 代替 int 后，程序输出了正确的结果，这一切都要归功于 incrementAndGet() 方法的原子性。它的实现其实非常简单，就是调用 Unsafe。
public class AtomicInteger extends Number implements java.io.Serializable {
private static final Unsafe unsafe = Unsafe.getUnsafe();
private static final long valueOffset;
private volatile int value;
public final int incrementAndGet() {
return unsafe.getAndAddInt(this, valueOffset, 1) + 1;
}
}
incrementAndGet() 方法在一个无限循环中，不断尝试将一个比当前值大一的新值赋值给自己。如果失败了，那说明在执行 CAS 操作的时候，旧值已经发生改变，于是再次循环进行下一次操作，直到设置成功为止。源码如下：
public final class Unsafe {
// CAS 底层依赖于一个 Unsafe 类来直接调用操作系统底层的 CAS 指令
public final int getAndSetInt(Object var1, long var2, int var4) {
int var5;
do {
var5 = this.getIntVolatile(var1, var2); // get
} while (!this.compareAndSwapInt(var1, var2, var5, var4)); // set
return var5;
}
/*
* [v1, v2] -> 变量内存地址(V)
* var4 -> 旧的预期值(A)
* var5 -> 准备设置的新值(B)
*/
public final native boolean compareAndSwapInt(Object var1, long var2, int var4, int var5);
}
获取共享变量时，为了保证该变量的可见性，需要使用 volatile 修饰。结合 CAS 和 volatile 可以实现无锁并发，适用于竞争不激烈、多核 CPU 的场景下。
因为没有使用 synchronized，所以线程不会陷入阻塞，这是效率提升的因素之一。但如果竞争激烈，可以想到重试必然频繁发生，反而效率会受影响。
2.2.3 ABA 问题
尽管 CAS 看起来很美好，既简单又高效，但显然这种操作无法涵盖互斥同步的所有使用场景，并且 CAS 从语义上来说并不是真正完美的，它存在一个逻辑漏洞：如果一个变量 V 初次读取的时候是 A 值，并且在准备赋值的时候检查到它仍然为 A 值，那就能说明它的值没有被其他线程改变过了吗？
这是不能的，因为如果在这段期间它的值曾经被改成 B，后来又被改回为 A，那 CAS 操作就会误认为它从来没有被改变过。这个漏洞称为 CAS 操作的“ABA 问题”。
J.U.C 包为了解决这个问题，提供了一个带有标记的原子引用类 AtomicStampedReference，它可以通过控制变量值的版本来保证 CAS 的正确性。不过目前来说这个类处于相当鸡肋的位置，大部分情况下 ABA 问题不会影响程序并发的正确性，如果需要解决 ABA 问题，改用传统的互斥同步可能会比原子类更为高效。
2.3 无同步方案
要保证线程安全，也并非一定要进行阻塞或非阻塞同步，同步与线程安全两者没有必然的联系。同步只是保障存在共享数据争用时正确性的手段，如果能让一个方法本来就不涉及共享数据，那它自然就不需要任何同步措施去保证其正确性，因此会有一些代码天生就是线程安全的，笔者简单介绍其中的两类。
2.3.1 可重入代码
可重入代码（Reentrant Code），这种代码又称纯代码（Pure Code），是指可以在代码执行的任何时刻中断它，转而去执行另外一段代码（包括递归调用它本身），而在控制权返回后，原来的程序不会出现任何错误，也不会对结果有所影响。
在特指多线程的上下文语境里（不涉及信号量等因素），我们可以认为可重入代码是线程安全代码的一个真子集，这意味着相对线程安全来说，可重入性是更为基础的特性，它可以保证代码线程安全，即所有可重入的代码都是线程安全的，但并非所有的线程安全的代码都是可重入的。
可重入代码有一些共同的特征，例如，不依赖全局变量、存储在堆上的数据和公用的系统资源，用到的状态量都由参数中传入，不调用非可重入的方法等。
我们可以通过一个比较简单的原则来判断代码是否具备可重入性：如果一个方法的返回结果是可以预测的，只要输入了相同的数据，就都能返回相同的结果，那它就满足可重入性的要求，当然也就是线程安全的。
2.3.2 线程本地存储
线程本地存储（Thread Local Storage），如果一段代码中所需要的数据必须与其他代码共享，那就看看这些共享数据的代码是否能保证在同一个线程中执行。如果能保证，我们就可以把共享数据的可见范围限制在同一个线程之内，这样，无须同步也能保证线程之间不出现数据争用的问题。
符合这种特点的应用并不少见，大部分使用消费队列的架构模式（如“生产者-消费者”模式）都会将产品的消费过程限制在一个线程中消费完，其中最重要的一种应用实例就是经典 Web 交互模型中的“一个请求对应一个服务器线程”（Thread-per-Request）的处理方式，这种处理方式的广泛应用使得很多 Web 服务端应用都可以使用线程本地存储来解决线程安全问题。
Java 语言中，如果一个变量要被多线程访问，可以使用volatile关键字将它声明为“易变的”；如果一个变量只要被某个线程独享，Java中就没有类似 C++ 中 __declspec(thread) 这样的关键字去修饰，不过我们还是可以通过 java.lang.ThreadLocal 类来实现线程本地存储的功能。
每一个线程的 Thread 对象中都有一个ThreadLocalMap对象，这个对象存储了一组以 ThreadLocal.threadLocalHashCode 为键，以本地线程变量为值的 K-V 值对，ThreadLocal 对象就是当前线程的 ThreadLocalMap 的访问入口，每一个 ThreadLocal 对象都包含了一个独一无二的 threadLocalHashCode 值，使用这个值就可以在线程 K-V 值对中找回对应的本地线程变量。
3. 锁优化
Java 的线程是映射到操作系统原生线程之上的，如果要阻塞或唤醒一个线程就需要操作系统介入，需要在用户态与核心态之间切换，这种切换会消耗大量的系统资源，因为用户态与内核态都有各自专用的内存空间，专用的寄存器等，用户态切换至内核态需要传递给许多变量、参数给内核，内核也需要保护好用户态在切换时的一些寄存器值、变量等，以便内核态调用结束后切换回用户态继续工作。
在 Java 早期版本中，synchronized 属于重量级锁，效率低下，因为监视器锁（monitor）是依赖于底层的操作系统的 Mutex Lock 来实现的，挂起线程和恢复线程都需要转入内核态去完成，阻塞或唤醒一个 Java 线程需要操作系统切换 CPU 状态来完成，这种状态切换需要耗费处理器时间，如果同步代码块中内容过于简单，这种切换的时间可能比用户代码执行的时间还长，时间成本相对较高，这也是为什么早期的 synchronized 效率低的原因。
Monitor 是在 jvm 底层实现的，底层代码是 C++。本质是依赖于底层操作系统的 Mutex Lock 实现，操作系统实现线程之间的切换需要从用户态到内核态的转换，状态转换需要耗费很多的处理器时间成本非常高。所以 synchronized 是 Java 语言中的一个重量级操作。
Monitor 与 Java 对象以及线程是如何关联 ？
- 如果一个 Java 对象被某个线程锁住，则该 Java 对象的 Mark Word 字段中 LockWord 指向 monitor 的起始地址；
- Monitor 的 Owner 字段会存放拥有相关联对象锁的 threadID。
Mutex Lock 的切换需要从用户态转换到核心态中，因此状态转换需要耗费很多的处理器时间。
JDK6 开始，优化 Synchronized，为了减少获得锁和释放锁所带来的性能消耗，引入了〈偏向锁〉和〈轻量级锁〉。有了一个逐步升级锁的过程，不再一开始就捅到重量级锁。
synchronized 作用的锁是存在 Java 对象头里的 MarkWord 中。锁升级功能主要依赖 MarkWord 中锁标志位和释放偏向锁标志位。
无锁状态下的对象：
高效并发是从 JDK 5 升级到 JDK 6 后一项重要的改进项，HotSpot 虚拟机开发团队在这个版本上花费了大量的资源去实现各种锁优化技术，如适应性自旋（Adaptive Spinning）、锁消除（Lock Elimination）、锁膨胀（Lock Coarsening）、轻量级锁（Lightweight Locking）、偏向锁（Biased Locking）等，这些技术都是为了在线程之间更高效地共享数据及解决竞争问题，从而提高程序的执行效率。
3.1 偏向锁
偏向锁是 JDK 6 中引入的一项锁优化措施，它的目的是消除数据在无竞争情况下的同步原语，进一步提高程序的运行性能。如果说轻量级锁是在无竞争的情况下使用 CAS 操作去消除同步使用的互斥量，那偏向锁就是在无竞争的情况下把整个同步都消除掉，连 CAS 操作都不去做了。
Hotspot 的作者经过研究发现，大多数情况下：多线程的情况下，锁不仅不存在多线程竞争，还存在锁由同一线程多次获得的情况，偏向锁就是在这种情况下出现的，它的出现是为了解决只有在一个线程执行同步时提高性能。
a. 说明&案例
偏向锁中的“偏”，就是偏心的“偏”、偏袒的“偏”。它的意思是这个锁会偏向于第一个获得它的线程，如果在接下来的执行过程中，该锁一直没有被其他的线程获取，则持有偏向锁的线程将永远不需要再进行同步。类比“同一个老顾客来访，直接老规矩行方便”。
就是说锁总是被第一个占用它的线程拥有，这个线程就是锁的偏向线程。那么只需要在锁第一次被拥有的时候，通过 CAS 方式记录下偏向线程 ID。这样偏向线程就一直持有着锁（后续这个线程进入和退出这段加了同步锁的代码块时，不需要再次加锁和释放锁。而是直接比较对象头里面是否存储了指向当前线程的偏向锁）。
如果相等表示偏向锁是偏向于当前线程的，就不需要再尝试获得锁了，直到竞争发生才释放锁。以后每次同步，检查锁的偏向线程 ID 与当前线程 ID 是否一致，如果一致直接进入同步。无需每次加锁解锁都去 CAS 更新对象头。如果自始至终使用锁的线程只有一个，很明显偏向锁几乎没有额外开销，性能极高。
假如不一致意味着发生了竞争，锁已经不是总是偏向于同一个线程了，这时候可能需要升级变为轻量级锁，才能保证线程间公平竞争锁。
一个 synchronized 方法被一个线程抢到了锁时，那这个方法所在的对象就会在其所在的 MarkWord 中将偏向锁修改状态位，同时还会有占用前 54 位来存储线程指针作为标识。若该线程再次访问同一个 synchronized 方法时，该线程只需去对象头的 MarkWord 中去判断一下是否有偏向锁指向本身的 ID，无需再进入 Monitor 去竞争对象了。
偏向锁的操作不用直接捅到操作系统，不涉及用户到内核转换，不必要直接升级为最高级，我们以一个 account 对象的“对象头”为例，假如有一个线程执行到 synchronized 代码块的时候，JVM 使用 CAS 操作把线程指针 ID 记录到 MarkWord 当中，并修改标偏向标识，标识当前线程就获得该锁。锁对象变成偏向锁（通过 CAS 修改对象头里的锁标志位），字面意思是“偏向于第一个获得它的线程”的锁。执行完同步代码块后，线程并不会主动释放偏向锁。
这时线程获得了锁，可以执行同步代码块。当该线程第二次到达同步代码块时会判断此时持有锁的线程是否还是自己（持有锁的线程 ID 也在对象头里），JVM 通过 account 对象的 MarkWord 判断：当前线程 ID 还在，说明还持有着这个对象的锁，就可以继续进入临界区工作。由于之前没有释放锁，这里也就不需要重新加锁。 如果自始至终使用锁的线程只有一个，很明显偏向锁几乎没有额外开销，性能极高。
JVM 不用和操作系统协商设置 Mutex（争取内核），它只需要记录下线程 ID 就表示自己获得了当前锁，不用操作系统介入。
上述就是偏向锁：在没有其他线程竞争的时候，一直偏向（心）当前线程，当前线程可以一直执行。
b. 命令&撤销
查看偏向锁相关的 JVM 初始化配置项 java -XX:+PrintFlagsInitial | grep BiasedLock*：
实际上偏向锁在 JDK1.6 之后是默认开启的，新创建对象的 Mark Word 中的 ThreadID 为 0，说明此时处于可偏向但未偏向任何线程，也叫做「匿名偏向状态（anonymously biased）」。
只有匿名偏向的对象才能进入偏向锁模式。JVM 启动时会延时初始化偏向锁，默认是 4000ms。初始化后会将所有加载的 Klass 的 prototype header 修改为匿名偏向样式。当创建一个对象时，会通过 Klass 的 prototype_header 来初始化该对象的对象头。简单的说，偏向锁初始化结束后，后续所有对象的对象头都为匿名偏向样式，在此之前创建的对象则为无锁状态。而对于无锁状态的锁对象，如果有竞争，会直接进入到轻量级锁。这也是为什么 JVM 启动前 4s 对象会直接进入到轻量级锁的原因。
为什么需要延迟初始化？
JVM 启动时必不可免会有大量 sync 的操作，而偏向锁并不是都有利。如果开启了偏向锁，会发生大量锁撤销和锁升级操作，大大降低 JVM 启动效率。
因此，我们可以明确地说，只有锁对象处于匿名偏向状态，线程才能拿到到我们通常意义上的偏向锁。而处于无锁状态的锁对象，只能进入到轻量级锁状态。
开启偏向锁(默认)：
-XX:+UseBiasedLocking
关闭延迟：
-XX:BiasedLockingStartupDelay=0
关闭偏向锁：如果确定锁通常处于竞争状态可关闭偏向锁，关闭之后程序默认会直接进入 <轻量级锁状态>
-XX:-UseBiasedLocking
执行完同步代码块后，线程并不会主动释放偏向锁：
但好日子终会到头，当有另外线程逐步来竞争锁的时候，就不能再使用偏向锁了，要升级为轻量级锁。
偏向锁使用一种等到竞争出现才释放锁的机制，只有当其他线程竞争锁时，持有偏向锁的原来线程才会被撤销。但撤销需要等待全局安全点（该时间点上没有字节码正在执行），同时检查持有偏向锁的线程是否还在执行：
- 第一个线程正在执行 synchronized 方法（处于同步块），它还没有执行完，其它线程来抢夺，该偏向锁会被取消并出现锁升级。此时轻量级锁由原持有偏向锁的线程持有，继续执行其同步代码，而正在竞争的线程会进入自旋等待获得该轻量级锁；
- 第一个线程执行完成 synchronized 方法（退出同步块），则将对象头设置成无锁状态并撤销偏向锁，重新偏向。
偏向锁的撤销步骤：
- 偏向锁的撤销动作必须等待「安全点」；
- 暂停拥有偏向锁的线程，判断锁对象是否处于“被锁定状态”；
- 撤销偏向锁，恢复到无锁（标志位为 01）或轻量级锁（标志位为 00）的状态。
↓出处：https://blog.csdn.net/qq_39288456/article/details/127721726
c. 运行过程
假设当前虚拟机启用了偏向锁，那么当锁对象第一次被线程获取的时候，虚拟机将会把对象头中的标志位设置为“01”、把偏向模式设置为“1”，表示进入偏向模式。同时使用 CAS 操作把获取到这个锁的线程的 ID 记录在对象的 Mark Word 之中。
如果 CAS 操作成功，持有偏向锁的线程以后每次进入这个锁相关的同步块时，虚拟机都可以不再进行任何同步操作（例如加锁、解锁及对 Mark Word 的更新操作等）。
一旦出现另外一个线程去尝试获取这个锁的情况，偏向模式就马上宣告结束。根据锁对象目前是否处于被锁定的状态决定是否撤销偏向（偏向模式设置为“0”），撤销后标志位恢复到未锁定（标志位为“01”）或轻量级锁定（标志位为“00”）的状态，后续的同步操作就按照上面介绍的轻量级锁那样去执行。偏向锁、轻量级锁的状态转化及对象 Mark Word 的关系如下图所示。
d. hashCode
细心的读者看到这里可能会发现一个问题：当对象进入偏向状态的时候，Mark Word 大部分的空间（23 个比特）都用于存储持有锁的线程 ID 了，这部分空间占用了原有存储对象哈希码的位置，那原来对象的哈希码怎么办呢？
在 Java 语言里面一个对象如果计算过哈希码，就应该一直保持该值不变，否则很多依赖对象哈希码的 API 都可能存在出错风险。而作为绝大多数对象哈希码来源的 Object::hashCode() 方法，返回的是对象的一致性哈希码（Identity Hash Code），这个值是能强制保证不变的，它通过在对象头中存储计算结果来保证第一次计算之后，再次调用该方法取到的哈希码值永远不会再发生改变。
因此，当一个对象已经计算过一致性哈希码后，它就再也无法进入〈偏向锁状态〉了；而当一个对象当前正处于偏向锁状态，又收到需要计算其一致性哈希码请求时，它的偏向状态会被立即撤销，并且锁会膨胀为重量级锁（偏向锁是没有地方保存 hashcode 的）。
也就是说，当对象处于可偏向（也就是 ThreadID 为 0）和已偏向的状态下，调用 hashCode 计算都将会使对象再也无法偏向：
- 当对象可偏向时，MarkWord 将变成未锁定状态，并只能升级成轻量锁；
- 当对象正处于偏向锁时，调用 hashCode 将使偏向锁强制升级成重量锁。
在重量级锁的实现中，对象头指向了重量级锁的位置，代表重量级锁的 ObjectMonitor 类里有字段 _object 可以记录非加锁状态（标志位为“01”）下的 Mark Word，其中自然可以存储原来的哈希码。
- 轻量级锁会在锁记录中记录 hashCode；
- 重量级锁会在 Monitor 中记录 hashCode。
偏向锁可以提高带有同步但无竞争的程序性能，但它同样是一个带有效益权衡（Trade Off）性质的优化，也就是说它并非总是对程序运行有利。
偏向锁是在只有一个线程执行同步块时进一步提高性能，适用于一个线程反复获得同一锁的情况；如果程序中大多数的锁都总是被多个不同的线程访问（比如线程池），那偏向模式就是多余的。
如果撤销偏向到达某个阈值，整个类的所有对象都会变为不可偏向的。
在具体问题具体分析的前提下，有时候使用参数 -XX:-UseBiasedLocking 来禁止偏向锁优化反而可以提升性能。
偏向锁状态执行 obj.notify() 会升级为轻量级锁，调用 obj.wait(timeout) 会升级为重量级锁。
3.2 轻量级锁
倘若偏向锁失败，虚拟机并不会立即升级为重量级锁，它还会尝试使用一种称为轻量级锁的优化手段，此时 Mark Word 的结构也变为轻量级锁的结构。轻量级锁所适应的场景是线程交替执行同步块的场合，如果存在同一时间多个线程访问同一把锁的场合，就会导致轻量级锁膨胀为重量级锁。
轻量级锁是 JDK 6 时加入的新型锁机制，它名字中的“轻量级”是相对于使用〈操作系统互斥量〉来实现的传统锁而言的，因此传统的锁机制就被称为“重量级”锁。
不过，需要强调一点，轻量级锁并不是用来代替重量级锁的，它设计的初衷是在没有多线程竞争的前提下（如多线程交替执行同步块），减少传统的重量级锁使用〈操作系统互斥量〉产生的性能消耗。
a. 对象头
要理解轻量级锁，以及后面会讲到的偏向锁的原理和运作过程，必须要对 HotSpot 虚拟机对象的内存布局（尤其是对象头部分）有所了解。
HotSpot 虚拟机的对象头（Object Header）由两部分组成，一部分用于存储自身的运行时数据，称之为 Mark Word，另外一部分是类型指针，及对象指向它的类元数据的指针。
HotSpot 采用 instanceOopDesc 和 arrayOopDesc 来描述对象头，arrayOopDesc 对象用来描述数组类型。instanceOopDesc 的定义的在 Hotspot 源码的 instanceOop.hpp 文件中。另外，arrayOopDesc 的定义对应 arrayOop.hpp 。
class instanceOopDesc : public oopDesc {
public:
// aligned header size.
static int header_size() { return sizeof(instanceOopDesc)/HeapWordSize; }
// If compressed, the offset of the fields of the instance may not be aligned.
static int base_offset_in_bytes() {
// offset computation code breaks if UseCompressedClassPointers
// only is true
return (UseCompressedOops && UseCompressedClassPointers) ?
klass_gap_offset_in_bytes() : sizeof(instanceOopDesc);
}
static bool contains_field_offset(int offset, int nonstatic_field_size) {
int base_in_bytes = base_offset_in_bytes();
return (offset >= base_in_bytes &&
(offset-base_in_bytes) < nonstatic_field_size * heapOopSize);
}
};
从 instanceOopDesc 代码中可以看到 instanceOopDesc 继承自 oopDesc，oopDesc 的定义在 Hotspot 源码中的 oop.hpp 文件中。
class oopDesc {
friend class VMStructs;
private:
volatile markOop _mark;
union _metadata {
Klass* _klass;
narrowKlass _compressed_klass;
} _metadata;
// Fast access to barrier set. Must be initialized.
static BarrierSet* _bs;
// 省略其他代码 ...
};
在普通实例对象中，oopDesc 的定义包含两个成员，分别是 _mark 和 _metadata：
_mark表示对象标记、属于 markOop 类型，也就是接下来要讲解的 Mark Word，它记录了对象和锁有关的信息。_metadata表示类元信息，类元信息存储的是对象指向它的类元数据(Klass) 的首地址，其中 Klass 表示普通指针、 _compressed_klass 表示压缩类指针。
第一部分用于存储对象自身的运行时数据，如哈希码（HashCode）、GC 分代年龄（Generational GC Age）等。这部分数据的长度在 32 位和 64 位的 Java 虚拟机中分别会占用 32 个或 64 个比特，官方称它为“Mark Word”。这部分是实现「轻量级锁」和「偏向锁」的关键。
另外一部分用于存储指向方法区对象类型数据的指针（如果是数组对象，还会有一个额外的部分用于存储数组长度），该指针指向它的类元数据，JVM 通过这个指针确定对象是哪个类的实例。该指针的位长度为 JVM 的一个字大小，即 32 位的 JVM 为 32 位，64 位的 JVM 为 64 位。 如果应用的对象过多，使用 64 位的指针将浪费大量内存，统计而言，64 位的 JVM 将会比 32 位的 JVM 多耗费 50% 的内存。为了节约内存可以使用选项 -XX:+UseCompressedOops 开启指针压缩，其中，oop 即 ordinary object pointer 普通对象指针。开启该选项后，下列指针将压缩至 32 位：
- 每个 Class 的属性指针（即静态变量）
- 每个对象的属性指针（即对象变量）
- 普通对象数组的每个元素指针
当然，也不是所有的指针都会压缩，一些特殊类型的指针 JVM 不会优化，比如指向 PermGen 的 Class 对象指针(JDK8 中指向元空间的 Class 对象指针)、本地变量、堆栈元素、入参、返回值和 NULL 指针等。
对象头 = Mark Word + 类型指针（未开启指针压缩的情况下）
- 在 32 位系统中，Mark Word = 4 bytes，类型指针 = 4bytes，对象头 = 8 bytes = 64 bits；
- 在 64 位系统中，Mark Word = 8 bytes，类型指针 = 8bytes，对象头 = 16 bytes = 128bits；
由于对象头信息是与对象自身定义的数据无关的额外存储成本，考虑到 Java 虚拟机的空间使用效率，Mark Word 被设计成一个非固定的动态数据结构，以便在极小的空间内存储尽量多的信息。它会根据对象的状态复用自己的存储空间。
例如在 32 位的 HotSpot 虚拟机中，对象未被锁定的状态下，Mark Word 的 32 个比特空间里的 25 个比特将用于存储对象哈希码，4 个比特用于存储对象分代年龄，2 个比特用于存储锁标志位，还有 1 个比特固定为 0（这表示未进入偏向模式）。对象除了未被锁定的正常状态外，还有轻量级锁定、重量级锁定、GC 标记、可偏向等几种不同状态，这些状态下对象头的存储内容如下图所示。
b. 工作过程
我们简单回顾了对象的内存布局后，接下来就可以介绍轻量级锁的工作过程了：
(一) 在代码即将进入同步块的时候，如果此同步对象没有被锁定（hashCode，0，01），虚拟机首先将在当前线程的「栈帧」中建立一个名为「锁记录 (Lock Record)」的空间，用于存储锁对象目前的 Mark Word 的拷贝（官方为这份拷贝加了一个 Displaced 前缀，即 Displaced Mark Word），owner 指向当前对象，这时候线程堆栈与对象头的状态如下图所示。
(二) 然后，虚拟机将使用 CAS 操作尝试把对象的 Mark Word 更新为指向 Lock Record 的指针。
(1) 如果这个更新动作成功了，即代表该线程拥有了这个对象的锁，并且对象 Mark Word 的锁标志位（Mark Word 的最后两个比特）将转变为“00”，表示此对象处于轻量级锁定状态。这时候线程堆栈与对象头的状态如下图所示。
(2) 如果这个更新操作失败了，那就意味着至少存在一条线程与当前线程竞争获取该对象的锁。虚拟机首先会检查对象的 Mark Word 是否指向当前线程的栈帧！
(a) 如果是，说明当前线程已经拥有了这个对象的锁，那直接进入同步块继续执行就可以了。
(b) 否则就说明这个锁对象已经被其他线程抢占了，如果出现两条以上的线程争用同一个锁的情况，那轻量级锁就不再有效，必须要膨胀为「重量级锁」，锁标志的状态值变为“10”，此时 Mark Word 中存储的就是〈指向重量级锁（互斥量）的指针〉，后面等待锁的线程也必须进入“阻塞状态”。
(三) 上面描述的是轻量级锁的加锁过程，它的解锁过程也同样是通过 CAS 操作来进行的。如果对象的 Mark Word 仍然指向线程的 Lock Record，那就用 CAS 操作把线程栈帧中复制的 Displaced Mark Word 替换回对象的 Mark Word 中。
(1) 假如能够成功替换，那整个同步过程就顺利完成了（说明释放锁成功）；
(2) 如果替换失败，则说明有其他线程尝试过获取该锁，就要在释放锁的同时，唤醒被挂起的线程。
c. 小结
轻量级锁能提升程序同步性能的依据是“对于绝大部分的锁，在整个同步周期内都是不存在竞争的”这一经验法则。如果没有竞争，轻量级锁便通过 CAS 操作成功避免了使用互斥量的开销；但如果确实存在锁竞争，除了互斥量的本身开销外，还额外发生了 CAS 操作的开销。因此在有竞争的情况下，轻量级锁反而会比传统的重量级锁更慢（膨胀）。
在多线程交替执行同步块的情况下，尽量避免重量级锁引起的性能消耗，但是如果多个线程在同一时刻进入临界区，会导致轻量级锁膨胀升级重量级锁，所以轻量级锁的出现并非是要替代重量级锁。
Java 中的 synchronized 有偏向锁、轻量级锁、重量级锁三种形式，分别对应了锁只被一个线程持有、不同线程交替持有锁、多线程竞争锁三种情况。
3.3 自旋锁
前面我们讨论互斥同步的时候，提到了互斥同步对性能最大的影响是〈阻塞〉的实现，挂起线程和恢复线程的操作都需要转入内核态中完成，这些操作给 Java 虚拟机的并发性能带来了很大的压力。
同时，虚拟机的开发团队也注意到在许多应用上，共享数据的锁定状态只会持续很短的一段时间，为了这段时间去挂起和恢复线程并不值得。现在绝大多数的个人电脑和服务器都是多路（核）处理器系统，如果物理机器有一个以上的处理器或者处理器核心（自旋会占用 CPU 时间，单核 CPU 自旋就是浪费，多核 CPU 自旋才能发挥优势），能让两个或以上的线程同时并行执行，我们就可以让后面请求锁的那个线程“稍等一会”，但不放弃处理器的执行时间，看看持有锁的线程是否很快就会释放锁。为了让线程等待，我们只须让线程执行一个〈忙循环 (自旋)〉，这项技术就是所谓的「自旋锁」。
自旋锁在 JDK 1.4.2 中就已经引入，只不过默认是关闭的，可以使用 -XX:+UseSpinning 参数来开启，在 JDK 6 中就已经改为默认开启了。
自旋等待不能代替阻塞，且先不说对处理器数量的要求，自旋等待本身虽然避免了线程切换的开销，但它是要占用处理器时间的，所以如果锁被占用的时间很短，自旋等待的效果就会非常好，反之如果锁被占用的时间很长，那么自旋的线程只会白白消耗处理器资源，而不会做任何有价值的工作，这就会带来性能的浪费。
让线程自旋而不阻塞就好比等红灯时车熄不熄火，不熄火相当于自旋（等待时间短划算），熄火相当于阻塞（等待时间长划算）。
因此自旋等待的时间必须有一定的限度，如果自旋超过了限定的次数仍然没有成功获得锁，就应当使用传统的方式去挂起线程。自旋次数的默认值是 10 次，用户也可以使用参数 -XX:PreBlockSpin 来自行更改。
不过无论是默认值还是用户指定的自旋次数，对整个 Java 虚拟机中所有的锁来说都是相同的。在 JDK 6 中对自旋锁的优化，引入了「自适应的自旋」。
自适应意味着自旋的时间不再是固定的了，而是由前一次在同一个锁上的自旋时间及锁的拥有者的状态来决定的。
如果在同一个锁对象上，自旋等待刚刚成功获得过锁，并且持有锁的线程正在运行中，那么虚拟机就会认为这次自旋也很有可能再次成功，进而允许自旋等待持续相对更长的时间，比如持续 100 次忙循环。
另一方面，如果对于某个锁，自旋很少成功获得过锁，那在以后要获取这个锁时将有可能直接省略掉自旋过程，以避免浪费处理器资源。有了自适应自旋，随着程序运行时间的增长及性能监控信息的不断完善，虚拟机对程序锁的状况预测就会越来越精准，虚拟机就会变得越来越“聪明”了。
3.4 锁消除
锁消除是指虚拟机即时编译器（JIT）在运行时，对一些代码要求同步，但是对被检测到不可能存在共享数据竞争的锁进行消除。
锁消除的主要判定依据来源于逃逸分析的数据支持，如果判断到一段代码中，在堆上的所有数据都不会逃逸出去被其他线程访问到，那就可以把它们当作栈上数据对待，认为它们是线程私有的，同步加锁自然就无须再进行。
也许读者会有疑问，变量是否逃逸，对于虚拟机来说是需要使用复杂的过程间分析才能确定的，但是程序员自己应该是很清楚的，怎么会在明知道不存在数据争用的情况下还要求同步呢？
这个问题的答案是：有许多同步措施并不是程序员自己加入的，同步的代码在 Java 程序中出现的频繁程度也许超过了大部分读者的想象。我们来看看如下所示的例子，这段非常简单的代码仅仅是输出三个字符串相加的结果，无论是源代码字面上，还是程序语义上都没有进行同步。
public String concatString(String s1, String s2, String s3) {
return s1 + s2 + s3;
}
我们也知道，由于 String 是一个不可变的类，对字符串的连接操作总是通过生成新的 String 对象来进行的，因此 Javac 编译器会对 String 连接做自动优化。在 JDK 5 之前，字符串加法会转化为 StringBuffer 对象的连续 append() 操作，在 JDK 5 及以后的版本中，会转化为 StringBuilder 对象的连续 append() 操作。即上述代码可能会变成如下所示的样子。
public String concatString(String s1, String s2, String s3) {
// sb 这个引用不会逃逸，即只会被当前线程获取
StringBuffer sb = new StringBuffer();
sb.append(s1);
sb.append(s2);
sb.append(s3);
return sb.toString();
}
现在大家还认为这段代码没有涉及同步吗？每个 StringBuffer.append() 方法中都有一个同步块，锁就是 sb 对象。虚拟机观察变量 sb，经过逃逸分析后会发现它的动态作用域被限制在 concatString() 方法内部。也就是 sb 的所有引用都永远不会逃逸到 concatString() 方法之外，其他线程无法访问到它，所以这里虽然有锁，但是可以被安全地消除掉。在解释执行时这里仍然会加锁，但在经过服务端编译器的即时编译之后，这段代码就会忽略所有的同步措施而直接执行。
【补充】客观地说，既然谈到锁消除与逃逸分析，那虚拟机就不可能是 JDK 5 之前的版本，所以实际上会转化为非线程安全的 StringBuilder 来完成字符串拼接，并不会加锁。但是这也不影响笔者用这个例子证明 Java 对象中同步的普遍性。
3.5 锁粗化
原则上，我们在编写代码的时候，总是推荐将同步块的作用范围限制得尽量小 —— 只在共享数据的实际作用域中才进行同步，这样是为了使得需要同步的操作数量尽可能变少，即使存在锁竞争，等待锁的线程也能尽可能快地拿到锁。
大多数情况下，上面的原则都是正确的，但是如果一系列的连续操作都对同一个对象反复加锁和解锁，甚至加锁操作是出现在循环体之中的，那即使没有线程竞争，频繁地进行互斥同步操作也会导致不必要的性能损耗。
上面的连续的 append() 方法就属于这类情况。如果虚拟机探测到有这样一串零碎的操作都对同一个对象加锁，将会把加锁同步的范围扩展（粗化）到整个操作序列的外部，以上述代码为例，就是扩展到第一个 append() 操作之前直至最后一个 append() 操作之后，这样只需要加锁一次就可以了。
4. 编程时 synchronized 技巧
4.1 减少锁范围/时间
synchronized 同步代码块中尽量短，减少同步代码块中代码的执行时间，减少锁的竞争。
4.2 降低锁的粒度
将一个锁拆分为多个锁提高并发度。
4.3 读写分离
读取时不加锁，写入和删除时加锁。多线程环境下集合类使用：ConcurrentHashMap，CopyOnWriteArrayList 和 ConyOnWriteSet。
