《Java并发编程的艺术》读书笔记（一）

发表于 分类于 评论数： 阅读次数：
本文字数： 13k 阅读时长 ≈ 22 分钟

笔记内容包含第一章～第三章

上下文

CPU通过时间片分配算法来循环执行任务，当前任务执行一个时间片后会切换到下一个任务。但是，在切换前会保存上一个任务的状态，以便下次切换回这个任务时，可以再加载这个任务的状态。所以任务从保存到再加载的过程就是一次上下文切换。

上下文切换也会影响多线程的执行速度。

dump线程信息里WAITING(on object monitor)的线程少了，系统上下文切换的次数就会少，因为每一次从WAITTING到RUNNABLE都会进行一次上下文的切换。

死锁

避免死锁的常见方法

  • 避免一个线程同时获取多个锁。
  • 避免一个线程在锁内同时占用多个资源，尽量保证每个锁只占用一个资源。
  • 尝试使用定时锁，使用lock.tryLock（timeout）来替代使用内部锁机制。
  • 对于数据库锁，加锁和解锁必须在一个数据库连接里，否则会出现解锁失败的情况。

volatile

在多处理器下，为了保证各个处理器的缓存是一致的，就会实现缓存一致性协议，每个处理器通过嗅探在总线上传播的数据来检查自己缓存的值是不是过期了，当处理器发现自己缓存行对应的内存地址被修改，就会将当前处理器的缓存行设置成无效状态，当处理器对这个数据进行修改操作的时候，会重新从系统内存中把数据读到处理器缓存里。

volatile的两条实现原则

  • Lock前缀指令会引起处理器缓存回写到内存
  • 一个处理器的缓存回写到内存会导致其他处理器的缓存无效

synchronized

synchronized实现同步的基础，Java中的每一个对象都可以作为锁：

  • 对于普通同步方法，锁是当前实例对象。
  • 对于静态同步方法，锁是当前类的Class对象。
  • 对于同步方法块，锁是Synchonized括号里配置的对象。

Synchonized在JVM里的实现原理，JVM基于进入和退出Monitor对象来实现方法同步和代码块同步，但两者的实现细节不一样。

代码块同步是使用monitorenter和monitorexit指令实现的，而方法同步是使用另外一种方式实现的，细节在JVM规范里并没有详细说明。但是，方法的同步同样可以使用这两个指令来实现。

monitorenter指令是在编译后插入到同步代码块的开始位置，而monitorexit是插入到方法结束处和异常处，JVM要保证每个monitorenter必须有对应的monitorexit与之配对。

任何对象都有一个monitor与之关联，当且一个monitor被持有后，它将处于锁定状态。线程执行到monitorenter指令时，将会尝试获取对象所对应的monitor的所有权，即尝试获得对象的锁。

synchronized用的锁是存在Java对象头里的。

锁的升级与对比

在Java SE 1.6中，锁一共有4种状态，级别从低到高依次是：无锁状态、偏向锁状态、轻量级锁状态和重量级锁状态，这几个状态会随着竞争情况逐渐升级。锁可以升级但不能降级，意味着偏向锁升级成轻量级锁后不能降级成偏向锁。这种锁升级却不能降级的策略，目的是为了提高获得锁和释放锁的效率。

下图中的线程1演示了偏向锁初始化的流程，线程2演示了偏向锁撤销的流程：
Java锁的升级

原子操作

锁机制保证了只有获得锁的线程才能够操作锁定的内存区域。JVM内部实现了很多种锁机制，有偏向锁、轻量级锁和互斥锁。有意思的是除了偏向锁，JVM实现锁的方式都用了循环CAS，即当一个线程想进入同步块的时候使用循环CAS的方式来获取锁，当它退出同步块的时候使用循环CAS释放锁。

CAS 即Compare And Swap

通过锁实现原子操作：

