深入理解并发编程和归纳总结

CPU和内存之间的关系

我们处理业务的话，一般都要用到CPU和内存。假如CPU和内存之间没有一个高速缓冲层区，我们处理数据要从内存中取，CPU计算完之后，又要放到内存；但是内存的读写很慢，这样CPU就只能干等着了，浪费资源。

        所以在CPU和内存之间添加了一层读写速度尽可能接近处理速度的高速缓存作为内存和CPU之间的缓冲：将运算需要使用到的数据复 制到缓存中，让运算能快速进行，当运算结束后再从缓存同步回内存之中，这样 处理器就无须等待缓慢的内存读写了。

 

        

在计算机系统中，寄存器划是 L0 级缓存，接着依次是 L1，L2，L3（接下来 是内存，本地磁盘，远程存储）。越往上的缓存存储空间越小，速度越快，成本 也更高；越往下的存储空间越大，速度更慢，成本也更低。从上至下，每一层都可以看做是更下一层的缓存，即：L0 寄存器是 L1 一级缓存的缓存，L1 是 L2 的缓存，依次类推；每一层的数据都是来至它的下一层，所以每一层的数据是下一层的数据的子集。

Java内存模型（JMM）：

        从抽象的角度来看，JMM 定义了线程和主内存之间的抽象关系：线程之间 的共享变量存储在主内存（Main Memory）中，每个线程都有一个私有的本地内 存（Local Memory），本地内存中存储了该线程以读/写共享变量的副本。本地内存是 JMM 的一个抽象概念，并不真实存在。它涵盖了缓存、写缓冲区、寄存器以及其他的硬件和编译器优化。

 可见性：

        可见性是指当多个线程访问同一个变量时，一个线程修改了这个变量的值， 其他线程能够立即看得到修改的值。 由于线程对变量的所有操作都必须在工作内存中进行，而不能直接读写主内存中的变量，那么对于共享变量 V，它们首先是在自己的工作内存，之后再同步 到主内存。可是并不会及时的刷到主存中，而是会有一定时间差。很明显，这个时候线程 A 对变量 V 的操作于线程 B 而言就不具备可见性了。

        要解决共享对象可见性这个问题，我们可以使用 volatile 关键字或者是加锁。

原子性：

        原子性：即一个操作或者多个操作 要么全部执行并且执行的过程不会被任何因素打断，要么就都不执行。我们都知道 CPU 资源的分配都是以线程为单位的,并且是分时调用,操作系统 允许某个进程执行一小段时间，例如 50 毫秒，过了 50 毫秒操作系统就会重新选择一个进程来执行（我们称为“任务切换”），这个 50 毫秒称为“时间片”。而任务的切换大多数是在时间片段结束以后, 那么线程切换为什么会带来 bug 呢？因为操作系统做任务切换，可以发生在任何一条 CPU 指令执行完！注意，是 CPU 指令，CPU 指令，CPU 指令，而不是高级语言里的一条语句。比如 count++，在 java 里就是一句话，但高级语言里一条语句往往需要多条 CPU 指令完成。其实 count++至少包含了三个 CPU 指令！   

Volatile详解     

volatile特性：

        可以把对volatile变量的单个读/写，看成是使用同一个锁对这些单个读/写操作做了同步。

public class VolatileTest {
    
    public static volatile long i = 0l;

    public static long getI() {
        return i; // 单个volatile变量的读
    }

    public static void setI(long i) {
        VolatileTest.i = i; // 单个volatile变量的写
    }
    
    public void add(){
        i++; // 多个volatile变量的读/写
    }
}

public class VolatileTest {

    public static  long i = 0l;

    public static synchronized long getI() {
        return i; // 单个volatile变量的读
    }

    public static synchronized void setI(long i) {
        VolatileTest.i = i; // 单个volatile变量的写
    }

    public void add(){
        long temp = getI(); // 调用已同步的读方法
        temp = temp+1; // 普通写操作
        setI(temp); // 调用已同步的写方法
    }
}

