Java内存模型与线程

Java内存模型

Java虚拟机规范中试图定义一种Java内存模型(Java Memory Model， JMM)来屏蔽掉各种硬件和操作系统的内存访问差异，以实现让Java程序在各种平台下都能达到一致的内存访问效果。在JDK1.5以后，Java内存模型就已经成熟和完善起来了。

主内存与工作内存

Java内存模型的主要目标是定义程序中各个变量的访问规则，即在虚拟机中将变量存储到内存和从内存中取出变量这样的底层细节，此处的变量包括了实例字段、静态字段和构成数组对象的元素，但不包括局部变量与方法参数，因为后者是线程私有的，不会被共享。为了获得较好的执行性能，Java内存模型并没有限制执行引擎使用处理器的特定寄存器或缓存来和主内存进行交互，也没有限制即时编译器进行调整代码执行顺序这类优化措施。

Java内存模型规定了所有的变量都存储在主内存(虚拟机内存的一部分)中，每条线程还有自己的工作内存，线程的工作内存中保存了被该线程使用到的变量的主内存副本拷贝，线程对变量的所有操作都必须在工作内存中进行，而不能直接读写主内存中的变量。不同的线程之间也无法直接访问对方工作内存中的变量，线程间变量值的传递均需要通过主内存来完成。

内存间交互操作

JMM中定义了以下八种操作完成内存交互，虚拟机实现时必须保证下面提及的每一种操作都是原子的、不可再分的：

• lock(锁定)：作用于主内存的变量，他把一个变量标识为一条线程独占的状态；
• unlock(解锁)：作用于主内存的变量，他把一个处于锁定状态的变量释放出来，释放后的变量才可以被其他线程锁定；
• read(读取)：作用于主内存的变量，他把一个变量的值从主内存传输到线程的工作内存中，以便随后的load动作使用；
• load(载入)：作用于工作内存的变量，他把read操作从主内存中得到的变量值放入工作内存的变量副本中；
• use(使用)：作用于工作内存的变量，他把工作内存中一个变量的值传递给执行引擎，每当虚拟机遇到一个需要使用到变量的值的字节码指令时将会执行这个操作；
• assign(赋值)：作用于工作内存的变量，他把一个从执行引擎接收到的值赋给工作内存的变量，每当虚拟机遇到一个给变量赋值的字节码指令时执行这个操作；
• store(存储)：作用于工作内存的变量，他把工作内存中一个变量的值传送到主内存中，以便随后的write操作使用；
• write(写入)：作用于主内存的变，他把store操作从工作内存中得到的变量的值放入主内存的变量中。

JMM规定了在执行上述八种操作时必须满足如下规则：

• 不允许read和load、store和write操作之一单独出现，即不允许一个变量从主内存读取了但工作内存不接受，或者从工作内存发起回写了但主内存不接受的情况出现；
• 不允许一个线程丢弃它的最近的assign操作，即变量在工作内存中改变了之后必须把该变化同步回主内存；
• 不允许一个线程无原因的(没有发生过任何assign操作)把数据从线程的工作内存同步回主内存中；
• 一个新的变量只能在主内存中诞生，不允许在工作内存中直接使用一个未被初始化的变量，换句话说，就是对一个变量实施use、store操作之前，必须先执行过了assign和load操作；
• 一个变量在同一个时刻只允许一条线程对其进行lock操作，但lock操作可以被同一条线程重复执行多次，多次执行lock后，只有执行相同次数的unlock操作，变量才会被解锁；
• 如果一个变量执行lock操作，那会清空工作内存中此变量的值，在执行引擎使用这个变量前，需要重新执行load或assign操作初始化变量的值；
• 如果一个变量事先没有被lock操作锁定，那就不允许对他进行unlock操作，也不允许去unlock一个被其他线程锁定住的变量；
• 对一个变量执行unlock操作之前，必须先把此变量同步回主内存中。

对于volatile型变量的特殊规则

当一个变量定义为volatile后，它具备两种特性：一是保证此变量对所有线程的可见性，这里的可见性是指当一条线程修改了这个变量的值，新值对于其他线程是可以立刻得知的；二是禁止指令重排序优化。

public class VolatileTest {
    public static volatile int race = 0;

    public static void increase(){
        race++;
    }

    public static final int THREAD_COUNT = 20;

    public static void main(String[] args) {
        Thread[] threads = new Thread[THREAD_COUNT];
        for (int i = 0; i < THREAD_COUNT; i++){
            threads[i] = new Thread(new Runnable() {
                @Override
                public void run() {
                    for(int i = 0; i < 10000; i++){
                        increase();
                    }
                }
            });

            threads[i].start();
        }

        while (Thread.activeCount() > 2)
            Thread.yield();


        System.out.println(race);
    }
}

上述代码中，输出结果一直小于200000，可见volatile是并发不安全的，在不符合以下两条运算规则的场景中，仍然要通过加锁来保证原子性：

• 运算结果并不依赖变量的当前值，或者能够确保只有单一的线程修改变量的值；
• 变量不需要与其他的状态变量共同参与不变约束。

public class Singleton {