1
2
3
4
5
6
7
8
9
10
11
12
Thread t1 = new Thread(new Runnable() {
    @Override
    public void run() {
        synchronized (A) {
            try {
                Thread.sleep(2000);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        }
    }
});

使用循环CAS实现原子操作：

1
2
3
4
5
6
7
8
9
private void safeCount() {
    for (;;) {
        int i = atomicI.get();
        boolean suc = atomicI.compareAndSet(i, ++i);
        if (suc) {
            break;
        }
    }
}

CAS虽然很高效地解决了原子操作，但是CAS仍然存在三大问题：

  1. ABA问题：如果一个值原来是A，变成了B，又变成了A。java.util.concurrent.atomic包里提供了一个类AtomicStampedReference来解决ABA问题。
  2. 循环时间长开销大：自旋CAS如果长时间不成功，会给CPU带来非常大的执行开销。
  3. 只能保证一个共享变量的原子操作：java.util.concurrent.atomic.AtomicReference类来保证引用对象之间的原子性，就可以把多个变量放在一个对象里来进行CAS操作。

Java内存模型（JMM）

基础

线程之间的通信机制有两种：

  1. 共享内存: 线程之间共享程序的公共状态，通过写-读内存中的公共状态进行隐式通信。
  2. 消息传递: 线程之间没有公共状态，线程之间必须通过发送消息来显式进行通信。

同步是指程序中用于控制不同线程间操作发生相对顺序的机制。在共享内存并发模型里，同步是显式进行的。

Java的并发采用的是共享内存模型，Java线程之间的通信总是隐式进行，整个通信过程对程序员完全透明。

为了提高性能，编译器和处理器常常会对指令做重排序。重排序分3种类型：

  1. 编译器优化的重排序：编译器在不改变单线程程序语义的前提下，可以重新安排语句的执行顺序。
  2. 指令级并行的重排序：如果不存在数据依赖性，处理器可以改变语句对应机器指令的执行顺序。
  3. 内存系统的重排序：由于处理器使用缓存和读/写缓冲区，这使得加载和存储操作看上去可能是在乱序执行。

从Java源代码到最终实际执行的指令序列，会分别经历下面3种重排序，如下图所示：

重排序是指编译器和处理器为了优化程序性能而对指令序列进行重新排序的一种手段。

as-if-serial语义的意思是：不管怎么重排序（编译器和处理器为了提高并行度），（单线程）程序的执行结果不能被改变。

为了遵守as-if-serial语义，编译器和处理器不会对存在数据依赖关系的操作做重排序，因为这种重排序会改变执行结果。但是，如果操作之间不存在数据依赖关系，这些操作就可能被编译器和处理器重排序。

在多线程程序中，对存在控制依赖的操作重排序，可能会改变程序的执行结果。

顺序一致性

JMM对正确同步的多线程程序的内存一致性做了如下保证：

如果程序是正确同步的，程序的执行将具有顺序一致性（Sequentially Consistent）——即程序的执行结果与该程序在顺序一致性内存模型中的执行结果相同。

顺序一致性内存模型有两大特性：

  1. 一个线程中的所有操作必须按照程序的顺序来执行。
  2. （不管程序是否同步）所有线程都只能看到一个单一的操作执行顺序。在顺序一致性内存模型中，每个操作都必须原子执行且立刻对所有线程可见。

每次处理器和内存之间的数据传递都是通过一系列步骤来完成的，这一系列步骤称之为总线事务（BusTransaction）。
总线事务包括读事务（Read Transaction）和写事务（Write Transaction）。

读事务从内存传送数据到处理器，写事务从处理器传送数据到内存，每个事务会读/写内存中一个或多个物理上连续的字。

在一些32位的处理器上，如果要求对64位数据的写操作具有原子性，会有比较大的开销。为了照顾这种处理器，Java语言规范鼓励但不强求JVM对64位的long型变量和double型变量的写操作具有原子性。

当JVM在这种处理器上运行时，可能会把一个64位long/double型变量的写操作拆分为两个32位的写操作来执行。这两个32位的写操作可能会被分配到不同的总线事务中执行，此时对这个64位变量的写操作将不具有原子性。

同步原语

volatile

锁的happens-before规则保证释放锁和获取锁的两个线程之间的内存可见性，这意味着对一个volatile变量的读，总是能看到（任意线程）对这个volatile变量最后的写入。

特性:

  1. 可见性：对一个volatile变量的读，总是能看到（任意线程）对这个volatile变量最后的写入。
  2. 原子性：对任意单个volatile变量的读/写具有原子性，但类似于volatile++这种复合操作不具有原子性。

volatile写的内存语义如下：

当写一个volatile变量时，JMM会把该线程对应的本地内存中的共享变量值刷新到主内存。

volatile读的内存语义如下：

当读一个volatile变量时，JMM会把该线程对应的本地内存置为无效。线程接下来将从主内存中读取共享变量。

前文提到过重排序分为编译器重排序和处理器重排序。为了实现volatile内存语义，JMM会分别限制这两种类型的重排序类型。下表是JMM针对编译器制定的volatile重排序规则表：

从上表我们可以看出：

  • 当第二个操作是volatile写时，不管第一个操作是什么，都不能重排序。这个规则确保volatile写之前的操作不会被编译器重排序到volatile写之后。
  • 当第一个操作是volatile读时，不管第二个操作是什么，都不能重排序。这个规则确保volatile读之后的操作不会被编译器重排序到volatile读之前。
  • 当第一个操作是volatile写，第二个操作是volatile读时，不能重排序。

对volatile写和volatile读的内存语义做个总结：

  • 线程A写一个volatile变量，实质上是线程A向接下来将要读这个volatile变量的某个线程发出了（其对共享变量所做修改的）消息。
  • 线程B读一个volatile变量，实质上是线程B接收了之前某个线程发出的（在写这个volatile变量之前对共享变量所做修改的）消息。
  • 线程A写一个volatile变量，随后线程B读这个volatile变量，这个过程实质上是线程A通过主内存向线程B发送消息。

由于volatile仅仅保证对单个volatile变量的读/写具有原子性，而锁的互斥执行的特性可以确保对整个临界区代码的执行具有原子性。在功能上，锁比volatile更强大；在可伸缩性和执行性能上，volatile更有优势。如果读者想在程序中用volatile代替锁，请一定谨慎，具体详情请参阅Brian Goetz的文章《Java理论与实践：正确使用Volatile变量》。

synchronized

锁释放和锁获取的内存语义总结：

  • 线程A释放一个锁，实质上是线程A向接下来将要获取这个锁的某个线程发出了（线程A对共享变量所做修改的）消息。
  • 线程B获取一个锁，实质上是线程B接收了之前某个线程发出的（在释放这个锁之前对共享变量所做修改的）消息。
  • 线程A释放锁，随后线程B获取这个锁，这个过程实质上是线程A通过主内存向线程B发送消息。

锁释放与volatile写有相同的内存语义；锁获取与volatile读有相同的内存语义。

借助ReentrantLock类的源代码，来分析锁内存语义的具体实现机制。

在ReentrantLock中，调用lock()方法获取锁；调用unlock()方法释放锁。

ReentrantLock的实现依赖于Java同步器框架AbstractQueuedSynchronizer（本文简称之为AQS）。
AQS使用一个整型的volatile变量（命名为state）来维护同步状态，马上我们会看到，这个volatile变量是ReentrantLock内存语义实现的关键。

ReentrantLock分为公平锁和非公平锁，我们首先分析公平锁。
使用公平锁时，加锁方法lock()调用轨迹如下：

  1. ReentrantLock:lock()
  2. FairSync:lock()
  3. AbstractQueuedSynchronizer:acquire(int arg)
  4. ReentrantLock:tryAcquire(int acquires)

在第4步真正开始加锁，下面是该方法的源代码:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
protected final boolean tryAcquire(int acquires) {
    final Thread current = Thread.currentThread();
    int c = getState();     // 获取锁的开始，首先读volatile变量state
    if (c == 0) {
        if (!hasQueuedPredecessors() &&
            compareAndSetState(0, acquires)) {
            setExclusiveOwnerThread(current);
            return true;
        }
    }
    else if (current == getExclusiveOwnerThread()) {
        int nextc = c + acquires;
        if (nextc < 0)
            throw new Error("Maximum lock count exceeded");
        setState(nextc);
        return true;
    }
    return false;
}

从上面源代码中我们可以看出，加锁方法首先读volatile变量state。

在使用公平锁时，解锁方法unlock()调用轨迹如下:

  1. ReentrantLock:unlock()
  2. AbstractQueuedSynchronizer:release(int arg)
  3. Sync:tryRelease(int releases)

在第3步真正开始释放锁，下面是该方法的源代码:

1
2
3
4
5
6
7
8
9
10
11
12
protected final boolean tryRelease(int releases) {
    int c = getState() - releases;
    if (Thread.currentThread() != getExclusiveOwnerThread())
        throw new IllegalMonitorStateException();
    boolean free = false;
    if (c == 0) {
        free = true;
        setExclusiveOwnerThread(null);
    }
    setState(c);        // 释放锁的最后，写volatile变量state
    return free;
}

从上面的源代码可以看出，在释放锁的最后写volatile变量state。

非公平锁的释放和公平锁完全一样，所以这里仅仅分析非公平锁的获取。

使用非公平锁时，加锁方法lock()调用轨迹如下:

  1. ReentrantLock:lock()
  2. NonfairSync:lock()
  3. AbstractQueuedSynchronizer:compareAndSetState(int expect,int update)

在第3步真正开始加锁，下面是该方法的源代码:

1
2
3
protected final boolean compareAndSetState(int expect, int update) {
    return unsafe.compareAndSwapInt(this, stateOffset, expect, update);
}

该方法以原子操作的方式更新state变量,JDK文档对该方法的说明如下：
如果当前状态值等于预期值，则以原子方式将同步状态设置为给定的更新值。
此操作具有volatile读和写的内存语义。

经过上面的分析，现在我们终于能明白为什么JDK文档说CAS同时具有volatile读和volatile写的内存语义了。

公平锁和非公平锁的内存语义总结:

  • 公平锁和非公平锁释放时，最后都要写一个volatile变量state。
  • 公平锁获取时，首先会去读volatile变量。
  • 非公平锁获取时，首先会用CAS更新volatile变量，这个操作同时具有volatile读和volatile写的内存语义。

锁释放-获取的内存语义的实现至少有下面两种方式：

  1. 利用volatile变量的写-读所具有的内存语义。
  2. 利用CAS所附带的volatile读和volatile写的内存语义

final

只要对象是正确构造的（被构造对象的引用在构造函数中没有“逸出（escape）”），那么不需要使用同步（指lock和volatile的使用）就可以保证任意线程都能看到这个final域在构造函数中被初始化之后的值。

要得到这个效果，还需要一个保证：
在构造函数内部，不能让这个被构造对象的引用为其他线程所见，也就是对象引用不能在构造函数中“逸出”。

为了说明问题，让我们来看下面的示例代码：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
public class FinalReferenceEscapeExample {
    final int                          i;
    static FinalReferenceEscapeExample obj;

    public FinalReferenceEscapeExample() {
        i = 1;       // 1 写final域
        obj = this;  // 2 this引用在此"逸出"
    }

    public static void writer() {
        new FinalReferenceEscapeExample();
    }

    public static void reader() {
        if (obj != null) {      // 3
            int temp = obj.i;   // 4
        }
    }
}

两个线程，线程a执行writer方法，由于操作1和2可能被重排序，当线程b执行reader方法时获取到的final域可能还是未初始化的。

因此，在构造函数返回前，被构造对象的引用不能为其他线程所见，因为此时的final域可能还没有被初始化。在构造函数返回后，任意线程都将保证能看到final域正确初始化之后的值。

设计原理

happens-before

《JSR-133:Java Memory Model and Thread Specification》对happens-before关系的定义：

  1. 如果一个操作happens-before另一个操作，那么第一个操作的执行结果将对第二个操作可见，而且第一个操作的执行顺序排在第二个操作之前。
  2. 两个操作之间存在happens-before关系，并不意味着Java平台的具体实现必须要按照happens-before关系指定的顺序来执行。如果重排序之后的执行结果，与按happens-before关系来执行的结果一致，那么这种重排序并不非法（也就是说，JMM允许这种重排序）。

happens-before关系本质上和as-if-serial语义是一回事，都是为了在不改变程序执行结果的前提下，尽可能地提高程序执行的并行度。

happens-before规则：

  1. 程序顺序规则：一个线程中的每个操作，happens-before于该线程中的任意后续操作。
  2. 监视器锁规则：对一个锁的解锁，happens-before于随后对这个锁的加锁。
  3. volatile变量规则：对一个volatile域的写，happens-before于任意后续对这个volatile域的读。
  4. 传递性：如果A happens-before B，且B happens-before C，那么A happens-before C。
  5. start()规则：如果线程A执行操作ThreadB.start()（启动线程B），那么A线程的ThreadB.start()操作happens-before于线程B中的任意操作。
  6. join()规则：如果线程A执行操作ThreadB.join()并成功返回，那么线程B中的任意操作happens-before于线程A从ThreadB.join()操作成功返回。

双重检查锁定与延迟初始化

在Java程序中，有时候可能需要推迟一些高开销的对象初始化操作，并且只在使用这些对象时才进行初始化。此时，可能会采用延迟初始化。但要正确实现线程安全的延迟初始化需要一些技巧，否则很容易出现问题。

比如，下面是非线程安全的延迟初始化对象的示例代码：

1
2
3
4
5
6
7
8
9
10
11
12
public class UnsafeLazyInitialization {
    private static Instance instance;

    public static Instance getInstance() {
        if (instance == null)           // 1：A线程执行
            instance = new Instance();  // 2：B线程执行
        return instance;
    }

    static class Instance {
    }
}

instance=new Singleton()创建了一个对象。这一行代码可以分解为如下的3行伪代码:

1
2
3
memory = allocate();  // 1：分配对象的内存空间
ctorInstance(memory); // 2：初始化对象
instance = memory;    // 3：设置instance指向刚分配的内存地址

上面3行伪代码中的2和3之间，可能会被重排序:

1
2
3
memory = allocate();    // 1：分配对象的内存空间
instance = memory;      // 3：设置instance指向刚分配的内存地址 注意，此时对象还没有被初始化！
ctorInstance(memory);   // 2：初始化对象

上面3行伪代码的2和3之间虽然被重排序了，但这个重排序并不会违反Java语言规范里的intra-thread semantics。这个重排序在没有改变单线程程序执行结果的前提下，可以提高程序的执行性能。

intra-thread semantics允许那些在单线程内，不会改变单线程程序执行结果的重排序。

因此在UnsafeLazyInitialization类中，假设A线程执行代码1的同时，B线程执行代码2。此时，线程A可能会看到instance引用的对象还没有完成初始化，最终导致创建了多个对象实例。

可以对getInstance()方法做同步处理来实现线程安全的延迟初始化。示例代码如下：

1
2
3
4
5
6
7
8
9
10
11
12
public class SafeLazyInitialization {
    private static Instance instance;

    public synchronized static Instance getInstance() {
        if (instance == null)
            instance = new Instance();
        return instance;
    }

    static class Instance {
    }
}

由于对getInstance()方法做了同步处理，synchronized将导致性能开销。如果getInstance()方法被多个线程频繁的调用，将会导致程序执行性能的下降。反之，如果getInstance()方法不会被多个线程频繁的调用，那么这个延迟初始化方案将能提供令人满意的性能。

在早期的JVM中，synchronized（甚至是无竞争的synchronized）存在巨大的性能开销。因此出现了双重检查锁定：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
public class DoubleCheckedLocking {                     //1
    private static Instance instance;                   //2

    public static Instance getInstance() {              //3
        // 在对象创建好之后，执行getInstance()方法将不需要获取锁，直接返回已创建好的对象
        if (instance == null) {                         //4:第一次检查
            // 多个线程试图在同一时间创建对象时，会通过加锁来保证只有一个线程能创建对象。
            synchronized (DoubleCheckedLocking.class) { //5:加锁
                if (instance == null)                   //6:第二次检查
                    instance = new Instance();          //7:问题的根源出在这里
            }                                           //8
        }                                               //9
        return instance;                                //10
    }                                                   //11

    static class Instance {
    }
}

如上面代码所示，如果第一次检查instance不为null，那么就不需要执行下面的加锁和初始化操作。因此，可以大幅降低synchronized带来的性能开销。

前面提到线程A执行到第7步代码可能会发生重排序。如果发生重排序，另一个并发执行的线程B就有可能在第4步判断instance不为null。
线程B接下来将访问instance所引用的对象，但此时这个对象可能还没有被A线程初始化。

下图是这个场景的具体执行时序：

这里A2和A3虽然重排序了，但Java内存模型的intra-thread semantics将确保A2一定会排在A4前面执行。因此，线程A的intra-thread semantics没有改变，但A2和A3的重排序，将导致线程B在B1处判断出instance不为空，线程B接下来将访问instance引用的对象。此时，线程B将会访问到一个还未初始化的对象，因此可能会导致线程安全问题。

可以看这个帖子加强理解。

有两个办法来实现线程安全的延迟初始化：

  1. 不允许A2和A3重排序 — 基于volatile的解决方案
  2. 允许A2和A3重排序，但不允许其他线程“看到”这个重排序 — 基于类初始化的解决方案
基于volatile的解决方案

把instance声明为volatile型，就可以实现线程安全的延迟初始化。请看下面的示例代码：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
public class SafeDoubleCheckedLocking {
    private volatile static Instance instance;

    public static Instance getInstance() {
        if (instance == null) {
            synchronized (SafeDoubleCheckedLocking.class) {
                if (instance == null)
                    instance = new Instance();  // instance为volatile，现在没问题了
            }
        }
        return instance;
    }

    static class Instance {
    }
}

当声明对象的引用为volatile后，上面的3行伪代码中的2和3之间的重排序，在多线程环境中将会被禁止。

基于类初始化的解决方案

JVM在类的初始化阶段（即在Class被加载后，且被线程使用之前），会执行类的初始化。在执行类的初始化期间，JVM会去获取一个锁，这个锁可以同步多个线程对同一个类的初始化。

基于这个特性，可以实现另一种线程安全的延迟初始化方案（这个方案被称之为Initialization On Demand Holder idiom）：

1
2
3
4
5
6
7
8
9
10
11
12
public class InstanceFactory {
    private static class InstanceHolder {
        public static Instance instance = new Instance();
    }

    public static Instance getInstance() {
        return InstanceHolder.instance; // 这里将导致InstanceHolder类被初始化
    }

    static class Instance {
    }
}

Java语言规范规定，对于每一个类或接口C，都有一个唯一的初始化锁LC与之对应。从C到LC的映射，由JVM的具体实现去自由实现。JVM在类初始化期间会获取这个初始化锁，并且每个线程至少获取一次锁来确保这个类已经被初始化过了。

通过对比基于volatile的双重检查锁定的方案和基于类初始化的方案，我们会发现基于类初始化的方案的实现代码更简洁。
但基于volatile的双重检查锁定的方案有一个额外的优势：
除了可以对静态字段实现延迟初始化外，还可以对实例字段实现延迟初始化。

字段延迟初始化降低了初始化类或创建实例的开销，但增加了访问被延迟初始化的字段
的开销。
在大多数时候，正常的初始化要优于延迟初始化。如果确实需要对实例字段使用线程安全的延迟初始化，请使用上面介绍的基于volatile的延迟初始化的方案；如果确实需要对静态字段使用线程安全的延迟初始化，请使用上面介绍的基于类初始化的方案。

以上，如有问题欢迎提出！

如果对您有所帮助，欢迎投食！
0%