系列文章
Java 内存模型
Android 系统内存管理机制
Android 性能优化（三）之内存管理
Android 性能优化（四）之内存优化实战
如果本文阐述不太明白，可在文章末尾查看参考资料
JVM - Java Virtual Machine，Java虚拟机
JMM - Java Memory Model，Java内存模型
捋一捋，咱们要讨论的是个角度的JMM？
- 涉及 CPU、寄存器、高速缓存、内存 的计算机实际执行的内存模型，姑且叫 动态的内存模型。
- 仅仅是JVM对内存的物理划分模型，包括程序计数器、线程栈/VM虚拟机栈（线程私有）、本地方法栈、堆（线程共享）、方法区、产量池等，姑且叫 静态的内存模型。
上面是以两个不同的维度来理解JMM。
认识 Java 线程安全，必须了解两个主要的点：
- Java的内存模型
- Java的线程同步机制，很大程度上都是基于内存模型而设定的。
关键字
语言级的内存模型，硬件级的内存模型，JSR-133，JMM抽象模型，并发，多线程，线程安全，原子性，有序性，可见性，数据依赖，重排序（编译器，处理器指令级，处理器系统缓存），内存屏障，happens-before语义，as-if-serial语义，数据竞争，顺序一致性，语法同步原语（lock / volatile / final），临界区，锁竞争，就绪队列，阻塞队列
看着很多，混个眼熟就行
其他随意补充：
transient 短暂的，不被序列化
volatile 不稳定的，保证内存可见性
知识点补充
可选择性忽略
- 进程和线程的区别
- 现在的计算机，cpu在计算的时候，并不总是从内存读取数据，它的数据读取顺序优先级 是：寄存器－高速缓存－内存。
- 线程耗费的是CPU，线程计算的时候，原始的数据来自内存，在计算过程中，有些数据可能被频繁读取，这些数据被存储在寄存器 和高速缓存中，当线程计算完后，这些缓存的数据在适当的时候应该写回内存。当个多个线程同时读写某个内存数据时，就会产生多线程并发问题，涉及到三个特 性：原子性，有序性，可见性。
- JVM是一个虚拟的计算机，它也会面临多线程并发问题，java程序运行在java虚拟机平台上，java程序员不可能直接去控制底层线程对寄存器高速缓存内存之间的同 步，那么java从语法层面，应该给开发人员提供一种解决方案，这个方案就是诸如 synchronized, volatile,锁机制（如同步块，就绪队 列，阻塞队列）等等。这些方案只是语法层面的，但我们要从本质上去理解它，不能仅仅知道一个 synchronized 可以保证同步就完了。
- Java 程序执行的过程：Java源程序 *.java -> Java编译器-> 字节码文件 *.class -> Java解释器 -> 机器指令运行 -> 内存 -> 总线 -> 高速缓存 -> 寄存器 -> CPU处理
相关图片
先抛出来几张图随意感受一下
注意1：这张图是抽象示意图
注意2：线程的“工作内存”或“本地内存”或“working memory”，是一个抽象的概念，本质是 CPU的寄存器和高速缓存的抽象描述，由于数据不同步导致的一种线程拥有工作内存的概念，实际上不会分配工作内存的空间。
堆内存线程共享，栈不共享不存在可见性问题
JMM到底是什么？
Java 线程之间的通信由 Java 内存模型（本文简称为 JMM）控制，JMM 决定一个线程对共享变量的写入何时对另一个线程可见。
从抽象的角度来看，JMM 定义了线程和主内存之间的抽象关系：线程之间的共享变量存储在主内存（main memory）中，每个线程都有一个私有的本地内存（local memory），本地内存中存储了该线程以读 / 写共享变量的副本。
本地内存是 JMM 的一个抽象概念，并不真实存在。它涵盖了缓存，写缓冲区，寄存器以及其他的硬件和编译器优化。
屏蔽了各种硬件和操作系统的内存访问差异，以实现让Java程序在各种平台下能达到一致的内存访问效果。
对Java开发人员来说，抽象了工作内存的概念，并提供了保证线程安全的同步原语（lock/volatile/final）；
浅谈Java内存模型
并发编程模型有 共享内存模型 和消息传递模型两种。JVM采用共享内存模型。
不同的平台，内存模型是不一样的，但JVM的内存模型规范是统一的。
线程安全：Java的多线程并发最终都会反应在Java的内存模型上，而JMM 就要控制多个线程对多个资源的有序访问或修改。
Java的内存模型要解决的两个问题：可见性和有序性（包括原子性）。
JVM定义了自己的内存模型，屏蔽了底层平台内存管理细节，对于Java开发人员，要清楚在 JVM 内存模型的基础上，解决多线程的可见性和有序性。
可见性和有序性
JVM规范定义了线程对主存的操作指 令：read，load，use，assign(分配指定)，store，write。
何为可见性？
多个线程之间是不能互相传递数据通信的，他们的沟通只能通过共享变量来进行。（共享内存模型）
Java 内存模型（JMM）规定了 JVM 有主内存，主内存是由多个线程共享的。当new一个对象的时候，也是被分配在主内存中，每个线程都有自己的工作内存，工作内存存储了主存的某些对象的副本，当然线程的工作内存大小是有限制 的。当线程操作某个对象时，执行顺序如下：
- 从主存复制变量到当前工作内存 (read and load)
- 执行代码，改变共享变量值 (use and assign)
- 用工作内存数据刷新主存相关内容 (store and write)
当一个共享变量在多个线程的工作内存中都有副本时，如果一个线程修改了这个共享 变量，那么其他线程应该能够看到这个被修改后的值，这就是多线程的可见性问题。
何为有序性？
线程在引用变量时不能直接从主内存中引用,如果线程工作内存中没有该变量,则会从主内存中拷贝一个副本到工作内存中,这个过程为read-load,完 成后线程会引用该副本。当同一线程再度引用该字段时,有可能重新从主存中获取变量副本(read-load-use),也有可能直接引用原来的副本 (use),也就是说 read,load,use顺序可以由JVM实现系统决定
线程不能直接为主存中中字段赋值，它会将值指定给工作内存中的变量副本(assign),完成后这个变量副本会同步到主存储区(store- write)，至于何时同步过去，根据JVM实现系统决定
有该字段,则会从主内存中将该字段赋值到工作内存中,这个过程为read-load,完成后线程会引用该变量副本
当同一线程多次重复对字段赋值时,线程有可能只对工作内存中的副本进行赋值,只到最后一次赋值后才同步到主存储区，所以assign,store,weite顺序可以由JVM实现系统决定。
以下说明沿袭“working memory”的说法，不牵扯到太多底层细节，从语法层面理解java的线程同步，知道各个关键字的使用场景
语义保证线程安全
synchronized 解决多线程的执行有序性和内存可见性问题，保证同步块是互斥的。
volatile 只解决多线程的内存可见性问题（轻量级的同步，不保证执行有序性）。
final 不可变，只能在构造方法中赋值一次。
JSR-133 之后对 volatile和 final 增强了语义，保证内存可见性
synchronized
synchronized 标示了临界区或互斥区
方法锁
public synchronized void add(int num)，锁就是这个方法所在的对象
public static synchronized void add(int num)，锁就是这个方法所在的class
理论上，每个对象都可以做为锁，但一个对象做为锁时，应该被多个线程共享，这样才显得有意义，在并发环境下，一个没有共享的对象作为锁是没有意义的。
每个锁对象都有两个队列，一个是就绪队列，一个是阻塞队列。
就绪队列存储了 将要 获得锁的线程，阻塞队列存储了被阻塞的线程（wait），当一个被线程被唤醒 (notify)后，才会进入到就绪队列，等待cpu的调度。
一个线程执行临界区代码过程如下：
- 获得同步锁
- 清空工作内存
- 从主存拷贝变量副本到工作内存
- 对这些变量计算
- 将变量从工作内存写回到主存
- 释放锁
可见，synchronized既保证了多线程的并发有序性，又保证了多线程的内存可见性。
volatile
轻量级的同步，只能保证多线程的内存可见性，不能保证多线 程的执行有序性。
任何被 volatile 修饰的变量，都不拷贝副本到工作内存，任何 修改都及时写在主存。因此对于 volatile 修饰的变量的修改，所有线程马上就能看到，但是volatile不能保证对变量的修改是有序的。
要使 volatile 变量提供理想的线程安全,必须同时满足下面两个条件:
1)对 变量的写操作不依赖于当前值。
2)该变量没有包含在具有其他变量的不变式中
适合场景：直接进行赋值操作，开销非常小
参考资料
JSR-133 官方文档
线程安全总结（一）
线程安全总结（二）
深入理解java内存模型系列文章
深入理解Java内存模型
CPU高速缓存行与内存关系 及并发MESI 协议
请问CPU，内核，寄存器，缓存，RAM，ROM的作用和他们之间的联系？
JVM 答疑解惑
