java并发编程的艺术01

发表于 | 分类于

以下是《java并发编程的艺术》一书的读书笔记第一部分。

并发的开销

线程有创建和上下文切换的开销，减少上下文切换的方法有无锁并发编程、CAS算法、使用最少线程和使用协程。

  • 无锁并发编程。多线程竞争锁时，会引起上下文切换，所以多线程处理数据时，可以用一些办法来避免使用锁，如将数据的ID按照Hash算法取模分段，不同的线程处理不同段的数据。
  • CAS算法。Java的Atomic包使用CAS算法来更新数据，而不需要加锁。
  • 使用最少线程。避免创建不需要的线程，比如任务很少，但是创建了很多线程来处理，这样会造成大量线程都处于等待状态。
  • 协程：在单线程里实现多任务的调度，并在单线程里维持多个任务间的切换

　对于并发控制而言，我们平时用的锁（synchronized，Lock）是一种悲观的策略。它总是假设每一次临界区操作会产生冲突，因此，必须对每次操作都小心翼翼。如果多个线程同时访问临界区资源，就宁可牺牲性能让线程进行等待，所以锁会阻塞线程执行。

　　与之相对的有一种乐观的策略，它会假设对资源的访问是没有冲突的。既然没有冲突也就无需等待了，所有的线程都在不停顿的状态下持续执行。那如果遇到问题了无锁的策略使用一种叫做比较交换（CAS Compare And Swap）来鉴别线程冲突，一旦检测到冲突产生，就重试当前操作直到没有冲突。CAS算法是非阻塞的，它对死锁问题天生免疫，而且它比基于锁的方式拥有更优越的性能。

　　CAS算法的过程是这样：它包含三个参数 CAS（V,E,N）。V表示要更新的变量，E表示预期的值，N表示新值。仅当V值等于E值时，才会将V的值设置成N，否则什么都不做。最后CAS返回当前V的值。CAS算法需要你额外给出一个期望值，也就是你认为现在变量应该是什么样子，如果变量不是你想象的那样，那说明已经被别人修改过。你就重新读取，再次尝试修改即可。

避免死锁

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

资源限制的挑战

资源限制是指在进行并发编程时，程序的执行速度受限于计算机硬件资源或软件资源。硬件资源限制有带宽的上传/下载速度、硬盘读写速度和CPU的处理速度。软件资源限制有数据库的连接数和socket连接数等。

在并发编程中，将代码执行速度加快的原则是将代码中串行执行的部分变成并发执行，但是如果将某段串行的代码并发执行，因为受限于资源，仍然在串行执行，这时候程序不仅不会加快执行，反而会更慢，因为增加了上下文切换和资源调度的时间。

volatile

volatile是轻量级的synchronized，它在多处理器开发中保证了共享变量的“可见性”。可见性的意思是当一个线程修改一个共享变量时，另外一个线程能读到这个修改的值。如果volatile变量修饰符使用恰当的话，它比synchronized的使用和执行成本更低，因为它不会引起线程上下文的切换和调度。

定义：如果一个字段被声明成volatile，Java线程内存模型确保所有线程看到这个变量的值是一致的。

原理：

  1. 将当前处理器缓存行的数据写回到系统内存。
  2. 这个写回内存的操作会使在其他CPU里缓存了该内存地址的数据无效。

synchronized

利用synchronized实现同步的基础：Java中的每一个对象都可以作为锁。具体表现
为以下3种形式。

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

从JVM规范中可以看到Synchonized在JVM里的实现原理，JVM基于进入和退出Monitor对象来实现方法同步和代码块同步，但两者的实现细节不一样。代码块同步是使用monitorenter和monitorexit指令实现的，而方法同步是使用另外一种方式实现的，细节在JVM规范里并没有详细说明。但是，方法的同步同样可以使用这两个指令来实现。

Monitor 对象

