# 并发编程（三）：锁的优化

# 锁优化角度

# 减小锁持有的时间

在真正需要同步的代码块进行加锁，避免在整个任务的处理上加锁，有助于降低锁冲突的可能性，进而提升系统的并发能力。

# 减小锁粒度

缩小锁定对象的范围，降低锁冲突可能性，进而提升系统并发能力。例如 ConcurrentHashMap 内部细分为若干个小的 HashMap，添加数据时可能只需要对其中的某个 SEGMENT 加锁，这样同时就有多个线程可以操作 ConcurrentHashMap，大大提高了吞吐量。

# 使用读写锁代替独占锁

理论上读-读之前是不应该阻塞的，在读多写少的情况下，使用读写锁相对于独占锁能够有效提升系统并发能力。

# 锁分离

在区别读写锁的基础上进一步延伸，就是锁分离。例如如果需要创建一个线程安全的容器，其加入元素和弹出元素的操作必须要获得容器的锁，那么在运行时，加入和弹出操作就必须等待对方释放资源，如果锁竞争激烈，并发性能就会大大下降。而 LinkedBlockingQueue 的实现中，则使用了读锁和写锁两把锁，其原理是利用 ReentrantLock 和 Condition 分别阻塞和唤醒线程，使得读取和写入之间可以并发。

# 锁粗化

虚拟机在一系列对同一锁不断进行请求和释放的操作时，便会把所有锁操作整合为对锁的一次请求，从而减少对锁的请求同步次数。锁粗化的思想和减少锁的持有时间是相反的。

# JVM 对锁的优化

# 偏向锁

如果某个线程获取了锁，到再次请求锁时，没有其他线程再去请求该锁，则省略线程申请锁的同步操作。在几乎没有锁竞争的场合中，偏向锁具有很强的优化效果；但在锁竞争激烈的情况下，可能是多个线程请求相同的锁，偏向模式就会失效。通过虚拟机参数 -XX:+UseBiasedLocking 开启偏向锁。

# 轻量级锁

线程在执行同步块之前，JVM 会先在当前线程的栈桢中创建用于存储锁记录的空间，并将对象头中的 Mark Word 复制到锁记录中，然后线程尝试使用 CAS 将对象头中的 Mark Word 替换为指向锁记录的指针。如果成功则线程可以顺利进入临界区，如果失败，锁请求会膨胀为重量级锁。

# 自旋锁

假设在不久的将来，线程就可以获取请求的锁资源，那么直接在操作系统层面将线程挂起是得不偿失的，因此虚拟机会让当前线程做几个空循环，如果若干次循环后能够获得锁，则顺利进入临界区，否则才会将线程真实地在操作系统层面挂起。

# 锁消除

虚拟机在 JIT 编译时通过对上下文的扫描，能够去除不可能存在共享资源竞争的锁。通过锁消除，可以节省无意义的请求锁的时间。锁消除设计的一项关键技术为逃逸分析，即观察某一个变量是否会逃出某一个作用域。

# ThreadLocal

ThreadLocal 表示线程局部变量，只有当前线程才能访问，因此是线程安全的，但是不同线程的 ThreadLocal 如果存放了相同的对象，那么也是线程不安全的，需要在应用层作出保证。如果共享对象对于竞争的处理容易造成性能损失，则应该考虑使用 ThreadLocal 为每个线程分配单独的对象。

# ThreadLocal.set(T value)

在调用 ThreadLocal 的 set() 方法时，先根据当前线程获取 ThreadLocal.ThreadLocalMap 的一个实例（可以理解为一个 Map），写入数据时，以 ThreadLocal 对象作为 key，写入的数据作为 value。

# ThreadLocal.get()

在调用 ThreadLocal 的 get() 方法时，获取当前线程对应的 ThreadLocal.ThreadLocalMap 实例，再使用 ThreadLocal 对象作为 key 取出数据。

# ThreadLocal.remove()

