java多线程基础学习1

pre 准备知识

什么是线程

程序中负责执行的哪个东东就叫做线程（执行路线，进程内部的执行序列），或者说是进程的子任务。

线程有什么特点

1、线程是进程的一个实体，是系统独立调度和分派的基本单位。
2、线程有不同的状态，系统提供了多种线程的控制原语，如创建线程、取消线程、销毁线程等。
3、线程之间的不需要类似于IPC的机制进行数据交换，因为他之间是共享的，但新的问题是如何解决同时访问时的冲突。
4、每个线程有自己独立的线程ID、寄存器信息、函数线、错误码。
5、一个进程可以多个线程它们是并发执行（感觉上是），它们可以执行相同的代码也可以执行不同的代码。
6、当需要同时解决多个任务，而这些任务量不大，相互之间可能需要有大量的数据交换，这种情况就不太适合多进程了，而多线程会比较合适，相比于进程线程的系统开销小，任务切换快。

什么是多线程

首先要先了解俩个概念串行和并行

串行

串行其实是相对於单条线程来执行多个任务来说的，我们就拿下载文件来举个例子，我们下载多个文件，在串行中它是按照一定的顺序去进行下载的，也就是说必须等下载完A之后，才能开始下载B，它们在时间上是不可能发生重叠的。
并行

下载多个文件，开启多条线程，多个文件同时进行下载，这里是严格意义上的在同一时刻发生的，并行在时间上是重叠的。

POSIX线程

早期的UNIX、Linux系统是不支持线程，而随着计算机技术发展，windows系统中实现的线程的使用，随后UNIX、Linux也都可以使用线程了。
刚开始时都是各个计算机厂商自己私有提供的线程库（用进程模拟的），接口和实现的差异非常大，不易于移植。
于1995年IEEE协会制定IEEEPOSIX1003.1c标准，规定了统一的线程编程接口，遵循该标准的线程实现方式被统称为POSIX线程，即pthread。
线程是以库的形式提供的，编译时需要添加 -lpthread 参数。

线程的状态和生命周期

1、新建状态
2、就绪状态

处于就绪状态的线程已经具备了运行条件，但还没有分配到CPU，处于线程就绪队列（就绪池），等待系统为其分配CPU。

3、运行状态

处于运行状态的线程最为复杂，它可以变为阻塞状态、就绪状态和死亡状态。
处于就绪状态的线程，如果获得了cpu的调度，就会从就绪状态变为运行状态，执行run()方法中的任务。
如果该线程失去了cpu资源，就会又从运行状态变为就绪状态，重新等待系统分配资源。
也可以对在运行状态的线程调用yield()方法，它就会让出cpu资源，再次变为就绪状态。

4、阻塞状态
5、死亡状态

并发编程的问题

提到并发就一定会想到几个特性：原子性问题，可见性问题和有序性问题

其实，原子性问题，可见性问题和有序性问题是人们抽象定义出来的。而这个抽象的底层问题就是前面提到的缓存一致性问题、处理器优化问题和指令重排问题等。

回顾一下为了保证数据的安全，需要满足以下三个特性：

原子性，是指在一个操作中，CPU 不可以在中途暂停然后再调度，即不被中断操作，要不执行完成，要不就不执行。

可见性，是指当多个线程访问同一个变量时，一个线程修改了这个变量的值，其他线程能够立即看得到修改的值。

有序性，即程序执行的顺序按照代码的先后顺序执行。

缓存一致性问题其实就是可见性问题。而处理器优化是可以导致原子性问题的。指令重排即会导致有序性问题。

1、线程涉及的关键字

1.1 synchronized

先看下下面的程序和运行结果

package com.prc.ThreadTest;

public class TestThread {

    private int value = 20; // 20张票

