jvm运行时数据区域

程序计数器

  一块比较小的内存空间,可以看做当前线程所执行的字节码的行号计数器.在jvm模型中,字节码解释器工作时就是通过改变这个计数器的值来选取下一条所需要执行的字节码指令,也是程序控制流的指示器,分支 循环 跳转 异常处理 线程恢复等基础功能都需要依赖这个计数器来完成.
  由于虚拟机的多线程是通过线程轮流切换,分配处理器执行时间的方式来实现的,在任何一个确定的时刻,一个处理器都只会执行一条线程中的指令.因此,为了线程切换后能恢复到正确的执行位置,每条线程都需要一个独立的程序计数器.并且计数器之间互不影响,独立存储,是内存区域中"线程私有"的内存.

java虚拟机栈
  java虚拟机栈也是线程私有的,他的生命周期也和线程相同.虚拟机栈描述的是java方法执行的线程内存模型,每个方法被执行的时候,java虚拟机都会同步创建一个栈帧用于存储局部变量表,操作数栈（用于计算的临时数据存储区）,动态链接,方法出口等信息.每一个方法被调用直至执行完毕的过程,就对应着一个栈帧在虚拟机中从入栈到出栈的过程.

动态链接:
   动态链接的优点显而易见，就是即使需要每个程序都依赖同一个库，但是该库不会像静态链接那样在内存中存在多分，副本，而是这多个程序在执行时共享同一份副本；另一个优点是，更新也比较方便，更新时只需要替换原来的目标文件，而无需将所有的程序再重新链接一遍。当程序下一次运行时，新版本的目标文件会被自动加载到内存并且链接起来，程序就完成了升级的目标。但是动态链接也是有缺点的，因为把链接推迟到了程序运行时，所以每次执行程序都需要进行链接，所以性能会有一定损失。

  java内存区域笼统的划分为堆内存和栈内存,这种划分方式直接继承自传统的c c++程序的内存布局结构,在java语言中就显得有些粗糙了,实际的内存区域划分要比这更复杂.

局部变量表
  存放了编译器可知的各种java虚拟机基本数据类型(boolean,byte,char,short,int,float,long,double)
对象引用
  (reference类型,它并不等于对象本身,可能是一个指向对象起始地址的引用指针,也可能是指向一个代表对象的句柄或者其他与此对象相关的位置) 和 returnAddress类型
这些数据类型在局部变量表中的存储空间以及局部变量槽(slot)来表示,局部变量表所需的内存空间在编译期间完成分配,当进入一个方法是,这个方法需要在帧栈中分配多大的局部变量空间是完全确定的,在方法运行期间不会改变局部变量表的大小
本地方法栈
  本地方法栈与虚拟机栈所发挥的作用是非常相似的,其区别只是虚拟机栈为虚拟机执行java方法服务,而本地方法栈则为虚拟机使用到的本地(Native)方法服务的
Java堆
  对于Java应用程序来说,Java堆是虚拟机所管理的内存中最大的一块.Java堆是被所有线程共享的一块内存区域,在虚拟机启动时创建,此内存区域的唯一目的就是存放对象实例,几乎所有的对象实例都在这里分配内存,但是逃逸技术的日渐强大,栈上分配 标量替换优化手段会导致对象实例都分配在堆上也渐渐变得不是那么绝对了.
  如果从内存分配的角度看,所有线程共享的java堆可以划分出多个线程私有的分配缓存区(ThreadLocal),以提升对象分配时的效率,不过无论从什么角度,无论如何划分,都不会改变Java堆中存储内容的共性,无论是哪个区域,存储的都只能是对象的实例,将Java堆细分的目的只是为了更好地回收内存,或者更快的分配内存.
  Java堆可以处于物理上不连续的内存空间中， 但在逻辑上它应该被视为连续的,Java堆可以被实现成固定大小的,也可以是可扩展的,不过当前主流的Java虚拟机都是按照可扩展来实现的.如果在堆中没有内存完成实例分配,并且堆无法再扩展时,虚拟机将会抛出OutOfMemoryError异常.
方法区
  方法区和堆一样,是各个线程共享的内存区域,他用于存储已被虚拟机加载的类型信息,常量,静态变量,即时编译器编译后的代码缓存等数据 ,Java堆可以处于物理上不连续的内存空间中， 但在逻辑上它应该被视为连续的
  说到方法区， 不得不提一下“永久代”这个概念， 尤其是在JDK 8以前， 许多Java程序员都习惯在HotSpot虚拟机上开发、 部署程序， 很多人都更愿意把方法区称呼为“永久代”（PermanentGeneration） ， 或将两者混为一谈。 当年使用永久代来实现方法区的决定并不是一个好主意， 这种设计导致了Java应用更容易遇到内存溢出的问题.
  在JDK 6的时候HotSpot开发团队就有放弃永久代， 逐步改为采用本地内存（Native Memory） 来实现方法区的计划了[1]， 到了JDK 7的HotSpot， 已经把原本放在永久代的字符串常量池、 静态变量等移出， 而到了JDK 8， 终于完全废弃了永久代的概念， 改用与JRockit、 J9一样在本地内存中实现的元空间（Metaspace） 来代替， 把JDK 7中永久代还剩余的内容（主要是类型信息） 全部移到元空间中。
运行时常量池
  是方法区的一部分.Class文件中除了有类的版本 字段 方法 接口等描述信息外,还有一项信息是常量池表,用于存放编译期生成的各种字面量与符号引用,这部分内容将在类加载后存放到方法区的运行时常量池中,不同提供商实现的虚拟机可以按照自己的需要来实现这个内存区域， 不过一般来说， 除了保存Class文件中描述的符号引用外， 还会把由符号引用翻译出来的直接引用也存储在运行时常量池中
  运行时常量池相对于Class文件常量池的另外一个重要特征是具备动态性， Java语言并不要求常量一定只有编译期才能产生， 也就是说， 并非预置入Class文件中常量池的内容才能进入方法区运行时常量池， 运行期间也可以将新的常量放入池中， 这种特性被开发人员利用得比较多的便是String类的intern()方法。
直接内存
  并不是虚拟机运行时数据的一部分,也不是虚拟机规范中定义的内存区域,但是这部分内存也被频繁的使用,而且也可能导致OutOfMemoryError异常出现
  在JDK 1.4中新加入了NIO（New Input/Output） 类， 引入了一种基于通道（Channel） 与缓冲区（Buffer） 的I/O方式， 它可以使用Native函数库直接分配堆外内存,通过一个存储在Java堆里面的DirectByteBuffer对象作为这块内存的引用进行操作,在一些场景中显著提高性能， 因为避免了在Java堆和Native堆中来回复制数据.
本机直接内存的分配不会受到Java堆大小的限制,还是会受到本机总内存大小以及处理器寻址空间的限制,从而导致动态扩展时出现OutOfMemoryError异常。