上面两份代码是等同的，所以volatile变量自身具有下列特性：

        可见性。对一个 volatile 变量的读，总是能看到（任意线程）对这个 volatile 变量最后的写入。 

        原子性：对任意单个 volatile 变量的读/写具有原子性，但类似于 volatile++ 这种复合操作不具有原子性。 

        volatile 虽然能保证执行完及时把变量刷到主内存中，但对于 count++这种非 原子性、多指令的情况，由于线程切换，线程 A 刚把 count=0 加载到工作内存， 线程 B 就可以开始工作了，这样就会导致线程 A 和 B 执行完的结果都是 1，都写 到主内存中，主内存的值还是 1 不是 2 。

 volatile的实现原理：

        volatile关键字修饰的变量会存在一个"lock:"的前缀。

        lock前缀，Lock不是一种内存屏障，但是它能完成类似内存屏蔽的功能。lock会对CPU总线和高速缓存加锁，可以理解为CPU指令级的一种锁。

        同时该指令会将当前处理器缓存行的数据直接写入到系统内存中，而且这个写回内存的操作会使在其他CPU里缓存了该地址的数据无效。

synchronized的实现原理

        Synchronized 在 JVM 里的实现都是基于进入和退出 Monitor 对象来实现方法 

同步和代码块同步，虽然具体实现细节不一样，但是都可以通过成对的 MonitorEnter 和 MonitorExit 指令来实现。 

        对同步块，MonitorEnter 指令插入在同步代码块的开始位置，而 monitorExit 指令则插入在方法结束处和异常处，JVM 保证每个 MonitorEnter 必须有对应的 MonitorExit。总的来说，当代码执行到该指令时，将会尝试获取该对象 Monitor 的所有权，即尝试获得该对象的锁： 

        1、如果 monitor 的进入数为 0，则该线程进入 monitor，然后将进入数设置 为 1，该线程即为 monitor 的所有者。 

        2、如果线程已经占有该 monitor，只是重新进入，则进入 monitor 的进入数 加 1.

        3.如果其他线程已经占用了 monitor，则该线程进入阻塞状态，直到 monitor 的进入数为 0，再重新尝试获取 monitor 的所有权。

synchronized修饰方法的话，反编译是这样的：

flags标识符中多了一个ACC_SYNCHRONIED，JVM 就是根据该标示符来实现方法的同步的：当方法被调用时，调用指令将 会检查方法的 ACC_SYNCHRONIZED 访问标志是否被设置，如果设置了，执行线 程将先获取 monitor，获取成功之后才能执行方法体，方法执行完后再释放 monitor。在方法执行期间，其他任何线程都无法再获得同一个 monitor 对象。

synchronized修饰代码块的话，反编译是这样的：

 

 

synchronized 使用的锁是存放在 Java 对象头里面，Java 对象的对象头由 mark word 和 klass pointer 两部分组成： 

        1）mark word 存储了同步状态、标识、hashcode、GC 状态等等。 

        2）klass pointer 存储对象的类型指针，该指针指向它的类元数据 

        另外对于数组而言还会有一份记录数组长度的数据。 

这个是JVM的知识，前面有提到。

        锁信息则是存在于对象的 mark word 中，MarkWord 里默认数据是存储对象 的 HashCode 等信息：

但是会随着对象的运行改变而发生变化，不同的锁状态对应着不同的记录存 储方式：

 

 了解各种锁

锁的状态：

        一共有四种状态，无锁状态，偏向锁状态，轻量级锁状态和重量级锁状态，它会随着竞争情况逐渐升级。锁可以升级但不能降级，目的是为了提高获得锁和释放锁的效率。

偏向锁：

        引入背景：大多数情况下锁不仅不存在多线程竞争，而且总是由同一线程多 次获得，为了让线程获得锁的代价更低而引入了偏向锁，减少不必要的 CAS 操作。 

        偏向锁，顾名思义，它会偏向于第一个访问锁的线程，如果在运行过程中， 同步锁只有个线程访问，不存在多线程争用的情况，则线程是不需要触发同步的，减少加锁／解锁的一些 CAS 操作（比如等待队列的一些 CAS 操作），这种情况下，就会给线程加一个偏向锁。 如果在运行过程中，遇到了其他线程抢占锁，则持有偏向锁的线程会被挂起，JVM 会消除它身上的偏向锁，将锁恢复到标准的轻量级锁。它通过消除资源无竞争情况下的同步原语，进一步提高了程序的运行性能。

偏向锁获取过程： 

        步骤 1、 访问 Mark Word 中偏向锁的标识是否设置成 1，锁标志位是否为01，确认为可偏向状态。 

        步骤 2、 如果为可偏向状态，则测试线程 ID 是否指向当前线程，如果是，进入步骤 5，否则进入步骤 3。 

        步骤 3、 如果线程 ID 并未指向当前线程，则通过 CAS 操作竞争锁。如果竞 争成功，则将 Mark Word 中线程 ID 设置为当前线程 ID，然后执行 5；如果竞争 失败，执行 4。

        步骤 4、 如果 CAS 获取偏向锁失败，则表示有竞争。当到达全局安全点（safepoint）时获得偏向锁的线程被挂起，偏向锁升级为轻量级锁，然后被阻塞在安全点的线程继续往下执行同步代码。（撤销偏向锁的时候会导致 stop the word）

        步骤 5、 执行同步代码。

