并发处理的广泛应用是使得Amdahl定律代替摩尔定律成为计算机性能发展源动力的根本原因，也是人类“压榨”计算机运算能力的最有力武器。
其实我很喜欢每篇文章标题的这一句话。虽然这篇这句我并不十分懂得。然后又去屁颠屁颠百度了一下。Amdahl定律（阿姆达尔定律） ，另一个是摩尔定律。感兴趣的同学可以自己去看看这两个定律的内容。
然后接下来说本章节的内容。
概述
多任务处理在现代计算机操作系统中几乎已经是一项必备的功能了。许多情况下让计算机同时去做几件事，不仅是因为计算机的运算能力强大。还有一个重要的原因是计算机的运算速度和他的存储通信子系统素的的差距太大。大量的时间都花费在磁盘I/O，网络通信或者数据库访问上。如果不想大部分时间都在等待，我们就应该让计算机同时处理几项任务。
服务端是java语言最擅长的领域之一。这个领域的应用占了java应用的最大的一块份额。不过如何写好并发应用程序又是服务端程序开发的难点之一。处理好并发问题通常需要编码经验来支持。幸好java语言和虚拟机提供了很多工具。把并发编程的门栏降低了好多。并且各种中间件服务器，各类框架都努力的替程序员处理尽可能多的线程并发细节。使得程序员在编码时可以更关注业务逻辑。但是无论语言，中间件如何先进，但是了解并发的内幕也是一个程序员不可或缺的课程。
“高效并发”是这本书讲解java虚拟机的最后一部分。将会介绍虚拟机如何实现多线程，多线程之间由于共享和竞争数据而导致的一系列问题和解决方案。
硬件的效率与一致性
“缓存一致性：”在多处理器系统中，每个处理器都有自己的高速缓存，而他们又共用同一个主内存。当东哥处理器的运算任务都涉及同一块主内存区域时，将可能导致各自的缓存数据不一致。如果真这样了，那么同步回主内存时以谁的缓存数据为准呢？
基于这种情况，为了解决缓存一致性的问题，需要各个处理器访问缓存时都遵循着一些协议。在读写的时候要根据协议来进行操作。这类协议有MSI,MESI,MOSI,Synapse，Firefly等。本章提到的“内存模型”可以理解为在特定的协议下，对特定的内存或者高速缓存进行读写访问的过程抽象。
Java内存模型
java虚拟机规范中试图定义一种java内存模型。使得java程序在各种平台下都能达到一致的内存访问效果。（C++等是直接使用物理硬件和操作系统的内存模型。所以不同平台上内存模型会不一样。所以必须针对平台编程。这个也是java一次编程到处使用的原因）。
在jdk1.5以后，这个java内存模型已经成熟和完善起立了。
主内存和工作内存
java内存模型主要是定义程序中各个变量的访问规则。也就是虚拟机将变量存储到内存和从内存读取的底层细节。此时的变量包括实例字段，静态字段和构成数组对象的元素。不包括局部变量和方法参数。因为后者是线程私有的，不会被共享，自然就不存在竞争问题。
java内存模型规定了所有的变量都存储在主内存中。每条线程还有自己的工作内存。线程的工作内存保存了被该线程使用的主内存副本拷贝。线程对内存的所有读写操作都在工作内存中进行。不同的线程之间也不能直接访问对方工作内存中的变量。线程间变量值的传递都通过主内存完成。
注意下这里讲的主内存和虚拟机内存是不一样的。主内存就是直接对应物理硬件的内存。
内存间交互操作
关于主内存与工作内存之间的交互协议，即一个变量如何从主内存拷贝到工作内存。如何从工作内存同步到主内存中的实现细节。java内存模型定义了8种操作来完成。这8种操作每一种都是原子操作。
- lock(锁定)：作用于主内存的变量，它把一个变量标记为一条线程独占状态。
- unlock(解锁)：作用于主内存的变量，它将一个处于锁定状态的变量释放出来，释放后的变量才能够被其他线程锁定。
- read(读取)：作用于主内存的变量，它把变量值从主内存传送到线程的工作内存中，以便随后的load动作使用。
- write(写入)：作用于主内存的变量，它把store传送值放到主内存中的变量中。
- load(载入)：作用于工作内存的变量，它把read操作的值放入工作内存中的变量副本中。
- use(使用)：作用于工作内存的变量，它把工作内存中的值传递给执行引擎，每当虚拟机遇到一个需要使用这个变量的指令时候，将会执行这个操作。
- assign(赋值)：作用于工作内存的变量，它把从执行引擎获取的值赋值给工作内存中的变量，每当虚拟机遇到一个给变量赋值的指令时候，执行该操作。
- store(存储)：作用于工作内存的变量，它把工作内存中的一个变量传送给主内存中，以备随后的write操作使用。
以上八个前四个是作用于主内存，后四个作用于工作内存。如果把一个变量从主内存复制到工作内存，就是先read在load。如果把工作内存的变量同步到主内存就是store在write。
java内存模型规定了执行上述八种基本操作时必要满足的规则：
- 不允许read和load、store和write操作之一单独出现（即不允许一个变量从主存读取了但是工作内存不接受，或者从工作内存发起会写了但是主存不接受的情况），以上两个操作必须按顺序执行，但没有保证必须连续执行，也就是说，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操作）。
其实感觉上述的规则还是很明确清晰而且符合逻辑的。用我自己的话理解理解（这个是为了加深我自己的印象。说的不准确勿喷）。
主内存和工作内存相当于两个人或者程序。
- 主内存的读和工作内存的加载是一个行为的两个部分。不可单独。就好像我们测试时候的接口调用和被调用一样。肯定是要两方都有行为啊！同理工作内存的存储和主内存写也是一样的。
- 你赋值一个变量或者说改一个变量了必须交上去。不能自己偷偷的改了然后就没然后了。换种思维理解也是一种不做无用功的规定。你贼喜欢你女神，然后天天微信框发八百字作文但是一次都不发出去。那样的不是有病么？也不符合逻辑啊~这条规定就很好，赋值了必须提交上去。
- 这个也是从正常逻辑就能理解。我都不知道咋解释了，就是没改动没必要提交上去！svn我们常用吧?一般team开发都是每天提交进度。然后你要是今天啥也没写就摸鱼了，有什么好提交的?
- 首先都没加载呢，所以不能用。也就是没load并不能use。然后之前上条，没有变化的不能再写回主线程。而storehewrite必须同时使用。所以说没有assign的不能store。这个其实联系联系都能分析出来。这里还专门作为一条规范了。
- 一个变量只能同时被一个线程锁。我们上锁的目的不就是为了独占么？还有啥可解释的？至于这个锁多次。现实中的比喻。我有一个大宝贝，怕丢了。所以藏起来锁起来了。觉得不放心。然后锁了18层。是不是可以？同样道理，我现在想看看我的大宝贝，是不是得一层锁一层锁的解开？我只打开10层锁也看不到我大宝贝啊！
- （这一点其实我看着有点小费解，但是找了半天没找到解释。所以把我的理解打出来，如果有大佬明确知道意思麻烦告知下）就是我觉得可能是
第一：锁之前，我们拿到的数据可能是没那么准确的。假如你前脚拿到数据后脚别的线程给改了呢？所以我们这个锁机制是锁上以后，再去read-load一次。这时候你能确保你手头拿的肯定是最新的数据了。因为你上锁了，这时候包括以后别的线程都不能动这个数据了！同样你自己也可以重新assign改这个值。（这点我不确定，反正我自己这么理解了。）
第二：这个时候所有其它使用到这个变量的线程中的所有的对这个变量的引用都清空。等解锁以后才可以从新read-load读取。 - 这个简单明了。没上锁的自然不能解锁。你也不能拿着自家的钥匙去解别人家的锁。
- 在解锁之前把变量同步到主内存。因为变量解锁后别的线程就可以read-load了。你不同步让主内存read啥？
volatile型变量的特殊规则
关键字volatile是java虚拟机提供的最轻量级的同步机制。这个关键字有一个很有意思的代码例子能让大家更了解volatile。
package demo;
public class VolatileDemo {
private static volatile int num = 0;
public static void add() {
num++;
}
public static void main(String[] args) {
Thread[] threads = new Thread[20];
for (Thread thread : threads) {
thread = new Thread(new Runnable() {
@Override
public void run() {
for (int i = 0; i < 10000; i++) {
add();
}
}
});
thread.start();
}
while (Thread.activeCount()>1)
Thread.yield();
System.out.println(num);
}
}
如果说线程安全的，最理想的情况下输入的是20*10000.也就是结果是20w、但是真正跑起来却不是.每次跑从六万多到12万多。我点了几十次。都没有20w的结果。而且每次运行的结果也不同。这是因为num++这个操作在执行的时候分为了四个字节码指令。在获取num的时候保证是正确的，但是在下面的指定的时候可能别的线程把这个num值改变了。反而这次提交把num值改小了。
由于volatile只能保证可见性。所以以下两个场景中还是要synchronized或者concurrent来加锁的。
- 运算结果并不依赖变量的当前值，或者能够确保只有单一的线程修改变量值。
- 变量不需要与其他的状态变量共同参与不变约束。
其实volatile的同步机制的性能是要优于锁的。volatile的读操作的性能几乎与普通变量没什么区别。写操作可能会慢一点。即便如此volatile的消耗也比锁要低。我们在volatile与锁的选择中唯一的依据仅仅是volatile的语义能否满足使用场景的需求。
long和double的特殊规则：这个简单的说一下，long和double这样的64位数据类型有一条特别的规定：没有被volatile修饰的64为数据的读写操作划分为两次32为的操作。这就是所谓的long和double的非原子性协定。虽然java内存模型允许虚拟机不把long和double的读写实现成原子操作。但是虚拟机本身都是当成原子对待的。
原子性，可见性，有序性
原子性：即一个操作或者多个操作，要么全部执行并且执行的过程不会被任何因素打断，要么就都不执行。原子性就像数据库里面的事务一样，他们是一个团队，同生共死。我们大致可以认为基本数据类型的访问读写是具有原子性的。如果应用场景需要大范围的原子性，我们可以用锁。
可见性：可见性是指当多个线程访问同一个变量时，一个线程修改了这个变量的值，其他线程能够立即看得到修改的值。
我们上面讲的volatile就是保证了多线程操作时变量的可见性。而普通变量不能保证。
有序性：总结成一句话：在本线程内观察，所有的操作都是有序的。如果在一个线程内观察另一个线程，所有的操作都是无序的。
先行发生原则
- 程序次序规则：一个线程内，按照代码顺序，书写在前面的操作先行发生于书写在后面的操作。
我的理解就是一段程序代码的执行在单个线程中看起来是有序的。虽然这条规则中提到“书写在前面的操作先行发生于书写在后面的操作”，这个应该是程序看起来执行的顺序是按照代码顺序执行的，因为虚拟机可能会对程序代码进行指令重排序。虽然进行重排序，但是最终执行的结果是与程序顺序执行的结果一致的，它只会对不存在数据依赖性的指令进行重排序。因此，在单个线程中，程序执行看起来是有序执行的，这一点要注意理解。事实上，这个规则是用来保证程序在单线程中执行结果的正确性，但无法保证程序在多线程中执行的正确性。 - 锁定规则：一个unLock操作先行发生于后面对同一个锁额lock操作。
这个也比较容易理解，也就是说无论在单线程中还是多线程中，同一个锁如果被锁定的状态，那么必须先对锁进行了释放操作，后面才能继续进行lock操作。 - volatile变量规则：对一个变量的写操作先行发生于后面对这个变量的读操作。
如果一个线程先去写一个变量，然后一个线程去进行读取，那么写入操作肯定会先行发生于读操作 - 传递规则：如果操作A先行发生于操作B，而操作B又先行发生于操作C，则可以得出操作A先行发生于操作C。
- 线程启动规则：Thread对象的start()方法先行发生于此线程的每个一个动作。
- 线程中断规则：对线程interrupt()方法的调用先行发生于被中断线程的代码检测到中断事件的发生。
- 线程终结规则：线程中所有的操作都先行发生于线程的终止检测，我们可以通过Thread.join()方法结束、Thread.isAlive()的返回值手段检测到线程已经终止执行。
- 对象终结规则：一个对象的初始化完成先行发生于他的finalize()方法的开始。
java与线程
并发并不一定依赖于多线程。但在java里谈并发，大多数与线程脱不开关系。
线程的实现
我们知道线程是比进程更轻量级的调度执行单位。线程的引入，可以把一个进程的资源分配和执行调度分开。各个线程既可以共享进程的资源。又可以独立调度。（线程的cpu调度的基本单位）
java语言中，每个已经执行start（）且还未结束的java.lang.Thread类的实例就代表一个线程。Thread的所有关键方法都是Native的。一个Native方法往往意味着这个方法没有使用或无法使用平台无关的手段来实现。
java线程调度
线程调度值系统为线程分配处理器使用权的过程。主要调度方式有两种：
- 协同式线程调度
- 抢占式线程调度
协同式线程调度是线程的执行时间是线程本身来控制。线程把自己的工作执行完了以后主动通知系统切换到另外一个线程上。系统是多线程的最大好处是实现简单。而且由于线程要把自己的事情做完后才进行线程切换。所以切换操作对线程自己是可知的，所以线程同步也没什么问题。他的坏处也很明显。就是一个线程的执行时间不可控。甚至一个线程的编写有问题，一直执行不完，那么程序会一直阻塞在那里。
抢占式线程调度是每个线程由系统分配执行时间。线程的切换不由线程本身决定。（thread.yield（）可以让出执行时间。但是获取执行时间的话，线程本身没啥办法）
在这种调度方式下，线程的执行时间是系统可控的。也不会因为一个线程导致阻塞。java使用的线程调度方式就是抢占式线程调度。
虽然java线程的调度是系统自动完成的，但是我们还是可以“建议”系统给某个线程多或者少分配一点执行时间。这个就是设置线程的优先级。
状态转换
java语言定义了五种线程状态（我查阅了一些资料，还有说六种，七种的。然后这个书里也是6点。但是非要说是5种线程状态.估计是本书作者把两个等待算成一种了？）。在任意一个时间点，一个线程有且只能有一种状态。、 - 新建（NEW）,也叫初始状态
实现Runnable接口和继承Thread可以得到一个线程类，new一个实例出来，线程就进入了初始状态。创建后尚未启动的线程就是这种状态 - 运行(RUNNABLE)：Java线程中将就绪（ready）和运行中（running）两种状态笼统的称为“运行”。
线程对象创建后，其他线程(比如main线程）调用了该对象的start()方法。该状态的线程位于可运行线程池中，等待被线程调度选中，获取CPU的使用权，此时处于就绪状态（ready）。就绪状态的线程在获得CPU时间片后变为运行中状态（running）。也就是处于此状态的线程可能正在执行，也可能正在等待cpu给他分配时间。 - 无限期等待(WAITING)：不会被cpu分配时间。进入该状态的线程必需要等待其他线程做出一些特定动作唤醒。下面的方法会让线程进入无限期等待。
- 没有设置Timeout参数的Object.wait().
- 没有设置Timeout参数的Thread.join().
- LockSupport.park().
- 限期等待(TIMED_WAITING)：该状态不同于WAITING，它可以在指定的时间后自行返回。以下方法会进入限期等待
- Thread.sleep()
- 设置了Timeout参数的Object.wait().
- 设置了Timeout参数的Thread.join().
- LockSupport.parkNanos().
- LockSupport.parkUntil().
- 阻塞(BLOCKED)：阻塞状态是线程阻塞在进入synchronized关键字修饰的方法或代码块(获取锁)时的状态。
- 终止(TERMINATED)：表示该线程已经执行完毕。
上述五种状态的转换关系：
本章小结
主要是了解了虚拟机java内训模型的结构。讲解了原子性，可见性，有序性。又介绍了先行发生原则的规则。另外还了解了线程在java语言中是如何实现的。
好了，全文手打不易，如果稍微帮到你了，请点个喜欢点个关注支持一下呦~~~~~~~祝大家工作顺顺利利。