    public static void main(String[] args) {

        TestThread t =  new TestThread();

        new Thread(() -> {
            while (true) {
                System.out.println("用户" + Thread.currentThread().getName() + "买了票还剩余" + t.increamentAndGet() + "张票");
                try {
                    Thread.sleep(1000);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
            }
        }, "张三").start();
        new Thread(() -> {
            while (true) {
                System.out.println("用户" + Thread.currentThread().getName() + "买了票还剩余" + t.increamentAndGet() + "张票");
                try {
                    Thread.sleep(1000);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
            }
        }, "王五").start();
        new Thread(() -> {
            while (true) {
                System.out.println("用户" + Thread.currentThread().getName() + "买了票还剩余" + t.increamentAndGet() + "张票");
                try {
                    Thread.sleep(1000);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
            }
        }, "李四").start();
    }

    //synchronized
    public int increamentAndGet() {
        if (value == 0){
            return 0;
        }
        return value--;
    }
}

// 运行结果
用户张三买了票还剩余20张票
用户王五买了票还剩余19张票
用户李四买了票还剩余18张票
用户张三买了票还剩余17张票
用户王五买了票还剩余16张票
用户李四买了票还剩余15张票
用户王五买了票还剩余14张票
用户张三买了票还剩余13张票
用户李四买了票还剩余13张票
用户王五买了票还剩余12张票
用户张三买了票还剩余11张票
用户李四买了票还剩余11张票
用户张三买了票还剩余10张票
用户王五买了票还剩余8张票
用户李四买了票还剩余9张票
用户王五买了票还剩余7张票
用户李四买了票还剩余6张票
用户张三买了票还剩余6张票
用户张三买了票还剩余5张票
用户李四买了票还剩余4张票
用户王五买了票还剩余4张票
用户王五买了票还剩余3张票
用户张三买了票还剩余2张票
用户李四买了票还剩余3张票
用户李四买了票还剩余1张票
用户王五买了票还剩余0张票
用户张三买了票还剩余0张票
用户王五买了票还剩余0张票
用户李四买了票还剩余0张票

可以发现存在俩个人都买了票但是票数只减了一张的情况，当多个线程抢夺同一有限资源的情况下，就会产生这样的场景。经典的模型如：火车购票、多消费者消费库存等。

那如何解决这个问题呢？？带着这个问题我们来学习下synchronized关键字

在java中,synchronized锁大家又通俗的称为:方法锁,对象锁和类锁三种.

1.1.1 方法锁

方法锁其实属于对象锁的一种

修饰方法

synchronized修饰普通方法,锁定的是当前对象.一次只能有一个线程进入同一个对象实例的method()方法.

public synchronized int increamentAndGet() {
    if (value == 0){
        return 0;
    }
    return value--;
}

1.1.2 对象锁

修饰代码块,锁实例对象

public synchronized int increamentAndGet() {
    synchronized (this){
        if (value == 0){
            return 0;
        }
        return value--;
    }
}

1.1.3 类锁

修饰静态方法

public synchronized static int increamentAndGet() {
        
}

修饰代码块,锁类对象

public synchronized  int increamentAndGet() {
    synchronized (TestThread.class){
        if (value == 0){
            return 0;
        }
        return value--;
    }
}

那么最开始的代码可以使用这三种锁进行修改来保证线程安全。下面只贴出关键代码。

// 方法锁方式，将调用的方法设置为synchronized
public synchronized  int increamentAndGet() {
    if (value == 0){
        return 0;
    }
    return value--;
}

// 对象锁
public int increamentAndGet() {
    synchronized (this){
        if (value == 0){
            return 0;
        }
        return value--;
    }
}

// 类锁
public  int increamentAndGet() {
    synchronized (TestThread.class){
        if (value == 0){
            return 0;
        }
        return value--;
    }
}

1.1.4 synchronized的底层原理

下面一段话是转载，原文出处不明

一段synchronized的代码被一个线程执行之前，他要先拿到执行这段代码的权限，
在Java里边就是拿到某个同步对象的锁（一个对象只有一把锁）；
如果这个时候同步对象的锁被其他线程拿走了，他（这个线程）就只能等了（线程阻塞在锁池等待队列中）。
取到锁后，他就开始执行同步代码(被synchronized修饰的代码）；
线程执行完同步代码后马上就把锁还给同步对象，其他在锁池中等待的某个线程就可以拿到锁执行同步代码了。
这样就保证了同步代码在统一时刻只有一个线程在执行。

在Java程序运行时环境中，JVM需要对两类线程共享的数据进行协调：
1）保存在堆中的实例变量
2）保存在方法区中的类变量

这两类数据是被所有线程共享的。

Java 虚拟机中的同步(Synchronization)基于进入和退出Monitor对象实现，无论是显式同步(有明确的 monitorenter 和 monitorexit 指令,即同步代码块)还是隐式同步都是如此。在 Java 语言中，同步用的最多的地方可能是被 synchronized 修饰的同步方法。同步方法并不是由 monitorenter 和 monitorexit 指令来实现同步的，而是由方法调用指令读取运行时常量池中方法表结构的 ACC_SYNCHRONIZED 标志来隐式实现的，关于这点，稍后详细分析。

同步代码块：monitorenter指令插入到同步代码块的开始位置，monitorexit指令插入到同步代码块的结束位置，JVM需要保证每一个monitorenter都有一个monitorexit与之相对应。任何对象都有一个monitor与之相关联，当且一个monitor被持有之后，他将处于锁定状态。线程执行到monitorenter指令时，将会尝试获取对象所对应的monitor所有权，即尝试获取对象的锁；

在JVM中，对象在内存中的布局分为三块区域：对象头、实例变量和填充数据。

实例变量：存放类的属性数据信息，包括父类的属性信息，如果是数组的实例部分还包括数组的长度，这部分内存按4字节对齐。
填充数据：由于虚拟机要求对象起始地址必须是8字节的整数倍。填充数据不是必须存在的，仅仅是为了字节对齐，这点了解即可。
对象头：Hotspot虚拟机的对象头主要包括两部分数据：Mark Word（标记字段）、Klass Pointer（类型指针）。其中Klass Point是是对象指向它的类元数据的指针，虚拟机通过这个指针来确定这个对象是哪个类的实例，Mark Word用于存储对象自身的运行时数据，它是实现轻量级锁和偏向锁的关键。

Mark Word：用于存储对象自身的运行时数据，如哈希码（HashCode）、GC分代年龄、锁状态标志、线程持有的锁、偏向线程 ID、偏向时间戳等等。Java对象头一般占有两个机器码（在32位虚拟机中，1个机器码等于4字节，也就是32bit），但是如果对象是数组类型，则需要三个机器码，因为JVM虚拟机可以通过Java对象的元数据信息确定Java对象的大小，但是无法从数组的元数据来确认数组的大小，所以用一块来记录数组长度。

监视器（monitor）：可以把它理解为一个同步工具，也可以描述为一种同步机制，它通常被描述为一个对象。与一切皆对象一样，所有的Java对象是天生的Monitor，每一个Java对象都有成为Monitor的潜质，因为在Java的设计中，每一个Java对象自打娘胎里出来就带了一把看不见的锁，它叫做内部锁或者Monitor锁。Monitor 是线程私有的数据结构，每一个线程都有一个可用monitor record列表，同时还有一个全局的可用列表。每一个被锁住的对象都会和一个monitor关联（对象头的MarkWord中的LockWord指向monitor的起始地址），同时monitor中有一个Owner字段存放拥有该锁的线程的唯一标识，表示该锁被这个线程占用。结构和每个组成的含义

Owner:初始时为NULL表示当前没有任何线程拥有该monitor record，当线程成功拥有该锁后保存线程唯一标识，当锁被释放时又设置为NULL；
EntryQ:关联一个系统互斥锁（semaphore），阻塞所有试图锁住monitor record失败的线程。
RcThis:表示blocked或waiting在该monitor record上的所有线程的个数。
Nest:用来实现重入锁的计数。
HashCode:保存从对象头拷贝过来的HashCode值（可能还包含GC age）。
Candidate:用来避免不必要的阻塞或等待线程唤醒，因为每一次只有一个线程能够成功拥有锁，如果每次前一个释放锁的线程唤醒所有正在阻塞或等待的线程，会引起不必要的上下文切换（从阻塞到就绪然后因为竞争锁失败又被阻塞）从而导致性能严重下降。Candidate只有两种可能的值0表示没有需要唤醒的线程1表示要唤醒一个继任线程来竞争锁

四种锁

无锁状态、偏向锁、轻量级锁和重量级锁

随着锁的竞争，锁可以从偏向锁升级到轻量级锁，再升级的重量级锁，但是锁的升级是单向的，也就是说只能从低到高升级，不会出现锁的降级。

重量级锁
偏向锁

在大多数情况下，锁不仅不存在多线程竞争，而且总是由同一线程多次获得，因此为了减少同一线程获取锁(会涉及到一些CAS操作,耗时)的代价而引入偏向锁。偏向锁的核心思想是，如果一个线程获得了锁，那么锁就进入偏向模式，此时Mark Word 的结构也变为偏向锁结构，当这个线程再次请求锁时，无需再做任何同步操作，即获取锁的过程，这样就省去了大量有关锁申请的操作，从而也就提供程序的性能。所以，对于没有锁竞争的场合，偏向锁有很好的优化效果，毕竟极有可能连续多次是同一个线程申请相同的锁。但是对于锁竞争比较激烈的场合，偏向锁就失效了，因为这样场合极有可能每次申请锁的线程都是不相同的，因此这种场合下不应该使用偏向锁，否则会得不偿失，需要注意的是，偏向锁失败后，并不会立即膨胀为重量级锁，而是先升级为轻量级锁。
轻量级锁

倘若偏向锁失败，虚拟机并不会立即升级为重量级锁，它还会尝试使用一种称为轻量级锁的优化手段(1.6之后加入的)，此时Mark Word 的结构也变为轻量级锁的结构。轻量级锁能够提升程序性能的依据是“对绝大部分的锁，在整个同步周期内都不存在竞争”，注意这是经验数据。需要了解的是，轻量级锁所适应的场景是线程交替执行同步块的场合，如果存在同一时间访问同一锁的场合，就会导致轻量级锁膨胀为重量级锁。
自旋锁

轻量级锁失败后，虚拟机为了避免线程真实地在操作系统层面挂起，还会进行一项称为自旋锁的优化手段。这是基于在大多数情况下，线程持有锁的时间都不会太长，如果直接挂起操作系统层面的线程可能会得不偿失，毕竟操作系统实现线程之间的切换时需要从用户态转换到核心态，这个状态之间的转换需要相对比较长的时间，时间成本相对较高，因此自旋锁会假设在不久将来，当前的线程可以获得锁，因此虚拟机会让当前想要获取锁的线程做几个空循环(这也是称为自旋的原因)，一般不会太久，可能是50个循环或100循环，在经过若干次循环后，如果得到锁，就顺利进入临界区。如果还不能获得锁，那就会将线程在操作系统层面挂起，这就是自旋锁的优化方式，这种方式确实也是可以提升效率的。最后没办法也就只能升级为重量级锁了。

锁消除

消除锁是虚拟机另外一种锁的优化，这种优化更彻底，Java虚拟机在JIT编译时(可以简单理解为当某段代码即将第一次被执行时进行编译，又称即时编译)，通过对运行上下文的扫描，去除不可能存在共享资源竞争的锁，通过这种方式消除没有必要的锁，可以节省毫无意义的请求锁时间，如下StringBuffer的append是一个同步方法，但是在add方法中的StringBuffer属于一个局部变量，并且不会被其他线程所使用，因此StringBuffer不可能存在共享资源竞争的情景，JVM会自动将其锁消除。

public class StringBufferRemoveSync {

    public void add(String str1, String str2) {
        //StringBuffer是线程安全,由于sb只会在append方法中使用,不可能被其他线程引用
        //因此sb属于不可能共享的资源,JVM会自动消除内部的锁
        StringBuffer sb = new StringBuffer();
        sb.append(str1).append(str2);
    }

    public static void main(String[] args) {
        StringBufferRemoveSync rmsync = new StringBufferRemoveSync();
        for (int i = 0; i < 10000000; i++) {
            rmsync.add("abc", "123");
        }
    }
}

synchronize的可重入性：

从互斥锁的设计上来说，当一个线程试图操作一个由其他线程持有的对象锁的临界资源时，将会处于阻塞状态，但当一个线程再次请求自己持有对象锁的临界资源时，这种情况属于重入锁，请求将会成功，在java中synchronized是基于原子性的内部锁机制，是可重入的，因此在一个线程调用synchronized方法的同时在其方法体内部调用该对象另一个synchronized方法，也就是说一个线程得到一个对象锁后再次请求该对象锁，是允许的，这就是synchronized的可重入性。

public class AccountingSync implements Runnable{
    static AccountingSync instance=new AccountingSync();
    static int i=0;
    static int j=0;
    @Override
    public void run() {
        for(int j=0;j<1000000;j++){
            //this,当前实例对象锁
            synchronized(this){
                i++;
                increase();//synchronized的可重入性
            }
        }
    }
 
    public synchronized void increase(){
        j++;
    }

    public static void main(String[] args) throws InterruptedException {
        Thread t1=new Thread(instance);
        Thread t2=new Thread(instance);
        t1.start();t2.start();
        t1.join();t2.join();
        System.out.println(i);
    }
}

Tip:

1.synchronized关键字不能继承。也就是说子类重写了父类中用synchronized修饰的方法，子类的方法仍然不是同步的。

2.定义接口方法时，不能使用synchronized关键字。

3.构造方法不能使用synchronized关键字，但是可以使用synchronized代码块。

1.2 volatile

volatile这个关键字可能很多朋友都听说过，或许也都用过。在Java 5之前，它是一个备受争议的关键字，因为在程序中使用它往往会导致出人意料的结果。在Java 5之后，volatile关键字才得以重获生机。

同样可以参考前面的链接进行查看java内存机制。

在理解java内存的基础上,我们来进行后续的学习

下面例子中展示了原子操作和非原子操作

x = 10;         //语句1  直接将数值10赋值给x，也就是说线程执行这个语句的会直接将数值10写入到工作内存中。
y = x;         //语句2 它先要去读取x的值，再将x的值写入工作内存，虽然读取x的值以及 将x的值写入工作内存 这2个操作都是原子性操作，但是合起来就不是原子性操作了。
x++;           //语句3 读取x的值，进行加1操作，写入新的值。非原子操作
x = x + 1;     //语句4 读取x的值，进行加1操作，写入新的值。非原子操作

1.2.1 volatile关键字含义

一旦一个共享变量（类的成员变量、类的静态成员变量）被volatile修饰之后，那么就具备了两层语义：

1）保证了不同线程对这个变量进行操作时的可见性，即一个线程修改了某个变量的值，这新值对其他线程来说是立即可见的。

2）禁止进行指令重排序。

先看一段代码，假如线程1先执行，线程2后执行

//线程1
boolean stop = false;
while(!stop){
    doSomething();
}
  
//线程2
stop = true;

这段代码是很典型的一段代码，很多人在中断线程时可能都会采用这种标记办法。但是事实上，这段代码会完全运行正确么？即一定会将线程中断么？不一定，也许在大多数时候，这个代码能够把线程中断，但是也有可能会导致无法中断线程（虽然这个可能性很小，但是只要一旦发生这种情况就会造成死循环了）。

下面解释一下这段代码为何有可能导致无法中断线程。在前面已经解释过，每个线程在运行过程中都有自己的工作内存，那么线程1在运行的时候，会将stop变量的值拷贝一份放在自己的工作内存当中。

那么当线程2更改了stop变量的值之后，但是还没来得及写入主存当中，线程2转去做其他事情了，那么线程1由于不知道线程2对stop变量的更改，因此还会一直循环下去。

但是用volatile修饰之后就变得不一样了：

第一：使用volatile关键字会强制将修改的值立即写入主存；

第二：使用volatile关键字的话，当线程2进行修改时，会导致线程1的工作内存中缓存变量stop的缓存行无效（反映到硬件层的话，就是CPU的L1或者L2缓存中对应的缓存行无效）；

第三：由于线程1的工作内存中缓存变量stop的缓存行无效，所以线程1再次读取变量stop的值时会去主存读取。

那么在线程2修改stop值时（当然这里包括2个操作，修改线程2工作内存中的值，然后将修改后的值写入内存），会使得线程1的工作内存中缓存变量stop的缓存行无效，然后线程1读取时，发现自己的缓存行无效，它会等待缓存行对应的主存地址被更新之后，然后去对应的主存读取最新的值。那么线程1读取到的就是最新的正确的值。

1.2.2 volatile保证原子性？

看下下面的例子

public class Test {
    public volatile int inc = 0;
      
    public void increase() {
        inc++;
    }
      
    public static void main(String[] args) {
        final Test test = new Test();
        for(int i=0;i<10;i++){
            new Thread(){
                public void run() {
                    for(int j=0;j<1000;j++)
                        test.increase();
                };
            }.start();
        }
          
        while(Thread.activeCount()>1)  //保证前面的线程都执行完
            Thread.yield();
        System.out.println(test.inc);
    }
}
// 每次输出结果不一致。

为什么每次输出结果不一致呢？？？

这里面就有一个误区了，volatile关键字能保证可见性没有错，但是上面的程序错在没能保证原子性。可见性只能保证每次读取的是最新的值，但是volatile没办法保证对变量的操作的原子性。自增操作是不具备原子性的，它包括读取变量的原始值、进行加1操作、写入工作内存。那么就是说自增操作的三个子操作可能会分割开执行，就有可能导致下面这种情况出现：

假如某个时刻变量inc的值为10，

线程1对变量进行自增操作，线程1先读取了变量inc的原始值，然后线程1被阻塞了；

然后线程2对变量进行自增操作，线程2也去读取变量inc的原始值，由于线程1只是对变量inc进行读取操作，而没有对变量进行修改操作，所以不会导致线程2的工作内存中缓存变量inc的缓存行无效，所以线程2会直接去主存读取inc的值，发现inc的值时10，然后进行加1操作，并把11写入工作内存，最后写入主存。

然后线程1接着进行加1操作，由于已经读取了inc的值，注意此时在线程1的工作内存中inc的值仍然为10，所以线程1对inc进行加1操作后inc的值为11，然后将11写入工作内存，最后写入主存。

那么两个线程分别进行了一次自增操作后，inc只增加了1。

要注意，线程1对变量进行读取操作之后，被阻塞了的话，并没有对inc值进行修改。然后虽然volatile能保证线程2对变量inc的值读取是从内存中读取的，但是线程1没有进行修改，所以线程2根本就不会看到修改的值。

那这种情况该怎么办才能保证原子性呢？

synchronized改写，使用方法锁，将inc方法设置为同步方法即可
lock方式，这个在下一章节学习后在进行改写

1.2.3 volatile保证有序性？

在前面提到volatile关键字能禁止指令重排序，所以volatile能在一定程度上保证有序性。

volatile关键字禁止指令重排序有两层意思：

1）当程序执行到volatile变量的读操作或者写操作时，在其前面的操作的更改肯定全部已经进行，且结果已经对后面的操作可见；在其后面的操作肯定还没有进行；

2）在进行指令优化时，不能将在对volatile变量访问的语句放在其后面执行，也不能把volatile变量后面的语句放到其前面执行。

举例说明

//x、y为非volatile变量
//flag为volatile变量
x = 2;        //语句1
y = 0;        //语句2
flag = true;  //语句3
x = 4;         //语句4
y = -1;       //语句5
/*
由于flag变量为volatile变量，那么在进行指令重排序的过程的时候，不会将语句3放到语句1、语句2前面，也不会讲语句3放到语句4、语句5后面。但是要注意语句1和语句2的顺序、语句4和语句5的顺序是不作任何保证的。
*/

1.2.4 volatile的原理和实现机制

摘自《深入理解Java虚拟机》：

“观察加入volatile关键字和没有加入volatile关键字时所生成的汇编代码发现，加入volatile关键字时，会多出一个lock前缀指令”

lock前缀指令实际上相当于一个内存屏障（也成内存栅栏），内存屏障会提供3个功能：

1）它确保指令重排序时不会把其后面的指令排到内存屏障之前的位置，也不会把前面的指令排到内存屏障的后面；即在执行到内存屏障这句指令时，在它前面的操作已经全部完成；

2）它会强制将对缓存的修改操作立即写入主存；

3）如果是写操作，它会导致其他CPU中对应的缓存行无效。

1.2.5 volatile关键字的场景

synchronized关键字是防止多个线程同时执行一段代码，那么就会很影响程序执行效率，而volatile关键字在某些情况下性能要优于synchronized，但是要注意volatile关键字是无法替代synchronized关键字的，因为volatile关键字无法保证操作的原子性。通常来说，使用volatile必须具备以下2个条件：

1）对变量的写操作不依赖于当前值

2）该变量没有包含在具有其他变量的不变式中

实际上，这些条件表明，可以被写入 volatile 变量的这些有效值独立于任何程序的状态，包括变量的当前状态。

事实上，我的理解就是上面的2个条件需要保证操作是原子性操作，才能保证使用volatile关键字的程序在并发时能够正确执行。

1.3 final

final修饰的常量会写进常量池，作为共享变量，而且无法修改指定的值，所以线程安全，具体可以看我之前总结的另外一篇 [java常见final类](文档：java常见final类.md
链接：http://note.youdao.com/noteshare?id=61c46e0f232d0e208ea5ddac4656b73e&sub=274C6869F867425ABCD570CA01E37392)。

2、Java的Lock框架

因为sychronized粒度有些大，在处理实际问题时存在诸多局限性，比如响应中断等。而Lock提供了更广泛的锁操作，它能以更优雅的方式处理线程同步问题。

下面我们来了解以下java中Lock框架部分。

2、java CAS

搬运资料：https://www.cnblogs.com/zhuawang/p/4196904.html

2.1 什么是CAS

比较和交换（Conmpare And Swap）是用于实现多线程同步的原子指令。它将内存位置的内容与给定值进行比较，只有在相同的情况下，将该内存位置的内容修改为新的给定值。这是作为单个原子操作完成的。原子性保证新值基于最新信息计算; 如果该值在同一时间被另一个线程更新，则写入将失败。操作结果必须说明是否进行替换; 这可以通过一个简单的布尔响应（这个变体通常称为比较和设置），或通过返回从内存位置读取的值来完成。 JAVA1.5开始引入了CAS，主要代码都放在JUC的atomic包下。是同步锁的一种乐观锁。

CAS 操作包含三个操作数 —— 内存位置（V）、预期原值（A）和新值(B)。”我认为位置 V 应该包含值 A；如果包含该值，则将 B 放到这个位置；否则，不要更改该位置，只告诉我这个位置现在的值即可。“

类似于 CAS 的指令允许算法执行读-修改-写操作，而无需害怕其他线程同时修改变量，因为如果其他线程修改变量，那么 CAS 会检测它（并失败），算法可以对该操作重新计算。

非阻塞算法（nonblocking algorithms）

一个线程的失败或者挂起不应该影响其他线程的失败或挂起的算法。

现代的CPU提供了特殊的指令，可以自动更新共享数据，而且能够检测到其他线程的干扰，而 compareAndSet() 就用这些代替了锁定。

拿出AtomicInteger来研究在没有锁的情况下是如何做到数据正确性的。

private volatile int value;	// 在没有锁的机制下可能需要借助volatile关键字保证数据的可见性

/** 自增
采用了CAS操作，每次从内存中读取数据然后将此数据和+1后的结果进行CAS操作，如果成功就返回结果，否则重试直到成功为止。compareAndSet利用JNI来完成CPU指令的操作整体的过程就是这样子的，利用CPU的CAS指令，同时借助JNI来完成Java的非阻塞算法。其它原子操作都是利用类似的特性完成的。
*/
public final int incrementAndGet() {
    for (;;) {
        int current = get();
        int next = current + 1;
        if (compareAndSet(current, next))
            return next;
    }
}

public final boolean compareAndSet(int expect, int update) {   
    return unsafe.compareAndSwapInt(this, valueOffset, expect, update);
}

那么问题就来了，成功过程中需要2个步骤：比较this == expect，替换this = update，compareAndSwapInt如何这两个步骤的原子性呢？

2.2 CAS原理

更底层的原理其实不需要特别了解，主要就是CAS底层直接调用的CPU命令保证了原子性

CAS通过调用JNI的代码实现的。JNI:Java Native Interface为JAVA本地调用，允许java调用其他语言。

而compareAndSwapInt就是借助C来调用CPU底层指令实现的。

下面从分析比较常用的CPU（intel x86）来解释CAS的实现原理。

下面是sun.misc.Unsafe类的compareAndSwapInt()方法的源代码：

public final native boolean compareAndSwapInt(Object o, long offset,
                                              int expected,
                                              int x);

可以看到这是个本地方法调用。这个本地方法在openjdk中依次调用的c++代码为：unsafe.cpp，atomic.cpp和atomicwindowsx86.inline.hpp。这个本地方法的最终实现在openjdk的如下位置：openjdk-7-fcs-src-b147-27jun2011\openjdk\hotspot\src\oscpu\windowsx86\vm\ atomicwindowsx86.inline.hpp（对应于windows操作系统，X86处理器）。下面是对应于intel x86处理器的源代码的片段：

// Adding a lock prefix to an instruction on MP machine
// VC++ doesn't like the lock prefix to be on a single line
// so we can't insert a label after the lock prefix.
// By emitting a lock prefix, we can define a label after it.
#define LOCK_IF_MP(mp) __asm cmp mp, 0  \
                       __asm je L0      \
                       __asm _emit 0xF0 \
                       __asm L0:

inline jint     Atomic::cmpxchg    (jint     exchange_value, volatile jint*     dest, jint     compare_value) {
  // alternative for InterlockedCompareExchange
  int mp = os::is_MP();
  __asm {
    mov edx, dest
    mov ecx, exchange_value
    mov eax, compare_value
    LOCK_IF_MP(mp)
    cmpxchg dword ptr [edx], ecx
  }
}

如上面源代码所示，程序会根据当前处理器的类型来决定是否为cmpxchg指令添加lock前缀。如果程序是在多处理器上运行，就为cmpxchg指令加上lock前缀（lock cmpxchg）。反之，如果程序是在单处理器上运行，就省略lock前缀（单处理器自身会维护单处理器内的顺序一致性，不需要lock前缀提供的内存屏障效果）。

intel的手册对lock前缀的说明如下：

确保对内存的读-改-写操作原子执行。在Pentium及Pentium之前的处理器中，带有lock前缀的指令在执行期间会锁住总线，使得其他处理器暂时无法通过总线访问内存。很显然，这会带来昂贵的开销。从Pentium 4，Intel Xeon及P6处理器开始，intel在原有总线锁的基础上做了一个很有意义的优化：如果要访问的内存区域（area of memory）在lock前缀指令执行期间已经在处理器内部的缓存中被锁定（即包含该内存区域的缓存行当前处于独占或以修改状态），并且该内存区域被完全包含在单个缓存行（cache line）中，那么处理器将直接执行该指令。由于在指令执行期间该缓存行会一直被锁定，其它处理器无法读/写该指令要访问的内存区域，因此能保证指令执行的原子性。这个操作过程叫做缓存锁定（cache locking），缓存锁定将大大降低lock前缀指令的执行开销，但是当多处理器之间的竞争程度很高或者指令访问的内存地址未对齐时，仍然会锁住总线。
禁止该指令与之前和之后的读和写指令重排序。
把写缓冲区中的所有数据刷新到内存中。

2.3 CAS的缺点

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

ABA问题
循环时间长开销大
只能保证一个共享变量的原子操作

2.3.1 ABA问题

因为CAS需要在操作值的时候检查下值有没有发生变化，如果没有发生变化则更新，但是如果一个值原来是A，变成了B，又变成了A，那么使用CAS进行检查时会发现它的值没有发生变化，但是实际上却变化了。ABA问题的解决思路就是使用版本号。在变量前面追加上版本号，每次变量更新的时候把版本号加一，那么A－B－A 就会变成1A-2B－3A。

从Java1.5开始JDK的atomic包里提供了一个类AtomicStampedReference来解决ABA问题。这个类的compareAndSet方法作用是首先检查当前引用是否等于预期引用，并且当前标志是否等于预期标志，如果全部相等，则以原子方式将该引用和该标志的值设置为给定的更新值。

https://hesey.wang/2011/09/resolve-aba-by-atomicstampedreference.html

2.3.2 循环时间长开销大

自旋CAS如果长时间不成功，会给CPU带来非常大的执行开销。如果JVM能支持处理器提供的pause指令那么效率会有一定的提升，pause指令有两个作用，第一它可以延迟流水线执行指令（de-pipeline）,使CPU不会消耗过多的执行资源，延迟的时间取决于具体实现的版本，在一些处理器上延迟时间是零。第二它可以避免在退出循环的时候因内存顺序冲突（memory order violation）而引起CPU流水线被清空（CPU pipeline flush），从而提高CPU的执行效率。

2.3.3 只能保证一个共享变量的原子操作

当对一个共享变量执行操作时，我们可以使用循环CAS的方式来保证原子操作，但是对多个共享变量操作时，循环CAS就无法保证操作的原子性，这个时候就可以用锁，或者有一个取巧的办法，就是把多个共享变量合并成一个共享变量来操作。比如有两个共享变量i＝2,j=a，合并一下ij=2a，然后用CAS来操作ij。从Java1.5开始JDK提供了AtomicReference类来保证引用对象之间的原子性，你可以把多个变量放在一个对象里来进行CAS操作。

2.4 concurrent包的实现

由于java的CAS同时具有 volatile 读和volatile写的内存语义，因此Java线程之间的通信现在有了下面四种方式：

A线程写volatile变量，随后B线程读这个volatile变量。
A线程写volatile变量，随后B线程用CAS更新这个volatile变量。
A线程用CAS更新一个volatile变量，随后B线程用CAS更新这个volatile变量。
A线程用CAS更新一个volatile变量，随后B线程读这个volatile变量。

Java的CAS会使用现代处理器上提供的高效机器级别原子指令，这些原子指令以原子方式对内存执行读-改-写操作，这是在多处理器中实现同步的关键（从本质上来说，能够支持原子性读-改-写指令的计算机器，是顺序计算图灵机的异步等价机器，因此任何现代的多处理器都会去支持某种能对内存执行原子性读-改-写操作的原子指令）。同时，volatile变量的读/写和CAS可以实现线程之间的通信。把这些特性整合在一起，就形成了整个concurrent包得以实现的基石。如果我们仔细分析concurrent包的源代码实现，会发现一个通用化的实现模式：

首先，声明共享变量为volatile；
然后，使用CAS的原子条件更新来实现线程之间的同步；
同时，配合以volatile的读/写和CAS所具有的volatile读和写的内存语义来实现线程之间的通信。

AQS，非阻塞数据结构和原子变量类（java.util.concurrent.atomic包中的类），这些concurrent包中的基础类都是使用这种模式来实现的，而concurrent包中的高层类又是依赖于这些基础类来实现的。从整体来看，concurrent包的实现示意图如下：

java多线程基础学习1

java多线程基础学习1

pre 准备知识

什么是线程

线程有什么特点

什么是多线程

POSIX线程

线程的状态和生命周期

并发编程的问题

1、线程涉及的关键字

1.1 synchronized

1.1.1 方法锁

修饰方法

1.1.2 对象锁

修饰代码块,锁实例对象

1.1.3 类锁

修饰静态方法

修饰代码块,锁类对象

1.1.4 synchronized的底层原理

1.2 volatile

1.2.1 volatile关键字含义

1.2.2 volatile保证原子性？

1.2.3 volatile保证有序性？

1.2.4 volatile的原理和实现机制

1.2.5 volatile关键字的场景

1.3 final

2、Java的Lock框架

2、java CAS

2.1 什么是CAS

2.2 CAS原理

2.3 CAS的缺点

2.3.1 ABA问题

2.3.2 循环时间长开销大

2.3.3 只能保证一个共享变量的原子操作

2.4 concurrent包的实现