偏向锁的释放：

        偏向锁的撤销在上述第四步骤中有提到。偏向锁只有遇到其他线程尝试竞争偏向锁时，持有偏向锁的线程才会释放偏向锁，线程不会主动去释放偏向锁。偏向锁的撤销，需要等待全局安全点（在这个时间点上没有字节码正在执行），它会首先暂停拥有偏向锁的线程，判断锁对象是否处于被锁定状态，撤销偏向锁后恢复到未锁定（标志位为“01”）或轻量级锁（标志位为“00”）的状态。 

偏向锁的适用场景 ：

        始终只有一个线程在执行同步块，在它没有执行完释放锁之前，没有其它线程去 执行同步块，在锁无竞争的情况下使用，一旦有了竞争就升级为轻量级锁，升级 为轻量级锁的时候需要撤销偏向锁，撤销偏向锁的时候会导致 stop the word 操 作；在有锁的竞争时，偏向锁会多做很额外操作，尤其是撤销偏向所的时候会导致 进入安全点，安全点会导致 stw，导致性能下降，这种情况下应当禁用。 

jvm 开启/关闭偏向锁 ：

开启偏向锁：-XX:+UseBiasedLocking -XX:BiasedLockingStartupDelay=0 

关闭偏向锁：-XX:-UseBiasedLocking 

 轻量级锁

        轻量级锁是由偏向锁升级来的，偏向锁运行在一个线程进入同步块的情况下，当 第二个线程加入锁争用的时候，偏向锁就会升级为轻量级锁； 

轻量级锁的加锁过程： 

        1、在代码进入同步块的时候，如果同步对象锁状态为无锁状态且不允许进行偏 向（锁标志位为“01”状态，是否为偏向锁为“0”），虚拟机首先将在当前线 程的栈帧中建立一个名为锁记录（Lock Record）的空间，用于存储锁对象目前的Mark Word 的拷贝，官方称之为 Displaced Mark Word。 

        2、拷贝对象头中的 Mark Word 复制到锁记录中。 

        3、拷贝成功后，虚拟机将使用 CAS 操作尝试将对象的 Mark Word 更新为指向 Lock Record 的指针，并将 Lock record 里的 owner 指针指向 object mark word。如果更 新成功，则执行步骤 4，否则执行步骤 5。 

        4、如果这个更新动作成功了，那么这个线程就拥有了该对象的锁，并且对象Mark Word 的锁标志位设置为“00”，即表示此对象处于轻量级锁定状态 

        5、如果这个更新操作失败了，虚拟机首先会检查对象的 Mark Word 是否指向当 前线程的栈帧，如果是就说明当前线程已经拥有了这个对象的锁，那就可以直接进入同步块继续执行。否则说明多个线程竞争锁，那么它就会自旋等待锁，一定次数后仍未获得锁对象。重量级线程指针指向竞争线程，竞争线程也会阻塞，等待轻量级线程释放锁后唤醒他。锁标志的状态值变为“10”，Mark Word 中存储 的就是指向重量级锁（互斥量）的指针，后面等待锁的线程也要进入阻塞状态。

 自旋锁：

        自旋锁属于轻量级锁。

        自旋锁原理非常简单，如果持有锁的线程能在很短时间内释放锁资源，那么那些等待竞争锁的线程就不需要做内核态和用户态之间的切换进入阻塞挂起状态，它们只需要等一等（自旋），等持有锁的线程释放锁后即可立即获取锁，这样就避免用户线程和内核的切换的消耗。

        

自旋锁的优缺点：

        优点：减少线程的阻塞

        缺点：如果所竞争激烈，长时间处于自旋，会造成CPU的浪费

解决办法：JVM 对于自旋次数的选择，jdk1.5 默认为 10 次，在 1.6 引入了适应性自旋锁，适应性自旋锁意味着自旋的时间不在是固定的了，而是由前一次在同一个锁上的自旋时间以及锁的拥有者的状态来决定，基本认为一个线程上下文切换的时间是最佳的一个时间。

不同锁的比较：