读书笔记之《Java 并发编程的艺术》

1、多线程语义

• 即便是单核处理器也支持多线程执行代码，CPU 经过给每一个线程分配 CPU 时间片来执行任务，当前任务执行一个时间片后会切换到下一个任务，因此 CPU 经过不停的切换线程执行。

• 并发执行若是没有达到必定的数量级，速度反而会比串行执行要慢。这是由于线程有建立和上下文切换的开销。

• 如何减小线程建立和上下文切换的开销？（“vmstat 1” 的 cs 参数，查看线程切换的次数）

  • 无锁并发编程。多线程竞争锁时，会引发上下文切换，因此多线程处理数据时，能够用一些办法来避免使用锁，好比 CAS 算法、好比将数据的ID按照 Hash 算法取模分段，不一样的线程处理不一样段的数据。
  • 使用最少线程。避免建立不须要的线程，好比经过线程池等方式。
  • 协程。在单线程里实现多任务的调度，并在单线程里维持多个任务间的切换。

• 如何避免死锁？

  • 避免一个线程同时获取多个锁。
  • 尝试使用定时锁，使用 lock.tryLock(timeout) 来替代使用内部锁机制。
  • 对于数据库锁，加锁和解锁必须在一个数据库链接里，不然会出现解锁失败的状况。

• 在Java SE 1.6中，锁一共有4种状态，级别从低到高依次是：无锁状态、偏向锁状态、轻量级锁状态和重量级锁（也称互斥锁）状态，这几个状态会随着竞争状况逐渐升级。锁能够升级但不能降级，这种策略的目的是为了提升得到锁和释放锁的效率。有意思的是除了偏向锁，JVM 实现锁的方式都用了循环 CAS，即当一个线程想进入同步块的时候使用循环 CAS 的方式来获取锁，当它退出同步块的时候使用循环 CAS 释放锁。
  
  若是只有一个线程进入同步代码块，那么它首先会得到“偏向锁”；当存在线程间竞争的时候，“偏向锁”会撤销，从而使用“轻量级锁”；当线程经过自旋方式始终获取不到“轻量级锁”时（获取锁的线程执行时间过长等缘由），那么“轻量级锁”会膨胀成“重量级锁”。

2、Java 内存模型

• JMM（Java 内存模型）采用共享内存模型，经过控制主内存（Main Memory）与每一个线程的本地内存（Local Memory）之间的交互，来为 Java 程序员提供内存可见性保证。

• 从 Java 源代码到最终实际执行的指令序列，会分别经历“编译器优化的重排序”、“指令级并行的重排序”、“内存系统的重排序”，前一个属于编译器重排序，后两个属于处理器重排序，这些重排序会致使多线程程序出现内存可见性问题。为了保证内存可见性，Java 编译器在生成指令序列的适当位置会插入内存屏障指令来禁止特定类型的处理器重排序。JMM 把内存屏障分为四类：
  

  • 对于会改变程序执行结果的重排序，JMM 要求编译器和处理器必须禁止这种重排序。
  • 对于不会改变程序执行结果的重排序，JMM 对编译器和处理器不作要求。
  • 所以，在程序员看来，程序执行的语义（执行结果）不会改变，happens-before 关系本质上和 as-if-serial 语义是一回事。

• happens-before 是 JMM 最核心的概念。happens-before 规则对应于一个或多个编译器和处理器重排序规则，JMM 经过 happens-before 规则隐藏了复杂的重排序规则以及这些规则的具体实现，而程序员在 happens-before 规则上编程，从而保证内存可见性。

  • 程序顺序规则：一个线程中的每一个操做，happens-before 于该线程中的任意后续操做。这个规则由 as-if-serial 语义保证。
  • 监视器锁规则：对一个锁的解锁，happens-before 于随后对这个锁的加锁。
  • volatile 变量规则：对一个 volatile 域的写，happens-before 于任意后续对这个 volatile 域的读。
  • 传递性：若是 A happens-before B，且 B happens-before C，那么 A happens-before C。

• 顺序一致性内存模型是一个理论参考模型，JMM 和处理器内存模型在设计时一般会以顺序一致性内存模型为参照。

• 顺序一致性模型、JMM、处理器内存模型，内存模型设计由强变弱，由于越是追求性能，内存模型就会设计的越弱，以此减小内存模型对它们的束缚。

