内存和高速缓存
计算机需要读写与存储，而用户磁盘远远跟不上cpu读写的速度，所以设计了内存；然而随着硬件的高速发展，连内存也不上CPU的速度了，所以各cpu厂家给每个CPU加上了一个高速缓存（high speed cache memory），已解决交互速度问题；基于高速缓存的存储交互解决了CPU和内存的矛盾，却又带来了缓存一致性（cache coherency）问题，多核处理器的每个CPU都有自己的高速缓存，并且共享主存（main memory），这样多个处理器处理同一块内存区域的时候，就有可能造成缓存不一致的问题。为了解决这一问题，需要各个处理器运行时都遵循一些协议，在运行时需要将这些协议保证数据的一致性。这类协议包括MSI、MESI、MOSI、Synapse、Firely、DragonProtocol等。更多的关于缓存一致性问题，可以参考这篇文章缓存一致性入门。
如此计算机的CPU和内存，高速缓存的工作模式可以用下图表示：
jvm内存模型
java虚拟机的内存模型定义的访问操作与计算机的处理基本一致。java的多线程中每个线程有自己的工作内存，又共享jvm内存（main memory）；线程与内存区域进行交互时，把数据从主存拷贝到工作内存来进行工作。
程序计数器
程序计数器（program counter register）是一块较小的内存空间，可以看做是当前线程所执行的字节码的行号指示器，在虚拟机概念模型里，字节码解释器就是通过改变程序计数器的值来选取下一条需要执行的字节码指令。
程序计数器是线程私有的内存，因为一个处理器一个时刻只会处理一个线程中的指令（对于多核处理器来说，是其中一个核），多线程是通过线程切换来实现的，所以每个线程需要一个自己私有的程序计数器，使线程切换时能记录任务执行的位置。
java栈
java虚拟机栈（java virtual machine stacks）也是线程私有的，生命周期和线程相同。java虚拟机栈描述的是java方法执行的内存模型：每个方法被执行时都会创建一个栈帧（stack frame），用于存储局部变量表、操作栈、动态链接、方法出口等信息。方法从调用到执行完成的过程标志着栈帧从进入虚拟机栈到离开虚拟机栈的过程。
局部变量表存储了编译期间各种可知的基本数据类型，局部变量表所需的内存空间在编译期间完成分配，当进入一个方法时，这个方法需要在帧中分配多大的局部变量空间时确定的，在方法运行期间是不变的。当一个方法所需要的栈深度超过了虚拟机所允许的深度，就会报stack overflow error，当虚拟机允许动态扩展，扩展时也无法请求到足够大的内存时就会报out of memory error。
本地方法栈
与虚拟机栈类似，本地方法栈为虚拟机所用到的本地方法（native method）服务，而虚拟机栈为虚拟机执行java方法服务。本地方法栈也会抛出stack overflow error 和out of memory error。
java堆
对大多数应用来说，java堆（java heap）是java虚拟机所管理的内存中最大的一块。java堆是被所有线程共享的内存区域，在虚拟机启动时创建，用来存放对象实例和数组，几乎所有的对象实例都是在堆中分配内存。随着技术的发展，这一点也不是那么“绝对” 了。
java堆是垃圾回收管理器管理的主要区域，所以也叫做”GC堆（garbage collected heap）“，如果从内存回收的角度看，由于现在收集器基本都是采用的分代收集算法，所以Java堆中还可以细分为：新生代、老年代；再细致一点的有Eden空间、From Survivor空间、To Survivor空间等。
Young：主要是用来存放新生的对象。
Old：主要存放应用程序中生命周期长的内存对象。
Permanent：也叫方法区，是指内存的永久保存区域，主要存放Class和Meta的信息,Class在被 Load的时候被放入PermGen space区域. 它和存放Instance的Heap区域不同,GC(Garbage Collection)不会在主程序运行期对PermGen space进行清理，所以如果你的APP会LOAD很多CLASS的话,就很可能出现PermGen space错误。
关于堆的细分更多可参考java 虚拟机--新生代与老年代GC。
如果从内存分配的角度看，线程共享的Java堆中可能划分出多个线程私有的分配缓冲区（Thread Local Allocation Buffer，TLAB）。不过，无论如何划分，都与存放内容无关，无论哪个区域，存储的都仍然是对象实例，进一步划分的目的是为了更好地回收内存，或者更快地分配。
方法区
方法区（Method Area）与Java堆一样，是各个线程共享的内存区域，它用于存储已被虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码等数据。虽然Java虚拟机规范把方法区描述为堆的一个逻辑部分，但是它却有一个别名叫做Non-Heap（非堆），目的应该是与Java堆区分开来。对于习惯在HotSpot虚拟机上开发和部署程序的开发者来说，很多人愿意把方法区称为“永久代”（Permanent Generation），本质上两者并不等价，仅仅是因为HotSpot虚拟机的设计团队选择把GC分代收集扩展至方法区，或者说使用永久代来实现方法区而已。对于其他虚拟机（如BEA JRockit、IBM J9等）来说是不存在永久代的概念的。即使是HotSpot虚拟机本身，根据官方发布的路线图信息，现在也有放弃永久代并“搬家”至Native Memory来实现方法区的规划了。
Java虚拟机规范对这个区域的限制非常宽松，除了和Java堆一样不需要连续的内存和可以选择固定大小或者可扩展外，还可以选择不实现垃圾收集。相对而言，垃圾收集行为在这个区域是比较少出现的，但并非数据进入了方法区就如永久代的名字一样“永久”存在了。这个区域的内存回收目标主要是针对常量池的回收和对类型的卸载，一般来说这个区域的回收“成绩”比较难以令人满意，尤其是类型的卸载，条件相当苛刻，但是这部分区域的回收确实是有必要的。在Sun公司的BUG列表中，曾出现过的若干个严重的BUG就是由于低版本的HotSpot虚拟机对此区域未完全回收而导致内存泄漏。根据Java虚拟机规范的规定，当方法区无法满足内存分配需求时，将抛出OutOfMemoryError异常。
运行时常量池
运行时常量池（Runtime Constant Pool）是方法区的一部分。Class文件中除了有类的版本、字段、方法、接口等描述等信息外，还有一项信息是常量池（Constant Pool Table），用于存放编译期生成的各种字面量和符号引用，这部分内容将在类加载后存放到方法区的运行时常量池中。Java虚拟机对Class文件的每一部分（自然也包括常量池）的格式都有严格的规定，每一个字节用于存储哪种数据都必须符合规范上的要求，这样才会被虚拟机认可、装载和执行。但对于运行时常量池，Java虚拟机规范没有做任何细节的要求，不同的提供商实现的虚拟机可以按照自己的需要来实现这个内存区域。不过，一般来说，除了保存Class文件中描述的符号引用外，还会把翻译出来的直接引用也存储在运行时常量池中。
运行时常量池相对于Class文件常量池的另外一个重要特征是具备动态性，Java语言并不要求常量一定只能在编译期产生，也就是并非预置入Class文件中常量池的内容才能进入方法区运行时常量池，运行期间也可能将新的常量放入池中，这种特性被开发人员利用得比较多的便是String类的intern()方法。既然运行时常量池是方法区的一部分，自然会受到方法区内存的限制，当常量池无法再申请到内存时会抛出OutOfMemoryError异常。
直接内存
直接内存（Direct Memory）并不是虚拟机运行时数据区的一部分，也不是Java虚拟机规范中定义的内存区域，但是这部分内存也被频繁地使用，而且也可能导致OutOfMemoryError异常出现，所以我们放到这里一起讲解。在JDK 1.4中新加入了NIO（New Input/Output）类，引入了一种基于通道（Channel）与缓冲区（Buffer）的I/O方式，它可以使用Native函数库直接分配堆外内存，然后通过一个存储在Java堆里面的DirectByteBuffer对象作为这块内存的引用进行操作。这样能在一些场景中显著提高性能，因为避免了在Java堆和Native堆中来回复制数据。
显然，本机直接内存的分配不会受到Java堆大小的限制，但是，既然是内存，则肯定还是会受到本机总内存（包括RAM及SWAP区或者分页文件）的大小及处理器寻址空间的限制。服务器管理员配置虚拟机参数时，一般会根据实际内存设置-Xmx等参数信息，但经常会忽略掉直接内存，使得各个内存区域的总和大于物理内存限制（包括物理上的和操作系统级的限制），从而导致动态扩展时出现OutOfMemoryError异常。
逻辑内存模型我们已经看到了，那当我们建立一个对象的时候是怎么进行访问的呢？在Java语言中，对象访问是如何进行的？对象访问在Java语言中无处不在，是最普通的程序行为，但即使是最简单的访问，也会却涉及Java栈、Java堆、方法区这三个最重要内存区域之间的关联关系，如下面的这句代码：
Object obj = new Object();
假设这句代码出现在方法体中，那“Object obj”这部分的语义将会反映到Java栈的本地变量表中，作为一个reference类型数据出现。而“new Object()”这部分的语义将会反映到Java堆中，形成一块存储了Object类型所有实例数据值（Instance Data，对象中各个实例字段的数据）的结构化内存，根据具体类型以及虚拟机实现的对象内存布局（Object Memory Layout）的不同，这块内存的长度是不固定的。另外，在Java堆中还必须包含能查找到此对象类型数据（如对象类型、父类、实现的接口、方法等）的地址信息，这些类型数据则存储在方法区中。由于reference类型在Java虚拟机规范里面只规定了一个指向对象的引用，并没有定义这个引用应该通过哪种方式去定位，以及访问到Java堆中的对象的具体位置，因此不同虚拟机实现的对象访问方式会有所不同，主流的访问方式有两种：使用句柄和直接指针。
如果使用句柄访问方式，Java堆中将会划分出一块内存来作为句柄池，reference中存储的就是对象的句柄地址，而句柄中包含了对象实例数据和类型数据各自的具体地址信息，如下图所示。
这两种对象的访问方式各有优势，使用句柄访问方式的最大好处就是reference中存储的是稳定的句柄地址，在对象被移动（垃圾收集时移动对象是非常普遍的行为）时只会改变句柄中的实例数据指针，而reference本身不需要被修改。使用直接指针访问方式的最大好处就是速度更快，它节省了一次指针定位的时间开销，由于对象的访问在Java中非常频繁，因此这类开销积少成多后也是一项非常可观的。
本文参考了 深入理解JVM—JVM内存模型
