简介：
阿姆达尔定律(Amdahl)：该定律通过系统中并行化与串行化的比重来描述多处理器系统能获得的运算加速能力。
摩尔定律(Moore)：该定律用于描述处理器晶体管数量与运行效率间的发展关系。
当价格不变时，集成电路上可容纳的元器件的数目，约每隔18-24个月便会增加一倍，性能也将提升一倍。
Moore
系统中对某一部件采用更快执行方式所能获得的系统性能改进程度，取决于这种执行方式被使用的频率，或所占总执行时间的比例。
阿姆达尔定律实际上定义了采取增强(加速)某部分功能处理的措施后可获得的性能改进或执行时间的加速比。
Amdahl
并发处理使得 Amdahl 定律代替摩尔定律成为计算机性能发展源动力的根本原因，也是人类“压榨”计算机运算能力的最有力武器。
多任务处理几乎是现代计算机操作系统的一项必备功能
由于计算机的运算速度与它的存储和通信子系统速度差距太大，大量时间花费在磁盘IO等，所以才去多任务充分利用计算机处理器能力。
1. 硬件的效率与一致性
“让计算机并发执行若干个运算任务”与“更充分地利用计算机处理器的效能”之间的因果关系，两者之前关系并非简单，
因为绝大多数的运算任务不可能只靠处理器“计算”就能完成，处理器至少要与内存交互，此IO操作很难消除。
由于计算机的存储设备与处理器的运算速率有几个数量级的差距，
所以现代计算机必须引入一层读写速度尽可能接近处理器速度的高速缓存(cache) 来作为内存与处理器间的缓冲：
将运算需要使用到的数据复制到缓存中，让运算能快速进行，当运算结束后再从缓冲同步回内存中，这样处理器就无须等待缓慢的内存读写了。
1,1缓存一致性(Cache Coherence)
缓存的引入产生了一个新问题——缓存一致性：
在多处理器系统中，每个处理器都有自己的高速缓存，而它们又共享同一主内存，
如下图所示
当多个处理器的运算任务都涉及到同一块内存区域时，将可能导致各自的缓存数据不一致，那同步到内存时以谁的数据为准呢？
解决方法：
需要各个处理器遵循一些协议，在读写时要根据协议来进行操作，这类协议有 MSI， MESI等。
1,2，乱序执行
为了使得处理器内部的运算单元能够被尽量使用，处理器可能对输入代码进行乱序执行优化，
处理器会在计算之后将乱序执行的结果重组，保证该结果与顺序执行的结果是一致的。
2. Java 内存模型
Java虚拟机规范试图定义一种Java内存模型来屏蔽掉各种硬件和操作系统的内存访问差异，以实现Java程序在各种平台下都能达到一致的内存访问效果。
2,1，Java内存模型的主要目标
定义程序中各个变量的访问规则，即在虚拟机中将变量存储到内存和从内存中读取变量这样的底层细节。
此处的变量不同于Java编程，不包括局部变量与方法参数，因为后者是线程私有的，不被共享，自然不会存在竞争问题。
2,2，Java内存模型规定了：所有的变量都存储在主内存中。
每条线程还有自己的工作内存，线程的工作内存中保存了被该线程使用到的变量的主内存副本拷贝，
线程对变量的所有操作(读取，赋值)都必须在工作内存中进行，而不能直接读写内存中的变量。
不同的线程之间也无法直接访问对方工作内存中的变量。
2,3，线程、内存、工作内存三者关系
线程间变量值的传递均需要通过主内存来完成。
这里所讲的主内存、工作内存与前面讲解Java内存区域中的Java堆、栈、方法区等不是同一个层次划分，两者无任何关系。
即：内存模型和内存结构是两个不同的概念。
3. 内存间交互操作
3,1，主内存与工作内存交互协议的8种操作：
即一个变量如何从主内存拷贝到工作内存，如何从工作内存同步回主内存的实现细节。
Java 内存模型中定义了以下8种操作(operations)来完成：
lock(锁定) ：作用于主内存的变量，它把一个变量标识为一条线程独占的状态。
unlock(解锁)：作用于主内存的变量，它把一个处于锁定状态的变量释放出来，释放后的变量才可以被其他线程锁定。
read(读取) ：作用于主内存的变量，它把一个变量的值从主内存传输到线程的工作内存中，以便随后的load 动作使用。
load(载入) ：作用于工作内存的变量，它把 read 操作从主内存中得到的变量放入工作内存的变量副本中。
use(使用) ：作用于工作内存的变量，它把工作内存中一个变量的值传递给执行引擎，每当虚拟机遇到一个需要使用到变量的值的字节码指令时将会执行这个操作。
assign(赋值)：作用于工作内存的变量，它把一个从执行引擎接收到的值赋给工作内存的变量，每当虚拟机遇到一个给变量赋值的字节码指令时执行这个操作。
store(存储) ：作用于工作内存的变量，它把工作内存中一个变量的值传送到主内存中，以便随后的write操作使用。
write(写入) ：作用于主内存的变量，它把store操作从工作内存中得到的变量的值放入主内存的变量中。
3,2，执行8种操作需满足的规则
如果要把一个变量从主内存复制到工作内存，那就要顺序地执行 read 和 load 操作。
如果要把变量从工作内存同步到主内存，就要顺序地操作 store 和 write 操作。
注意：
Java内存模型只要求上述两个操作必须按照顺序执行，而没有保证是连续执行。
也就是说，read 和 load 之间、store 和 write 之间是可插入其他指令的。
如对内存中的变量a、b 进行访问时，一种可能出现的顺序是 ：read a、read b、load b、load a 。
除此之外，Java内存模型还规定在执行上述8种操作需满足的规则：
1，不允许read和load，store和write操作之一单独出现，即不允许一个变量从主内存读取了但工作内存不接受，或者从工作内存回写了但主内存不接受的情况出现。
2，不允许一个线程丢弃它的最近的assign操作，即变量在工作内存中改变了之后必须把该变化同步回主内存。
3，不允许一个线程无原因地(没有发生过任何assign操作)把数据从线程的工作内存同步回主内存中。
4，一个新变量只能在主内存中诞生，不允许在工作内存中直接使用一个未被初始化的变量，换句话说，对一个变量实施 use，store操作前，必须先执行过 assign 和 load 操作。
5，一个变量在同一个时刻只允许一个线程对其进行lock 操作，但lock操作可以被同一条线程重复执行多次，多次执行 lock后，只有执行相同次数的unlock 操作，变量才会被解锁。
6，如果对一个变量执行lock 操作，那将会清空工作内存中此变量的值，在执行引擎使用这个变量前，需要重新执行 load 或 assign 操作初始化变量的值。
7，如果一个变量事先没有被lock操作锁定，那就不允许对它执行unlock操作，也不允许去 unlock 一个被其他线程锁定住的变量；
8，对一个变量执行unlock 变量前，必须先把此变量同步回主内存中(执行store， write操作)。
PS：第6点有些疑问，为什么是载入和赋值，而不是载入和使用。个人理解为当前线程执行load前，是在其他线程执行assign完成后。
1，原子性：要么都执行要么都不执行。
在数据库中，中间如果执行有问题可以回滚来保证所以操作是一个整体。。
而在并发中有两个意思：
1，代表了原子性的操作(几个步骤是一个原子)在线程执行过程中不会被中断，是一个整体。2，原子性是拒绝多线程操作的，不论是多核还是单核，具有原子性的量，同一时刻只能有一个线程来对它进行操作！
ps：原子性：在其执行过程中，不允许其他并行线程对该变量进行读取和写入的操作。 如果发生竞争，则其他线程必须等待。
补充：
1，线程中断：一段程序其实是很多条指令的集合，多线程的情况，每条线程被处理器分配一定执行时间来执行这些指令，所以执行并非连续的。
Java自带的原子性
在Java中，对基本数据类型的变量的读取和赋值操作是原子性操作。
赋值或者return。比如"a = 1;"和 "return a;"这样的操作都具有原子性
非原子性操作：
类似"a += b" 或 “a++” 这样的操作不具有原子性，经过三个步骤：
(1)取出a和b
(2)计算a+b
(3)将计算结果写入内存
如果有两个线程t1,t2在进行这样的操作。t1在第二步做完之后还没来得及把数据写回内存就被线程调度器中断了，
于是t2开始执行，t2执行完毕后t1又把没有完成的第三步做完。这个时候就出现了错误，相当于t2的计算结果被无视掉了。
2，可见性：
可见性是指当多个线程访问同一个变量时，一个线程修改了这个变量的值，其他线程能够立即看得到修改的值。
如果线程t1与线程t2分别被安排在了不同的处理器上面，那么t1与t2对于变量A的修改时相互不可见，
如果t1给A赋值，然后t2又赋新值，那么t2的操作就将t1的操作覆盖掉了，这样会产生不可预料的结果。
所以，即使有些操作是原子性的，但是如果不具有可见性，那么多个处理器中备份的存在就会使原子性失去意义。
(ps:原子性应该只是读和计算，而没有写入主内存)
来源《java编程思想》：原子性和可变性：
1 原子性
原子操作是不能被线程中断机制中断的操作，
一旦操作开始，则它一定在可能的切换到其他线程之前执行完毕。简而言之就是不能被中断的操作，如赋值或return。
1,1，对于读写除long和double之外的基本类型变量的简单操作，可以保证它们的原子性来操作内存，
因为JVM将long和double这样的64位的变量拆分成两个分离的32位来操作，这样很可能在一个读取和写入操作之间切换到其它线程，从而导致错误的结果。
1,2， 类似a+=2的操作不具备原子性，因为在JVM中这个操作需要三个步骤：
1)取出a2)计算a+2
3)将计算结果写入内存
在上述步骤之间很可能线程调度器中断，转向另一个任务，这个任务可能修改这个域，造成结果错误，所以这个操作不是原子性的。
同样a++也不具备原子性。(注：在C++中以上这两种操作都是原子性的)
2 可视性
在多核处理器中，如果多个线程同时对一个变量进行操作，这些线程可能被分配到不同的CPU中运行。
由于编译器会对代码进行优化，当某个线程要对这个变量进行操作时，为了提高操作速度，
这个线程所在的CPU会从主存中复制这个变量到自己的缓存中，等操作完成后再存储到主存中。
因此不同的线程对应的这个变量就有不同的状态。(注：在单核处理器中也存在可视性问题)
变量的可视性：
假设有两个线程T1和T2分别被安排到了两个不同的CPU中(cpu1、cpu2)，则T1和T2对变量a的修改互不可视，
如T1对a进行修改之后，只是对cpu1缓存中的a运行修改，没有立即被写入到主存中，
因此当线程T2再对a进行操作时，操作的并不是被线程T1修改后的新值。
此时线程T1和线程T2对于变量a是互不可视的。
不可视性产生的问题：
多个线程对某个变量的操作互不可视，可能造成某些操作被覆盖，产生错误的结果。
如对于变量a，线程T1和线程T2都对其进行a++操作，T1操作a++后并没有及时地将结果写入到主存中去，而是继续执行其它对a的操作，
当T2再执行a++操作后，它并没有发现a的值已被线程T1修改，这样就由于a的值没有被及时更新而产生错误。
PS:
没有原子性产生的问题：当前线程执行中断。其他线程覆盖执行。
不可视性产生的问题：(有原子性的情况)执行完变量的原子性的部分后，继续执行对变量相关的其他操作。其他线程不知道变量的变化，覆盖执行。
二 、 volatile与synchronized关键字在原子性和可视性中的应用
(1)当对long和double类型的变量用关键字volatile修饰时，就能获得简单操作(赋值和(return)的原子性。
但除对long和double简单类型的简单操作外，volatile并不能提供原子性，即使对一个变量用volatile修饰，对这个变量的操作也不是原子性的。
(2)volatile与可视性：
volatile赋予变量可视性，它修饰的变量每次被线程访问时都要从主存中重新读取该变量的值，
并且当变量的值发生变化时会强迫线程刷新到主存中去，这样在任何时刻，从不同的线程看某一变量都是相同的值，从而保证了变量的可视性。
使用场合：
如果多个线程同时访问某个变量，那个这个变量就应该用volatile修饰，
如果这个变量已在由synchronized修饰的方法或代码块中，则不必再用volatile修饰。(注：优先选择使用synchronized关键字，因为这是最安全的方式)
原理：
为了获得最佳速度，允许线程保存共享成员变量的私有拷贝，而且只当线程进入或者离开同步代码块时才与共享成员变量的原始值对比。
这样当多个线程同时与某个对象交互时，就必须要注意到要让线程及时的得到共享成员变量的变化。
而volatile关键字就是提示JVM：对于这个成员变量不能保存它的私有拷贝，而应直接与共享成员变量交互。
因此当要访问的变量已在synchronized代码块中(因为线程进入或离开同步代码块时会更新共享变量的值)，或者为常量时，不必再使用volatile。
由于使用volatile屏蔽掉了JVM中必要的代码优化，所以在效率上比较低。
(3)synchronized关键字与操作原子性：
synchronized为一段操作或内存加锁，具有互斥性。
当线程要操作被synchronized修饰的方法或代码块时，必须先获得锁。
但是同一时刻只能有一个线程持有同一把锁(对象监示器)，所以只允许一个线程对被synchronized修饰的方法或代码块进行操作。
synchronized关键字可以看作是解决多线程原子性操作的方法，因为它拒绝同一时刻多个线程对同一资源的访问。
volatile的两大特殊规则
1. 对于 volatile 型变量的特殊规则
1,1，volatile的特性 —– 可见性
可见性：当一条线程修改了这个变量的值，新值对于其他线程来说是可以立即得知的。
而普通变量做不到这一点，其在线程间传递需要通过主内存来完成。
例如，线程A修改一个普通变量的值，然后向主内存进行回写，另外一条线程B在线程A回写完成之后再从主内存进行读取操作，新变量值才会对线程B可见。
“可见性”的误解:
错误认为：volatile变量对所有线程都是可见的，对volatile变量所有的写操作都能立刻反应到其他线程中，
实际：volatile变量在各个线程中是一致的，但在并发下是不安全的。
并发下volatile的不安全性示例
volatile变量在各个线程的工作内存中不存在一致性问题，但Java运算并非原子操作，导致 volatile变量的运算在并发下一样是不安全的
public classVolatileTest {public static volatile int race = 0;public static voidincrease() {
race++;
}public static final int THREADS_COUNT = 20;public static voidmain(String[] args) {
Thread[] threads= newThread[THREADS_COUNT];for (int i = 0; i < threads.length; i++) {
threads[i]= new Thread(newRunnable() {
@Overridepublic voidrun() {for (int j = 0; j < 10000; j++) {
increase();
}
}
});
threads[i].start();
}//等待所有累计线程都ending
while(Thread.activeCount() > 1) {
Thread.yield();
}
System.out.println(race);
}
}
如果这段代码能够正确并发，最后输出结果是200000。但是运行了3次，得出的结果都是小于200000的一个数字。
并发失败原因：
问题在于自增运算race++ ，increase() 方法在Class文件中是由4条字节码指令构成：
从字节码层面上分析并发失败原因：
当 getstatic 指令把race的值取到操作栈顶(读取，加载)时，volatile关键字保证了 rece 的值此时是正确的，
但是在执行 iconst_1、iadd这些指令(使用)时，其他线程可能已经把 race的值加大了，
而在操作栈顶的值就变成了过期的数据，所以 putstatic 指令(赋值，存储，写入)执行后就可能把较小的 race 值同步回内存之中。
客观而言，在此使用字节码分析并发问题并不严谨，因为即使编译出来的只有一条字节码指令，并不意味执行这条指令是一个原子操作。
由于 volatile 变量只能保证可见性，在不符合以下两条规则的运算场景中，仍然要通过加锁(使用 synchronize 或 java.util.concurrent中的原子类)来保证原子性。
1，运算结果并不依赖变量的当前值，或者能确保只有单一的线程修改变量的值。
2，变量不需要与其他的状态变量共同参与不变约束。
像以下代码所示的这类场景很适合使用 volatile 变量来控制并发，当showdown() 方法被调用时，能保证所有线程中执行的doWork()方法立即停下来：
//使用volatile变量来控制并发
public classVolatileVariableTest {volatile boolean shutdownRequested; //volatile变量
public voidshutdown() {
shutdownRequested= true;
}public voiddoWork() {while(!shutdownRequested) {//do sth.
}
}
1,2，volatile的特性 —– 禁止指令重排序优化
使用volatile变量的第二个语义是禁止指令重排序优化：
普通变量仅仅会保证在单线程的执行过程中所有依赖赋值结果的地方都能获取到正确的结果，而不能保证变量赋值操作的顺序与程序代码中的执行顺序一致。
我们在单线程的执行过程中是无法感知到这点，这也就是java 内存模型中描述的所谓的 “线程内表现为串行的语义”。
【指令重排序演示(伪代码)】
Map configOptions;char[] configText;//此变量必须为 volatile
volatile boolean initialized = false;
1，//假设以下代码在线程A 中执行//模拟读取配置信息，当读取完成后将 initialized 设置为true 已通知其他线程配置可用
configOptions = newHashMap();
configText=readConfigFile(filename);
processConfigOptions(configText, configOptions);
initialized= true;
2，//假设以下代码在线程B 中执行//等待initialized 为true，代表线程A 已经把配置信息初始化完成
while(!initialized) {
sleep();
}//使用线程A 中初始化好的配置信息
doSomethingWithConfig();
}
如果定义initialized变量没有使用volatile修饰：
就可能会由于指令重排序的优化，导致位于线程A 中最后一句码initialized=true被提前执行(即这行代码对应的汇编代码被提前执行)，
这样在线程B中使用配置信息的代码就可能出现错误(获取时还没有初始化配置)，而volatile关键字则可以避免此类情况的发生。
PS:内存屏障的目的
因为缓存导致的可见性和,cpu/编译期重排序执行优化可能导致错误。
不同的处理器重排序的规则也是不一样的。
java内存模型为了避免这种差异造成的问题，通过内存屏障方式来实现可见见性和非重排序。
常见的有2种方式：1，通过 Synchronized关键字包住的代码区域,插入了StoreStore屏障2，使用了volatile修饰变量,则对变量的写操作,会插入StoreLoad屏障.
不常用的，通过Unsafe这个类来执行.
UNSAFE.putOrderedObject类似这样的方法,会插入StoreStore内存屏障
Unsafe.putVolatiObject 则是插入了StoreLoad屏障
内存屏障 示例
volatile关键字是如何使用内存屏障禁止指令重排序优化的，
内存屏障(Memory Barrier)，指重排序时不能把后面的指令重排序到内存屏障之前的位置。当两个或以上的CPU访问同一块内存时，需要内存屏障来保证一致性。
为何说它禁止指令重排序呢？
从硬件上而言，指令重排序呢是指CPU采用允许将多条指令不按程序规定的顺序分开发送给各相应电路单元处理。
并非说是任意重排，例如(a*b)+c 与 c+(a+b)，代表c相加的指令是可以重排的。
比如屏障指令把修改同步到内存时，意味着所有之前的操作都已经执行完成，这便形成了“指令重排序无法越过内存屏障”的效果。
使用 volatile 还是 锁？
众多保障并发工具都使用了volatile 关键字，在某些情况下，它的同步机制性能要优于锁(使用synchronized 关键字或java.util.concurrent包里的锁)，
但由于虚拟机对锁实行的许多消除和优化，它并非快多少。
若让volatile 关键字与锁比较，可确定一个原则：
它读操作的、性能消耗与普通变量几乎无差别，写操作可能较慢，因为需要在本地代码中插入许多内存屏障指令来保证处理器不发生乱序执行。
但即便如此，大多数volatile 关键字的总开销仍比锁低，选择的唯一依据是它的语义能否满足使用常见的要求。
2. 对于 long 和 double 型变量的规则
(1)64位数据类型的非原子性协定
Java内存模型要求lock， unlock， read， load， assign， use，store，write这8个操作都具有原子性，
但对于64位的数据类型(long和double)，在模型中特别定义了一条相对宽松的规定：
允许虚拟机将没有被 volatile 修饰的64位数据的读写操作划分为 两次 32位的操作来进行，
即允许虚拟机实现选择可以不保证64位数据类型的 load， store，read和write 这4个操作的原子性，
这点就是所谓的 long 和double 的非原子性协定(Nonatomic Treatment of double and long Variable)。
(2)非原子性协定导致的问题
如果有多个线程共享一个并未声明为 volatile的 long 或 double类型的变量，并且同时对它们进行读取和修改操作，
那么某些线程可能会读取到一个既非原值，也不是其他线程修改值的代表了“半个变量”的数值。
(3)“半个变量”的情况
不过这种读取到的“半个变量”的情况非常罕见(商业JVM中尚未出现)：
因为Java内存模型虽然允许虚拟机不把long 和 double 变量的读写实现成原子操作，
但允许虚拟机选择把 这些操作实现为具有原子性的操作，而且还强烈建议虚拟机这样实现。
实际开发中，目前各平台下的商用虚拟机几乎选择把64位数据读写操作作为原子操作来对待，
因此平时编写代码时不需要把long 和 double 变量专门声明为 volatile。
并发过程三大特征 与 先行发生原则
1. 原子性、可见性与有序性
Java内存模型是围绕着在并发过程中如何处理原子性， 可见性和有序性这3个特征来建立的。
(1)原子性(Atomicity)
由于Java内存模型来直接保证的原子性变量操作包括 read，load，assign，use，store和write，
我们大致认为基本数据类型的访问读写数据是具备原子性的。
更大范围的原子性保证
如果应用场景需要一个更大范围的原子性保证，Java内存模型还提供了lock 和 unlock 操作来满足这些需求，
尽管虚拟机没有把lock 和 unlock 操作直接开放给用户使用，
但是却提供了更高层次的字节码指令 monitorenter 和 monitorexit 来隐式地使用这两个操作。
synchronized关键字
monitorenter 和 monitorexit 这两个字节码指令反映到java代码中就是同步块——synchronized关键字，因此在synchronized块之间的操作也具备原子性。
(2)可见性(Visibility)
指当一个线程修改了共享变量的值，其他能够立即得知这个修改。
Java内存模型是通过在变量修改后将新值同步回主内存，
在变量读取前从主内存刷新变量值这种依赖主内存作为传递媒介的方式来实现可见性的，
无论是普通变量还是volatile变量都是如此
普通变量与 volatile变量的区别
volatile的特殊规则保证了新值能立即同步到主内存，以及每次使用前立即从主内存刷新，
所以volatile保证了多线程操作时变量的可见性，
普通变量则不能保证这一点。
synchronized 和 final关键字
除了volatile关键字外，Java还有两个关键字实现可见性： synchronized 和 final。
synchronized同步块的可见性： 是由对一个变量执行unlock 操作前，必须先把此变量同步回主内存中；
final关键字的可见性：被final修饰的字段在构造器中一旦初始化完成，并且构造器没有把this 的引用传递出去
(this引用传递很危险，其他线程很有可能通过此引用访问到“初始化了一半”的对象)，
那在其他线程中就能看见final 字段的值。
关于final关键字的可见性，以下代码中的变量i 与 j 都具备可见性，它们无须同步就能被其他线程正确访问：
(3)有序性(Ordering)
如果在本线程内观察，所有的操作都是有序的；如果在一个线程中观察另一个线程，所有的操作都是无序的
volatile和 synchronized关键字保证了线程间操作的有序性
volatile关键字本身就包含了禁止指令重排序的语义。
synchronized则是由 一个变量在同一时刻只允许一条线程对其进行lock 操作这条规则获得的，这条规则决定了持有同一个锁的两个同步块只能串行地进入。
2. 先行发生(happens-before)原则
若Java内存模型中所有的有序性都仅仅靠 volatile 和 synchronized 来完成，那么有些操作将很繁琐，
而Java语言中的“先行发生”语言已考虑到，它是判断断数据是否存在竞争、线程是否安全的主要依据。
先行发生原则定义：
先行发生是Java内存模型中定义的两项操作之间的偏序关系，
如果说操作A 先行发生于操作B，其实就是说在发生操作B之前，操作A产生的影响能被操作B观察到，
影响包括 修改了内存中共享变量的值，发送了消息，调用了方法等。
PS：所谓产生影响能被后发生的观察到，指的是前面发生的影响和后面发生的必须是有关联，不然视作没有影响。(即，有关联的影响一定能观察到)。
先行发生规则
下面是 Java内存模型下一些天然的先行发生关系，这些先行发生关系无须任何同步器协助就已经存在，可以在编码中直接使用：
程序次序规则(Program Order Rule)：在一个线程内，按照程序代码顺序，书写在前面的操作先行发生于书写在后面的操作，准确地说，应该是控制流顺序。
管程锁定规则(Monitor Lock Rule)：一个unlock操作先行发生于后面对同一个锁的lock操作；这里必须强调的是同一个锁，而后面是指时间上的先后顺序。
volatile变量规则(Volatile Variable Rule)：对一个volatile变量的写操作先行发生于后面对这个变量的读操作，这里的后面是指时间上的先后顺序。
线程启动规则(Thread Start Rule)： Thread对象的start() 方法先行发生于此线程的每一个动作。
线程终止规则(Thread Temination Rule)：线程中的所有操作都先行发生于对此线程的终止检测，可以通过Thread.join() 方法结束，
Thread.isAlive() 的返回值等手段检测到线程已经终止运行。
线程中断规则(Thread Interruption Rule)：对线程interrupt() 方法的调用先行发生于被中断线程的代码检测到中断事件的发生，
可以通过 Thread.interrrupted() 方法检测到是否有中断发生。
对象终结规则(Finalizer Rule)：一个对象的初始化完成先行发生于它的finalize() 方法的开始。
传递性(Transitivity)：如果操作A 先行发生于操作B， 操作B 先行发生于操作C，那就可以得出操作A先行发生于操作C的结论。
时间先后顺序 与 先行发生原则 关系探讨
private int value = 0;public void setValue(intvalue) {this.value =value;
}public intgetValue() {returnvalue;
}
以上代码是经常出现JavaBean中的 get/set方法，假设线程A 先调用了 setValue(1)， 之后线程B 调用了同一个对象的getValue() ，那么线程B 收到的value是什么？
尽管线程A在操作时间上先于线程B， 但是无法确定线程B 中getValue() 方法的返回结果，换句话说，这里面的操作不是线程安全的。
解决办法
要么把getter 和 setter方法都定义为 synchronized方法，这样就可以套用管程锁定规则；
要么把value定义为 volatile变量，由于setter方法对value的修改不依赖于value的原值，
满足volatile关键字使用场景，这样就可以套用volatile变量规则来实现先行发生关系；
一个操作 “时间上的先发生” 不代表这个操作会是“先行发生”。
那如果一个操作“先行发生”是否就能推导出这个操作必定是 “时间上的先行发生”呢？
此推理时不成立的。一个典型的例子就是多次提到的“指令重排序”，代码如下：
//以下操作在同一个线程中执行
int i = 1;int j = 2;
根据程序次序规则， int i = 1 的操作先行发生于 int j =2，但 int j = 2 完全可能先被处理器执行，这并不影响先行发生原则的正确性。
最终结论
时间先后顺序与先行发生原则之间基本没有太大的关系，所以我们衡量并发安全问题的时候不要受到时间顺序的干扰，一切必须以先行发生原则为准。