    private volatile static Singleton instance ;

    private Singleton(){}

    public static Singleton getInstance(){
        if(instance == null){
            synchronized (Singleton.class){
                if(instance == null){
                    instance = new Singleton();
                }
            }
        }
        return instance;
    }

}

上面是一个单例的例子，在执行时，会多执行一个内存屏障操作，重排序时不能把后面的指令重排序到内存屏障之前的位置。由此保证volatile禁止指令重排序的效果。

volatile开销要比锁低，选择二者的依据仅仅是看volatile的语义能否满足使用场景的需求。

假设T表示线程，V和W代表两个volatile变量，那么需要满足以下规则：

• 只有当T对变量V执行的前一个动作是load的时候，线程T才能对V执行use动作；只有当T对变量执行的后一个动作是use时，才能对V执行load动作。这条规则要求在工作内存中，每次使用V前都必须先从主内存刷新最新的值，用于保证能看见其他线程对变量V所做的修改后的值；
• 只有当T对V执行的前一个动作是assign的时候，T才能对变量执行store动作；只有当T对V执行的后一个动作是store时，才能对V执行assign操作。这条规则要求在工作内存中，每次修改V后必须立刻同步回主内存中，用于保证其他线程可以看到自己对V所做的修改。
• 假定动作A是T对V实施的use或assign操作，F是和A相关联的load或store操作，P是和F相对于的read或write操作；类似的，B是T对W的use或assign操作，G是load或store操作，Q是read或write操作，如果A先于B，那么P先于Q。这条规则要求volatile修饰的变量不会被指令重排序优化，保证代码的执行顺序与程序的顺序相同。

对于long和double型变量的特殊规则

对于64位数据类型long和double，定义了一条相对宽松的规定：允许虚拟机将没有被volatile修饰的64位数据的读写操作划分为两次32位的操作来进行，即允许虚拟机实现可以不保证64位数据类型的load、store、read和write这四个操作的原子性，这就是long和double的非原子协定。

如果有多个线程共享一个未被声明为volatile的long和double变量，同时对他们进行读取和修改操作，那么某些线程会读到一个既非原值也不是其他线程修改值的半个变量的数据。不过，这种情况在目前的虚拟机中不会出现。

原子性、可见性与有序性

原子性(Atomicity)：

由Java内存模型来直接保证的原子性变量操作包括read、load、assign、use、store和write，基本类型的读写访问是原子性的。如果应用场景中需要一个更大范围的原子性保证，Java内存模型还提供了lock和unlock操作来满足。虚拟机把lock和unlock操作开放给用户，但提供了更高层次的字节码指令monitorenter和monitorexit来隐式的使用这两个操作。这两个字节码反映到代码就是synchronized关键字。

可见性(Visibility)

可见性是指当一个线程修改了共享变量的值，其他线程能够立即得知这个修改。Java内存模型是通过在变量修改后将新值同步回主存，在变量读取前从主内存刷新变量值这种依赖主内存作为传递媒介的方式来实现可见性的，普通变量和volatile都是如此，但volatile保证新值能立即同步到主内存，以及每次使用前从主内存刷新，保证了多线程操作时变量的可见性，普通变量则不能保证这一点。

除此之外，synchronized和final关键字也能保证可见性。synchronized对一个变量执行unlock操作前，必须先把此变量同步回主内存中，而final修饰的字段在构造器中一旦初始化完成，并且构造器没有吧this引用传递出去，那在其他线程中就能看见final字段的值。

有序性(Ordering)

有序性可以总结为一句话：如果在本线程内观察，所有的操作都是有序的；如果在一个线程观察另一个线程，所有的操作都是无序的。前半句指线程内表现为串行的语义，后半句指指令重排序和工作内存与主内存同步延迟。

volatile通过禁止指令重排序保证有序性，synchronized通过规则一个变量在同一个时刻只允许一条线程对其进行lock操作保证有序性。

先行发生(happens-before)原则

先行发生原则是判断数据是否存在竞争、线程是否安全的主要依据，依靠这个原则，我们可以通过几条规则解决并发环境下两个操作之间是否可能存在冲突的所有问题。

下面是一些天然的先行发生关系，这种情况下无需任何同步操作就可以使用：

• 程序次序规则(Program Order Rule)：在一个线程内，按照程序代码顺序，书写在前面的操作先行发生于书写在后面的操作，准确的说，应该是控制流顺序而不是代码顺序，因为要考虑分支、循环等结构；
• 管程锁定规则(Monitor Lock Rule)：一个unlock操作先行发生于后面对同一个锁的lock操作；
• volatile变量规则(Volatile Variable Rule)：对一个volatile变量的写操作先行发生于后面对这个变量的读操作；
• 线程启动规则(Thread Start Rule)：Thread对象的start方法先行发生于此线程的每一个动作；
• 线程终止规则(Thread Termination Rule)：线程中的所有操作都先行发生于对此线程的终止检测，可以通过Thread.join()方法结束、Thread.isAlive()的返回值等手段检测到线程已经终止执行；
• 线程中断规则(Thread Interruption Rule)：对线程interrupt()方法的调用先行发生于被中断线程的代码检测到中断事件的发生；
• 对象终结规则(Finalizer Rule)：一个对象的初始化完成先行发生于它的finalize()方法的开始；
• 传递性(Transitivity)：如果操作A先于操作B，B先于C，那么A先于C。