3、synchronized、volatile和 final 的内存语义

• 理解 volatile 特性的一个好方法是把对 volatile 变量的单个读/写，当作是使用同一个锁对这些单个读/写操做作了同步。简而言之，volatile 变量自身具备下列特性：

  • 可见性。对一个 volatile 变量的读，老是能看到（任意线程）对这个 volatile 变量最后的写入。
  • 原子性。对任意单个 volatile 变量的读/写具备原子性，但相似于 volatile++ 这种复合操做不具备原子性。

• volatile 关键字如何保证可见性？volatile 的内存语义？

  • 当对 volatile 变量写的时候，会将当前处理器缓存行的数据写回到系统内存。
  • 当对 volatile 变量读的时候，会将当前处理器缓存行的数据置为无效，所以要从系统内存中读取变量值。

• volatile 关键字如何保证有序性？

  • 在每一个 volatile 写操做的前面插入一个 StoreStore 屏障（禁止上面的普通写和下面的 volatile 写重排序）。
  • 在每一个 volatile 写操做的后面插入一个 StoreLoad 屏障（防止上面的 volatile 写与下面可能有的 volatile 读/写重排序）。
  • 在每一个 volatile 读操做的后面插入一个 LoadLoad 屏障（禁止下面全部的普通读操做和上面的 volatile 读重排序）。
  • 在每一个 volatile 读操做的后面插入一个 LoadStore 屏障（禁止下面全部的普通写操做和上面的 volatile 读重排序）。

• 为何 JDK 文档说 CAS 同时具备 volatile 读和 volatile 写的内存语义？

  • 编译器不会对 volatile 读与 volatile 读后面的任意内存操做重排序。
  • 编译器不会对 volatile 写与 volatile 写前面的任意内存操做重排序。
  • CAS（compare and swap）操做意味着要对 volatile 变量先读后写，要同时具有 volatile 读和写的语义，所以编译器不能对 CAS 与 CAS 前面和后面的任意内存操做重排序。

• Synchonized 关键字的原理？JVM 基于进入和退出 Monitor 对象来实现方法同步和代码块同步，但二者的实现细节不同。代码块同步是使用 monitorenter 和 monitorexit 指令实现的，而方法同步是使用另一种方式实现的，细节在 JVM 规范里并无详细说明。

• 锁的释放和获取的内存语义？

  • 当线程释放锁时，JMM 会把该线程对应的本地内存中的共享变量刷新到主内存中。（和 volatile 写的内存语义相同）
  • 当线程获取锁时，JMM 会把该线程对应的本地内存置为无效，所以要从系统内存中读取变量值。（和 volatile 读的内存语义相同）

• 对于 final 变量，编译器和处理器要遵照两个重排序规则（对象引用不在构造函数中“溢出”的状况下）：

  • 在构造函数内对一个 final 变量的写入，与随后把这个被构造对象的引用赋值给一个引用变量，这两个操做之间不能重排序。
  • 初次读一个包含 final 变量的对象引用，与随后初次读这个 final 变量，这两个操做之间不能重排序。

• final 变量的内存语义？

  • 写 final 变量的重排序规则会要求编译器在 final 变量的写以后，构造函数 return 以前插入一个 StoreStore 屏障。
  • 读 final 变量的重排序规则会要求编译器在读 final 变量的操做前面插入一个 LoadLoad 屏障。

• 在构造函数内部，不能让这个被构造对象的引用为其余线程所见，也就是对象引用不能在构造函数中“溢出”。由于 JMM 没法保证在构造函数中“对变量的写”和“被构造对象的引用” 这二者之间是否会被重排序。

4、其余

• jps 和 jstack 命令？

  • jps：查看 JVM 进程信息
  • jstack：查看某个JVM进程的堆栈信息
  • 用 jstack 命令dump线程信息，看看 pid 为 18023 的进程里的线程都在作什么。

  jstack 18023 > /home/wwwroot/dump18023

  • 统计线程分别处于什么状态

  grep java.lang.Thread.State dump18023 | awk '{print $2$3$4$5}' | sort | uniq -c

• 可使用ODPS、Hadoop 或者本身搭建服务器集群来解决硬件资源限制的问题。

• 一个对象的引用占 4 个字节。