Java内存模型是用来屏蔽掉各种硬件和操作系统的内存访问差异，以实现让Java程序在各种平台下都能达到一致的内存访问效果。
Java内存模型的主要目标是定义程序中的各个变量的访问规则，即在虚拟机中将变量存储到内存和从内存中取出变量这样的底层细节。这里的变量指的是实例字段、静态字段和构成数组对象的元素，但不包括局部变量与方法参数，因为后者是线程私有的，不会被共享。
Java内存模型规定了所有的变量都存储在主内存中，除此之外，每条线程还有自己的工作内存，线程的工作内存中保存了被该线程使用到的变量的主内存的副本拷贝(拷贝的一般是对象的引用，或者是对象的在线程中被访问到的字段)，线程对变量的所有操作都必须在工作内存中进行，而不能直接读写主内存中的变量。不同线程间也无法直接访问对方工作内存中的变量，线程间变量值的传递均需要通过主内存来完成。
主内存主要对应于Java堆中的对象实例数据部分，而工作内存则对应于虚拟机栈中的部分区域。从更低层次上来说，主内存就直接对应于物理硬件的内存，而为了获得更好的运行速度，虚拟机(甚至是硬件系统本身的优化措施)可能会让工作内存优先存储于寄存器和高速缓存中，因为程序运行时主要访问读写的是工作内存。
这里的讨论的问题是一个变量如何从主内存拷贝到工作内存中、如何从工作内存同步回主内存的实现细节，在Java内存模型中定义了8种原子操作(对于long和double类型的变量允许有例外)来实现：
- lock(锁定)：作用于主内存的变量，它把一个变量标识为一条线程独占的状态。
- unlock(解锁)：作用于主内存的变量，它把一个处于锁定状态的变量释放出来，释放后的变量才可以被其他线程锁定。
- read(读取)：作用于主内存的变量，它把一个变量的值从主内存传输到线程的工作内存中，以便随后的load动作的使用。
- load(载入)：作用于工作内存的变量，它把read操作从主内存中得到的变量值放入工作内存的变量副本中。
- use(使用)：作用于工作内存的变量，它把工作内存中一个变量的值传递给执行引擎，每当虚拟机遇到一个需要使用到变量的值的字节码指令时就会执行这个操作。
- assign(赋值)：作用于工作内存的变量，它把一个从执行引擎接收到的值赋给工作内存的变量，每当虚拟机遇到一个给变量赋值的字节码指令时执行这个操作。
- store(存储)：作用于工作内存的变量，它把工作内存中一个变量的值传送到主内存中，以便随后的write操作使用。
- write(写入)：作用于主内存的变量，它把store操作从工作内存中得到的变量值放入主内存的变量中。
如果要把一个变量从主内存复制到工作内存，那么就要顺序地执行read和load操作，如果要把变量从工作内存同步回主内存，就要顺序执行store和write操作。注意Java内存模型只要求两个操作必须要按顺序执行，而没有保证是连续执行。除此之外，Java内存模型还规定了在执行上述8中操作时必须满足如下规则：
- 不允许read和load、store和write操作之一单独出现，即不允许一个变量从主内存读取了但工作内存不接受，或者从工作内存发起回写了但主内存不接受的情况。
- 不允许一个线程丢弃他的最近的assign操作，即变量在工作内存中改变了之后，必须把该变化同步回主内存。
- 不允许一个线程无原因的(没有发生过任何assign操作)把数据从线程的工作内存同步回主内存。
- 一个新的变量只能在主内存中诞生，不允许在工作内存中直接使用一个未被初始化(load和assign)的变量，换句话说，就是对一个变量实施use、store操作前，必须先执行过assign或load操作。
- 一个变量在同一时刻只允许一条线程对其进行lock操作，但lock操作可以被同一条线程重复执行多次，多次执行lock后，只有执行相同次数的unlock操作，变量才会被解锁
- 如果对一个变量执行lock操作，那将会清空工作内存中此变量的值，在执行引擎使用这个变量前，需要重新执行load或assign操作初始化变量的值。
- 如果一个变量事先没有被lock锁定，那就不允许对它执行unlock操作，也不允许去unlock一个被其他线程锁定的变量。
- 对一个变量执行unlock操作之前，必须先把此变量同步回主内存中(执行store、write操作)因此加锁可以保证原子性
volatile是Java虚拟机提供的最轻量级的同步机制。
当一个变量被定义为volatile之后，它将具备两种特性，第一是保证此变量对所有线程的可见性，这里的可见性是指当一条线程修改了这个变量的值，新值对于其他线程来说是可以立即得知的。
volatile变量在各个线程中是一致的，但是由于Java里面的运算并非是原子操作，导致volatile变量的运算在并发下一样是不安全的。
由于volatile变量只能保证可见性，在不符合一下两条规则的运算场景中，我们仍然要通过加锁(使用synchronized或java.util.concurrent中的原子类)来保证原子性。
- 运算结果并不依赖当前变量的值，或者能够保证只有单一的线程修改变量的值
- 变量不需要与其他的状态变量共同参与不变约束。
对于第二点可能有点抽象，举例说明一下：
volatile是弱同步级别，只是强制Thread每次读取变量都要去本地Main Memory里面刷新变量值而已“变量不需要与其他的状态变量共同参与不变约束”应该是指变量不会跟其他变量产生依赖关系，举个例子：
int A;如果是volatile的，那么Thread-A和Thread-B每次去读A的值都必须去Main Memory里，所以会是一致的
但如果A的定义是A=1+X；那么Thread-A和Thread-B每次去读A的值虽然都是去Main Memory里，但不能保证X的值是一致而且最新的.
使用volatile变量的第二个语义是禁止指令重排序优化(在jdk1.5中才被完全修复)，普通的变量仅仅会保证在该方法的执行过程中所有依赖赋值结果的地方都能获取到正确的结果，而不能保证变量赋值操作的顺序与程序代码执行顺序的一致性，这种一致性是怎么保证的呢，是通过在赋值后的代码中加一个lock addl $0x0，(%esp)操作，这个操作相当于一个内存屏障，指令重排序时不能把后面的指令重排序到内存屏障之前的位置，只有一个CPU访问内存时，并不需要内存屏障：但如果有两个或更多的CPU访问同一个块内存，且其中有一个正在观测另一个，就需要内存屏障来保证一致性了。这句指令的addl $0x0,(%esp)(把ESP寄存器的值加0)显然是一个空操作(采用这个空操作而不是空操作指令nop是因为IA32手册规定lock前缀不允许配合nop指令使用)，lock的作用是使得本CPU的Cache写入了内存，该写入动作也会让其他CPU或别的内核无效化其Cache，这种操作相当于对Cache中的变量做了一次store和write操作。所以通过这样一个空操作，可以让前面的volatile变量的修改对其他CPU立即可见。
那为何说它禁止指令重排序呢？从硬件架构上讲，指令重排序是指CPU采用了允许将多条指令不按程序规定的顺序分开发送给各相应电路单元处理。但并不是说指令任意重排，CPU需要能正确处理指令依赖情况以保证程序能得出正确的执行结果。
volatile变量读操作的性能消耗与普通变量几乎没有什么差别，但是写操作则可能会慢一些，因为它需要在本地代码中插入内存屏障指令来保证处理器不发生乱序执行。我们在volatile与锁之中选择的唯一依据仅仅是volatile的语义能否满足使用场景的需求。
Java内存模型中对volatile变量定义的特殊规则，假设T表示一个线程，V和W分别表示两个volatile变量：
- 在工作内存中，每次使用V前都必须先从主内存刷新最新的值，用于保证能看见其他线程对变量V所做的修改后的值。
- 在工作内存中，每次修改V后，都必须立即同步回主内存，用于保证其他线程可以看到自己对变量V所做的修改。
- volatile修饰的变量不会被指令冲排序优化，保证代码的执行顺序与程序的顺序相同。
允许虚拟机将没有被volatile修饰的64位数据的读写划分为两次32位的操作来进行，即允许虚拟机实现选择可以不保证64位数据类型的load、store、read和write这四个操作的原子性，这点就是所谓的long和double的非原子性协定。
**原子性：**由Java内存模型来直接保证的原子性变量操作包括read、load、assign、use、store、write，除此之外，Java内存模型还提供了lock和unlock(未直接开放)来满足这种需求，可以采用更高层次的字节码指令monitorenter和monitorexit来隐式的使用这两个操作，这两个字节码指令反映到Java代码中就是同步块synchronized关键字。
**可见性：**可见性是指当一个线程修改了共享变量的值，其他线程能够立即得知这个修改。Java内存模型是通过在变量修改后将新值立即同步回主内存，在变量读取前从主内存刷新变量值这种依赖主内存作为传递媒介的方式来实现可见性的。除了volatile可以保证多线程操作时变量的可见性，synchronized和final也可以实现可见性。
同步块的可见性是由"对一个变量执行unlock操作前，必须先把此变量同步回主内存中”来实现的。
**final关键字的可见性是指：**被final修饰的字段在构造器中一旦初始化完成，并且构造器没有把this的引用传递出去(this引用逃逸是一件很危险的事情，其他线程有可能通过这个引用访问到初始化了一半的对象)，那在其他线程中就能看到final字段的值。
**有序性：**如果在本线程内观察，所有操作都是有序的；如果在一个线程中观察另一个线程，所有的操作都是无序的。前半句指“线程内表现为串行的语义”，后半句是指是指"指令重排序现象"和"工作内存与主内存同步延迟"现象。
在Java语言中提供了volatile和synchronized两个关键字来保证线程之间操作的有序性，volatile关键字本身就包含了禁止指令重排序的语义，而synchronized则是由"一个变量在同一个时刻只允许一条线程对其进行lock操作"这条规则获得的，这条规则决定持有同一个锁的两个同步块只能串行的进入。
这个原则非常重要，它是判断数据是否存在竞争、线程是否安全的主要依据，依靠这个原则，我们可以通过几条规则一揽子的解决并发环境下两个操作之间是否可能存在冲突的所有问题。
Java内存模型中一些天然的先行发生关系：
- **程序次序规则：**在一个线程内，按照程序代码顺序，书写在前面的操作先行发生于书写在后面的操作。准确的说，应该是控制流顺序而不是代码顺序，因为还要考虑分支、循环等结构。
- **管程锁定规则：**一个unlock操作先行发生于后面对同一个锁的lock操作
- **volatile变量规则：**对一个volatile变量的写操作先行发生于后面对这个变量的读操作
- **线程启动规则：**Thread对象的start()方法先行发生于此线程的每一个动作。
- **线程终止规则：**线程中的所有操作都先行发生于对此线程的终止检测，我们可以通过Thread.join()方法结束、Thread.isAlive()的返回值等手段检测到线程已经中止执行。
- **线程中断规则：**对线程interrupt()方法的调用先行发生于被中断线程的代码检测到中断事件的发生，可以通过Thread.interrupted()方法检测到是否有中断发生。
- **对象终结规则：**一个对象的初始化完成(构造函数执行结束)先行发生于它的finalize()方法的开始。
- **传递性：**如果操作A先行发生于操作B，操作B先行发生于操作C，那就可以得出操作A先行发生于操作C的结论。
一个操作"时间上的先发生"不代表这个操作会是先行发生的，一个操作"先行发生"也不能推导出这个操作必定是"时间上的先发生"，一个典型例子就是指令重排序。
时间先后顺序与先行发生原则之间基本没有太大的关系，所以我们衡量并发安全问题的时候不要受到时间顺序的干扰，一切必须以先行发生原则为准。
线程是比进程更轻量级的调度执行单位，线程的引入，可以把一个进程的资源分配和执行调度分开，各个线程既可以共享进程资源(内存地址、文件I/O等)，又可以独立调度(线程是CPU调度的基本单位)。
Thread类与大部分的Java API有显著的差别，它的所有关键方法都是声明为native的。在Java API中，一个Native方法往往意味着这个方法无法使用平台无关手段来实现(当然也可能是为了执行效率而使用Native方法，不过，通常最高效率的手段也就是平台相关的手段)
实现线程主要有三种方式：使用内核线程实现、使用用户线程实现和使用用户线程加轻量级进程混合实现。
1.**使用内核线程实现：**内核线程就是直接由操作系统内核(Kernel)支持的线程，这种线程由内核来完成线程切换，内核通过操纵调度器对线程进行调度，并负责将线程的任务映射到各个处理器上。每个内核线程可以视为内核的一个分身，这样操作系统就有能力同时处理多件事情，支持多线程的内核就叫做多线程内核。
程序一般不会直接去使用内核线程(KLT)，而是去使用内核线程的一种高级接口：轻量级进程(LWP)，轻量级进程就是我们通常意义上所讲的线程，由于每个轻量级进程都由一个内核线程支持，因此只有先支持内核线程，才能有轻量级进程。这种轻量级进程与内核线程之间1:1的关系称为一对一线程模型。
由于内核线程的支持，每个轻量级线程都成为一个独立的调度单元，即使有一个轻量级进程在系统调用中阻塞了，也不会影响整个进程的继续工作，但是轻量级进程具有它的局限性：首先，由于是基于内核线程实现的，所以各种线程操作，如创建、析构及同步，都需要进行系统调用。而系统调用的代价相对较高，需要在用户态和内核态中来回切换。其次，每个轻量级进程都需要有一个内核线程的支持，因此轻量级进程要消耗一定的内核资源(如内核线程的栈空间)，因此一个系统支持轻量级进程的数量是有限的。
2.**使用用户线程实现：**用户线程指的是完全建立在用户空间的线程库上，系统内核不能感知用户线程的存在，用户线程的建立、同步、销毁和调度完全在用户态中完成，不需要内核的帮助，因此操作是非常快速且低消耗的，也可以支持规模更大的线程数量，部分高性能数据库中的多线程就是由用户线程实现的。这种进程与用户线程之间1:N的关系称为一对多的线程模型。
使用用户线程的优势在于不需要系统内核支援，劣势也在于没有系统内核支援，所有的线程操作都需要用户程序自己处理，线程的创建、切换和调度都是需要考虑的问题，而且由于操作系统只把处理器资源分配到进程，那诸如"阻塞如何处理"、"多处理器系统中如何将线程映射到其他处理器上"这类问题解决起来就会非常困难。因此这种实现线程的方式已经很少使用了。
3.使用用户线程加轻量级进程混合实现
线程除了依赖内核线程实现和完全由用户程序自己实现外，还有一种将内核线程与用户线程一起使用的实现方式。在这种混合实现下，既存在用户线程，也存在轻量级进程。用户线程还是完全建立在用户空间中，因此用户线程的创建、切换、析构等操作依然廉价，并且可以支持大规模的用户线程并发。而操作系统提供支持的轻量级进程作为用户线程和内核线程之间的桥梁，这样可以使用内核提供的线程调度功能及处理器映射，并且用户线程的系统调用都要通过轻量级进程来完成，大大降低了整个进程被完全阻塞的风险。在这种混合模式下，用户线程和轻量级进程的数量比是不定的，即为N:M的关系，这种就是多对多的线程模型。
4.Java线程在jdk1.2之前，是基于称为"绿色线程"的用户线程实现的，而在JDK1.2中，线程模型替换为基于操作系统原生线程模型来实现的。因此，在目前的JDK版本中，操作系统支持怎样的线程模型，在很大程度上决定了Java虚拟机的线程是怎样映射的，这点在不同的平台上无法达到一致，虚拟机规范中也并未规定Java线程需要使用哪种线程模型来实现。
对于Sun JDK来说，它的Windows与Linux版都是使用一对一的线程模型实现的，一条Java线程就映射到一条轻量级进程中。在Solaris平台中，由于操作系统的线程特性可以同时支持一对一及多对多线程模型，因此在Solaris版的JDK中也对应提供了两个平台专有的虚拟机参数：-XX:UseLWPSynchronization(默认值)和-XX:+UseBoundThreads来明确指明指定虚拟机使用哪种线程模型。
线程调度是指系统为线程分配处理器使用权的过程，主要调度方式有两种：分别是协同式线程调度和抢占式线程调度。
如果使用协同式线程调度的多线程系统，线程的执行时间由线程本身来控制，线程把自己的工作执行完后，要主动通知系统切换到另外一个线程上。
- 协同式线程调度最大的好处就是实现简单，而且由于线程要把自己的事情干完以后才会进行线程切换，切换操作对线程自己是可知的，所以没有什么同步问题。
- 坏处是：线程执行时间不可控制，甚至如果一个线程编写有问题，一直不通知系统进行线程切换，那么程序将一直阻塞在那里。
如果使用抢占式调度的多进程系统，那么每个线程将由系统来分配执行时间，线程的切换不由线程本身来决定(在Java中，Thread.yield()可以让出执行时间，但是要获取执行时间的话，线程本身是没有什么办法的)。在这种实现线程调度的方式下，线程的执行时间是系统可控的，也不会有一个线程导致整个进程阻塞的问题，Java使用的线程调度方式就是抢占式调度。
在Java中可以通过给线程设置优先级来建议系统给某些线程多分配一点执行时间，在两个线程同时处于Ready状态时，优先级越高的线程越容易被系统选择执行。但是线程的优先级并不太靠谱，原因为Java的线程是通过映射到系统的原生线程上来实现的，所以线程调度最终还是取决于操作系统，虽然现在很多操作系统都提供线程优先级的概念，但是并不能见得与Java线程的优先级一一对应。
线程优先级并不是太靠谱，不仅仅是说在一些平台上不同的优先级实际会变得相同这一点，还有其他情况：因为优先级可能会被系统自行改变。例如Windows系统中存在一个称为"优先级推进器"的功能，大致作用就是当系统发现一个线程执行的特别勤奋努力时，可能会越过优先级为它去分配执行时间。因此，我们不能完全通过优先级来完全准确的判断一组状态都为Ready的线程将会先执行哪个？
Java定义了5种线程状态，在任意的一个时间点，一个线程只能有且只有其中的一种状态，这5种状态分别如下：
- 新建(New)：创建后尚未启动的线程处于这种状态。
- 运行(Runable)：Runable包括了操作系统线程状态中的Running和Ready，也就是处于此状态的线程有可能正在执行，也有可能正在等待着CPU为它分配执行时间。
- **无限期等待(Waiting)：**处于这种状态的线程不会被分配CPU执行时间，他们要等待被其他线程显式的唤醒。以下方法会让线程陷入无限期的等待状态。
- 没有设置TimeOut参数的Object.wait()方法
- 没有设置TimeOut参数的Thread.join()方法
- LockSupport.park()方法
- **限期等待：**处于这种状态的线程也不会被分配CPU执行时间，不过无需等待被其他线程显式地唤醒，在一定时间之后它们会由系统自动唤醒。以下方法会让线程进入限期等待：
- Thread.sleep()方法
- 设置了TimeOut参数的Object.wait()方法
- 设置了TimeOut参数的Thread.join()方法
- LockSupport.parkNanos()方法
- LockSupport.parkUntil()方法
- **阻塞：**线程被阻塞了，"阻塞状态"与"等待状态"的区别是："阻塞状态"在等待着获取到一个排它锁，这个事件将在另外一个线程放弃这个锁的时候发生；而等待状态则是等待一段时间或者唤醒动作的发生。在程序等待进入同步区域时，线程将进入这种状态。
- **结束：**已终止线程的线程状态，线程已经结束执行。