通过 ThreadLocal 写入的数据是维护在线程内部的，所以只要线程不退出，对象引用就会一直存在。如果使用线程池，在任务结束后不对数据进行清理，则可能会造成内存泄漏，因此在数据使用完成后最好使用 ThreadLocal.remove() 将数据移除。

# 无锁

对于并发而言，锁是一种悲观的策略，它总是假设每次临界区操作都会产生冲突，在获取不到锁时，会阻塞线程执行。而无锁是一种乐观的策略，它假设对资源的访问是没有冲突的，所有线程都可以在非阻塞的情况下执行，无锁策略使用 CAS (Compare And Swap) 来鉴别线程冲突，一旦检测到冲突，就重试当前操作至没有冲突为止。

# CAS

CAS (Compare And Swap，比较交换) 由于其非阻塞性，对死锁问题天生免疫；线程间的相互影响远比基于锁的方式要小；使用无锁的方式完全没有锁竞争和线程间频繁调度带来的系统开销，因此无锁比基于锁的方式拥有更优越的性能。

# CAS 算法

CAS(V, E, N) 包含 3 个参数：

V：要更新的变量的值。
E：变量的预期值。
N：变量需要更新的值。

CAS 是一个原子操作，仅当 V 和 E 相等时，才会将变量的值更新为 N，否则说明有其它线程对这个变量做了修改操作，当前线程放弃更新，最后返回变量的真实值。

# CAS 核心操作

以 AtomicInteger 为例，此类中的核心字段为：

// 实际取值
private volatile int value;

incrementAndGet() 方法的作用是自增 1 并获取变量的值，其内部调用的是 Unsafe 类的 getAndAddInt() 方法。

public final int incrementAndGet() {
    return unsafe.getAndAddInt(this, valueOffset, 1) + 1;
}

/**
 * @param obj 进行修改的AtomicInteger对象
 * @param valueOffset AtomicInteger的value字段的地址偏移量
 * @param i 要增加的数值
 * @return 被修改的变量修改前的值
 */
public final int getAndAddInt(Object obj, long valueOffset, int i) {
    int pre;
    do {
        // 需要修改的变量的当前值
        pre = this.getIntVolatile(obj, valueOffset);
        // CAS操作，成功返回true，失败返回false
    } while(!this.compareAndSwapInt(obj, valueOffset, pre, pre + i));

    return pre;
}

getAndAddInt() 方法被调用后，循环调用 Java Native 方法 compareAndSwapInt()，如果修改成功则退出循环，返回被修改的变量修改前的值，如果修改不成功，则会一直重试直至成功修改。

# ABA 问题

从内存中读取和比较之间，变量的值可能被多次修改，最终回到原来的值，当前线程可能就会误以为此变量未修改。为了解决这类问题，可以引入 AtomicStampedReference，它的内部不仅维护了变量的值，还维护了修改的时间戳（或者可以看作是版本号），当进行 CAS 操作时，对象值和时间戳都满足期望值，修改才会成功。

# 普通字段的原子操作

原子包提供 AtomicIntegerFieldUpdater，AtomicReferenceFieldUpdater 等工具用于给普通资源提供原子操作，其使用方式如下：

T t = new T();
AtomicIntegerFieldUpdater<T> number = AtomicIntegerFieldUpdater.newUpdater(T.class, "number");
number.incrementAndGet(t);

使用这些工具需要注意：

只能增强非 private 字段，即只能修改可见范围内的字段。
被增强的字段必须要用 volatile 字段修饰，用于确保变量被正确的读取。
由于 CAS 会通过对象实例中的偏移量直接进行赋值，所以增强不支持 static 字段。

# Unsafe 类

sun.misc.Unsafe 类封装了一些不安全的操作，主要是为了操作指针，例如：

public native int getInt(Object obj, long offset);

此方法的作用是获取到对象 obj 头部的偏移量为 offset 的 int 值。

← 并发编程（二）：JDK支持并发编程（四）：并行模式与策略 →