在Monitor Object模式中，主要有四种类型的参与者：

  • 监视者对象（Monitor Object）：负责定义公共的接口方法，这些公共的接口方法会在多线程的环境下被调用执行；

  • 同步方法：这些方法是监视者对象锁定义。为了防止竞争条件，无论是否同时有多个线程并发调用同步方法，还是监视者对象含有多个同步方法，在任一时间内只有监视者对象的一个同步方法能够被执行。

  • 监视锁（Monitor Lock）：每一个监视者对象都会拥有一把监视锁。

  • 监视条件（Monitor Condition）：同步方法使用监视锁和监视条件来决定方法是否需要阻塞或重新执行。

    监视者对象的动态特性

实质上，Java 的 Object 类本身就是监视者对象，Java 对于 Monitor Object 模式做了内建的支持。

Object 类本身就是监视者对象每个 Object 都带了一把看不见的锁，通常叫 内部锁/Monitor 锁/Instrinsic Lock, 这把锁就是 监控锁 synchronized 关键字修饰方法和代码块就是 同步方法wait()/notify()/notifyAll() 方法构成监控条件(Monitor Condition)下图描述了 Java Monitor 的工作机理：

Java Monitor工作机理

任何对象都有一个 monitor 与之关联。当且仅当一个 monitor 被持有后，它将处于锁定状态。

线程执行到 monitorenter 指令时，将会尝试获取objectref 所对应的 monitor 的所有权，那么：如果 objectref 的 monitor 的进入计数器为 0，那线程可以成功进入monitor，以及将计数器值设置为 1。当前线程就是 monitor 的所有。
如果当前线程已经拥有 objectref 的 monitor 的所有权，那它可以重入这个monitor，重入时需将进入计数器的值加 1。如果其他线程已经拥有 objectref 的 monitor 的所有权，那当前线程将被阻塞，直到 monitor 的进入计数器值变为 0 时，重新尝试获取 monitor 的所有权。

执行 monitorexit 指令的线程必须是 objectref 对应的 monitor 的所有者。
指令执行时，线程把 monitor 的进入计数器值减 1，如果减 1 后计数器值为 0，那线程退出 monitor，不再是这个 monitor 的拥有者。其他被这个 monitor 阻塞的线程可以尝试去获取这个 monitor 的所有权。

当一个 synchronized 方法被调用时，自动进入对应的 monitor，当方法返回时，自动退出 monitor， 这些动作是 Java 虚拟机在调用和返回指令中隐式处理的。

Java对象头

HotSpot虚拟机中，对象在内存中存储的布局可以分为三块区域：对象头（Header）、实例数据（Instance Data）和对齐填充（Padding）。synchronized用的锁是存在Java对象头里的，如果对象是数组类型，则虚拟机用3个字宽（Word）存储对象头，如果对象是非数组类型，则用2字宽存储对象头。在32位虚拟机中，1字宽等于4字节，即32bit。

没事有上锁时，对象头里存储了对象的HashCode、分代年龄和锁标记位。当锁标志位变化时，Mark Word可能变化为存储以下4种数据（32位系统）

mark word 状态

锁

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

偏向锁

大多数情况下，锁不仅不存在多线程竞争，而且总是由同一线程多次获得，为了让线程获得锁的代价更低而引入了偏向锁。当一个线程访问同步块并获取锁时，会在对象头和栈帧中的锁记录里存储锁偏向的线程ID，以后该线程在进入和退出同步块时不需要进行CAS操作来加锁和解锁，只需简单地测试一下对象头的Mark Word里是否存储着指向当前线程的偏向锁。如果测试成功，表示线程已经获得了锁。如果测试失败，则需要再测试一下Mark Word中偏向锁的标识是否设置成1（表示当前是偏向锁）：如果没有设置，则使用CAS竞争锁；如果设置了，则尝试使用CAS将对象头的偏向锁指向当前线程。

