Java内存模型规范了Java虚拟机与计算机内存是如何协同工作的。
Java虚拟机是一个完整的计算机的一个模型，因此这个模型自然也包含一个内存模型——又称为Java内存模型。
java运行时内存划分
程序计数器
记录当前线程所执行的字节码行号，用于获取下一条执行的字节码。
当多线程运行时，每个线程切换后需要知道上一次所运行的状态、位置。由此也可以看出程序计数器是每个线程私有的。
虚拟机栈
虚拟机栈由一个一个的栈帧组成，栈帧是在每一个方法调用时产生的。
每一个栈帧由局部变量区、操作数栈等组成。每创建一个栈帧压栈，当一个方法执行完毕之后则出栈。
如果出现方法递归调用出现死循环的话就会造成栈帧过多，最终会抛出 StackOverflowError。
若线程执行过程中栈帧大小超出虚拟机栈限制，则会抛出 StackOverflowError。
若虚拟机栈允许动态扩展，但在尝试扩展时内存不足，或者在为一个新线程初始化新的虚拟机栈时申请不到足够的内存，则会抛出 OutOfMemoryError。
这块内存区域也是线程私有的。
java堆
Java 堆是整个虚拟机所管理的最大内存区域，所有的对象创建都是在这个区域进行内存分配。
可利用参数 -Xms -Xmx 进行堆内存控制。
这块区域也是垃圾回收器重点管理的区域，由于大多数垃圾回收器都采用分代回收算法，所有堆内存也分为 新生代、老年代，可以方便垃圾的准确回收。
这块内存属于线程共享区域。
方法区（JDK1.7）
方法区主要用于存放已经被虚拟机加载的类信息，如常量，静态变量。 这块区域也被称为永久代。
可利用参数 -XX:PermSize -XX:MaxPermSize 控制初始化方法区和最大方法区大小。
元数据区（JDK1.8）
在 JDK1.8 中已经移除了方法区（永久代），并使用了一个元数据区域进行代替（Metaspace）。
默认情况下元数据区域会根据使用情况动态调整，避免了在 1.7 中由于加载类过多从而出现 java.lang.OutOfMemoryError: PermGen。
但也不能无限扩展，因此可以使用 -XX:MaxMetaspaceSize来控制最大内存。
运行时常量池
运行时常量池是方法区的一部分，其中存放了一些符号引用。当 new 一个对象时，会检查这个区域是否有这个符号的引用。
直接内存
直接内存又称为 Direct Memory（堆外内存），它并不是由 JVM 虚拟机所管理的一块内存区域。
有使用过 Netty 的朋友应该对这块并内存不陌生，在 Netty 中所有的 IO（nio） 操作都会通过 Native 函数直接分配堆外内存。
它是通过在堆内存中的 DirectByteBuffer 对象操作的堆外内存，避免了堆内存和堆外内存来回复制交换复制，这样的高效操作也称为零拷贝。
既然是内存，那也得是可以被回收的。但由于堆外内存不直接受 JVM 管理，所以常规 GC 操作并不能回收堆外内存。它是借助于老年代产生的 fullGC 顺便进行回收。同时也可以显式调用 System.gc() 方法进行回收（前提是没有使用 -XX:+DisableExplicitGC 参数来禁止该方法）。
值得注意的是：由于堆外内存也是内存，是由操作系统管理。如果应用有使用堆外内存则需要平衡虚拟机的堆内存和堆外内存的使用占比。避免出现堆外内存溢出。
常用参数
通过上图可以直观的查看各个区域的参数设置。
常见的如下：
- -Xms64m 最小堆内存 64m.
- -Xmx128m 最大堆内存 128m.
- -XX:NewSize=30m 新生代初始化大小为30m.
- -XX:MaxNewSize=40m 新生代最大大小为40m.
- -Xss=256k 线程栈大小。
- -XX:+PrintHeapAtGC 当发生 GC 时打印内存布局。
- -XX:+HeapDumpOnOutOfMemoryError 发送内存溢出时 dump 内存。
新生代和老年代的默认比例为 1:2，也就是说新生代占用 1/3的堆内存，而老年代占用 2/3 的堆内存。
可以通过参数 -XX:NewRatio=2 来设置老年代/新生代的比例。
硬件内存架构
理解硬件内存模型架构以及Java内存模型如何与它协同工作是非常重要的。
下面是现代计算机硬件架构的简单图示：
CPU
一个现代计算机通常有两个或者多个CPU。
每个CPU在某一时刻运行一个线程是没有问题的。这意味着，如果你的Java程序是多线程的，在你的Java程序中每个CPU上一个线程可能同时（并发）执行。
寄存器
每个CPU都包含一系列的寄存器，它们是CPU内内存的基础。CPU在寄存器上执行操作的速度远大于在主存上执行的速度。这是因为CPU访问寄存器的速度远大于主存。
CPU缓存层
每个CPU可能还有CPU缓存层。实际上，绝大多数的现代CPU都有一定大小的缓存层。CPU访问缓存层的速度快于访问主存的速度，但通常比访问内部寄存器的速度还要慢一点。
主存
一个计算机还包含一个主存。所有的CPU都可以访问主存。主存通常比CPU中的缓存大得多。
数据交互
通常情况下，当一个CPU需要读取主存时，它会将主存的部分读到CPU缓存中。它甚至可能将缓存中的部分内容读到它的内部寄存器中，然后在寄存器中执行操作。当CPU需要将结果写回到主存中去时，它会将内部寄存器的值刷新到缓存中，然后在某个时间点将值刷新回主存。
当CPU需要在缓存层存放一些东西的时候，存放在缓存中的内容通常会被刷新回主存。CPU缓存可以在某一时刻将数据局部写到它的内存中，和在某一时刻局部刷新它的内存。它不会再某一时刻读/写整个缓存。通常，在一个被称作“cache lines”的更小的内存块中缓存被更新。一个或者多个缓存行可能被读到缓存，一个或者多个缓存行可能再被刷新回主存。
Java内存模型和硬件内存架构之间的桥接
Java内存模型与硬件内存架构之间存在差异。硬件内存架构没有区分线程栈和堆。
对于硬件，所有的线程栈和堆都分布在主内中。部分线程栈和堆可能有时候会出现在CPU缓存中和CPU内部的寄存器中。
如下图所示：
当对象和变量被存放在计算机中各种不同的内存区域中时，就可能会出现一些具体的问题。
可见性问题
如果两个或者更多的线程在没有正确的使用volatile声明或者同步的情况下共享一个对象，一个线程更新这个共享对象可能对其它线程来说是不接见的。
想象一下，共享对象被初始化在主存中。跑在CPU上的一个线程将这个共享对象读到CPU缓存中。然后修改了这个对象。只要CPU缓存没有被刷新会主存，对象修改后的版本对跑在其它CPU上的线程都是不可见的。这种方式可能导致每个线程拥有这个共享对象的私有拷贝，每个拷贝停留在不同的CPU缓存中。
下图示意了这种情形。跑在左边CPU的线程拷贝这个共享对象到它的CPU缓存中，然后将count变量的值修改为2。这个修改对跑在右边CPU上的其它线程是不可见的，因为修改后的count的值还没有被刷新回主存中去。
解决这个问题你可以使用Java中的volatile关键字。volatile关键字可以保证直接从主存中读取一个变量，如果这个变量被修改后，总是会被写回到主存中去。
并发竞争问题
想象一下，如果线程A读一个共享对象的变量count到它的CPU缓存中。再想象一下，线程B也做了同样的事情，但是往一个不同的CPU缓存中。现在线程A将count加1，线程B也做了同样的事情。现在count已经被增在了两个，每个CPU缓存中一次。
如果这些增加操作被顺序的执行，变量count应该被增加两次，然后原值+2被写回到主存中去。
然而，两次增加都是在没有适当的同步下并发执行的。无论是线程A还是线程B将count修改后的版本写回到主存中取，修改后的值仅会被原值大1，尽管增加了两次。
下图演示了上面描述的情况：
解决这个问题可以使用Java同步块。
一个同步块可以保证在同一时刻仅有一个线程可以进入代码的临界区。同步块还可以保证代码块中所有被访问的变量将会从主存中读入，当线程退出同步代码块时，所有被更新的变量都会被刷新回主存中去，不管这个变量是否被声明为volatile。