Java与线程

线程的实现

线程是比进程更轻量级的调度执行单位，线程的引入，可以把一个进程的资源分配和执行调度分开，各个线程既可以共享进程资源，又可以独立调度(线程是CPU调度的基本单位)。

Java语言提供了在不同硬件和操作系统平台下对线程操作的统一处理，每个已经执行start()且还未结束的java.lang.Thread类的实例就代表了一个线程。Thread类所有关键方法都声明是Native的，一个Native方法往往意味着这个方法没有使用或无法使用平台无关的手段来实现。

实现线程主要有三种方式：使用内核线程实现、使用用户线程和使用用户线程加轻量级进程混合实现。

使用内核线程实现

内核线程(Kernel-Level Thread， KLT)就是直接由操作系统内核(Kernel)支持的线程，这种线程由内核来完成线程切换，内核通过操纵调度器(Scheduler)对线程进行调度，并负责将线程的任务映射到各个处理器上。每个内核线程可以视为内核的一个分身，这样操作系统旧有能力处理多件事情，支持多线程的内核就叫做多线程内核。

程序一般不会直接去使用线程，而是去使用内核线程的一种高级接口——轻量级进程(Light Weight Process， LWP)，轻量级进程就是我们通常所说的线程，由于每个轻量级进程都有一个内核线程支持，因此只有先支持内核线程，才有轻量级进程。这种关系称为一对一的线程模型。

由于内核线程的支持，每个轻量级进程都成为一个独立的调度单元，即使有一个轻量级进程在系统调用中阻塞了，也不会影响整个进程继续工作，但轻量级进程有他的局限性：首先，由于是基于内核线程实现的，所以各种线程操作，如创建、析构及同步，都需要进行系统调用。而系统调用的代价较高，需要在用户态和内核态中来回切换。其次，每个轻量级进程都需要有一个内核线程的支持，因此轻量级进程要消耗一定的内核资源(如内核线程的栈空间)，因此一个系统支持轻量级进程的数量是有限的。

使用用户线程实现

用户线程指的是完全建立在用户空间的线程库上，系统内核不能感知线程存在的实现。用户线程的建立、同步、销毁和调度完全在用户态中完成，不需要内核的帮助。如果程序实现得当，这种线程不需要切换到内核态，因此操作可以是非常快速且低消耗的，也可以支持规模更大的线程数量，部分高性能数据库中的多线程就是由用户线程实现的，这种关系称为一对多的线程模型。

使用用户线程的优势在于不需要系统内核支援，所有的线程操作都需要用户程序自己处理，线程的创建、切换、调度都是需要考虑的问题，而且，由于操作系统只把处理器资源分配到进程，诸如阻塞如何处理、多处理器系统中如何将线程映射到其他处理器上这类问题解决起来会异常困难，甚至不可能完成。因而使用用户线程实现的程序一般都比较复杂，现在使用用户线程的程序越来越少，Java也放弃它了；

使用用户线程加轻量级进程混合实现

在这种混合实现下，既存在用户线程，也存在轻量级进程，操作系统提供支持的轻量级进程作为用户线程和内核线程的桥梁，这样可以使用内核提供的线程调度功能及处理器映射，并且用户线程的系统调用要通过轻量级进程来完成，大大降低了整个进程被完全阻塞的风险。

Java线程的实现

JDK1.2之前，Java线程是基于“绿色线程”的用户线程实现的，而在1.2中，线程模型替换为基于操作系统原生线程模型来实现。因此，Java虚拟机线程是由操作系统决定的。对Sun JDK来说，Windows和Linux版是使用一对一的线程模型实现的，一条Java线程映射到一条轻量级进程中。在Solaris中，由于操作系统的线程特性可以同时支持一对一和多对多的线程模型，因此Solaris版JDK也提供了两个参数：-XX：+UseLWPSynchronization(多对多，默认值)和-XX：+UseBoundThreads(一对一)来指定使用哪种线程模型。

Java线程调度

线程调度是指系统为线程分配处理器使用权的过程，主要调度方式有两种：协同式线程调度(Cooperative Threads-Scheduling)和抢占式线程调度(P热尔没跑题学Threads-Scheduling)。

• 协同式多线程系统里线程的执行时间由线程本身控制，线程把自己的工作执行完之后，要主动通知系统切换到另一个线程上。好处是实现简单，没有线程同步的问题。坏处是线程执行时间不可控制，如果一个线程有问题，一直不告诉系统进行线程切换，那么程序就会一直阻塞在那里；
• 抢占式调度的多线程系统里每个线程将由系统来分配执行时间，线程的切换不由线程本身决定，线程的执行是系统可控的，也不会出现一个线程导致进程阻塞的问题，Java使用抢占式调度。

Java语言设置了十个线程优先级，而Windows系统只有七种优先级，只能有几个优先级对应重合。