CAS算法的过程是这样：它包含三个参数 CAS（V,E,N）。V表示要更新的变量，E表示预期的值，N表示新值。仅当V值等于E值时，才会将V的值设置成N，否则什么都不做。最后CAS返回当前V的值。CAS算法需要你额外给出一个期望值，也就是你认为现在变量应该是什么样子，如果变量不是你想象的那样，那说明已经被别人修改过。你就重新读取，再次尝试修改即可。

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

偏向锁

偏向锁在Java 6和Java 7里是默认启用的，但是它在应用程序启动几秒钟之后才激活，如有必要可以使用JVM参数来关闭延迟 -XX:BiasedLockingStartupDelay=0。如果你确定应用程序里所有的锁通常情况下处于竞争状态，可以通过JVM参数关闭偏向锁：-XX:-UseBiasedLocking=false，那么程序默认会进入轻量级锁状态。

轻量级锁

加锁：线程在执行同步块之前，JVM会先在当前线程的栈桢中创建用于存储锁记录的空间，并将对象头中的Mark Word复制到锁记录中，官方称为Displaced Mark Word。然后线程尝试使用CAS将对象头中的Mark Word替换为指向锁记录的指针。如果成功，当前线程获得锁，如果失败，表示其他线程竞争锁，当前线程便尝试使用自旋来获取锁。

解锁：轻量级解锁时，会使用原子的CAS操作将Displaced Mark Word替换回到对象头，如果成功，则表示没有竞争发生。如果失败，表示当前锁存在竞争，锁就会膨胀成重量级锁。下图是两个线程同时争夺锁，导致锁膨胀的流程图。因为自旋会消耗CPU，为了避免无用的自旋（比如获得锁的线程被阻塞住了），一旦锁升级成重量级锁，就不会再恢复到轻量级锁状态。当锁处于这个状态下，其他线程试图获取锁时，都会被阻塞住，当持有锁的线程释放锁之后会唤醒这些线程，被唤醒的线程就会进行新一轮的夺锁之争。

轻量级锁和自旋锁，其实两个是一体使用的，为的是尽量避免线程进入内核的阻塞状态，这对性能非常不利，试图用CAS操作和循环把加锁问题解决掉。

轻量级锁

锁的对比

锁的对比

原子操作

原子操作（atomic operation）意为“不可被中断的一个或一系列操作”。在Java中可以通过锁和循环CAS的方式来实现原子操作。

JDK的并发包里提供了一些类来支持原子操作，如AtomicBoolean（用原子方式更新的boolean值）、AtomicInteger（用原子方式更新的int值）和AtomicLong（用原子方式更新的long值）。这些原子包装类还提供了有用的工具方法，比如以原子的方式将当前值自增1和自减1。

CAS实现原子操作的三大问题

  1. ABA问题。因为CAS需要在操作值的时候，检查值有没有发生变化，如果没有发生变化则更新，但是如果一个值原来是A，变成了B，又变成了A，那么使用CAS进行检查时会发现它的值没有发生变化，但是实际上却变化了。ABA问题的解决思路就是使用版本号。在变量前面追加上版本号，每次变量更新的时候把版本号加1，那么A→B→A就会变成1A→2B→3A。
  2. 循环时间长开销大。自旋CAS如果长时间不成功，会给CPU带来非常大的执行开销。
  3. 只能保证一个共享变量的原子操作。当对一个共享变量执行操作时，我们可以使用循环CAS的方式来保证原子操作，但是对多个共享变量操作时，循环CAS就无法保证操作的原子性，这个时候就可以用锁。还有一个取巧的办法，就是把多个共享变量合并成一个共享变量来操作。比如，有两个共享变量i＝2，j=a，合并一下ij=2a，然后用CAS来操作ij。从Java 1.5开始，JDK提供了AtomicReference类来保证引用对象之间的原子性，就可以把多个变量放在一个对象里来进行CAS操作。

除了CAS外，JVM 还使用锁实现原子操作，但是除了偏向锁以外，其他的锁都用到了CAS。