java虚拟机运行时，管理的内存包含5个数据区域：

1.方法区；2.堆；3.java虚拟机栈；4.本地方法栈；5.程序计数器 

程序计数器(Program Counter Register)：当前线程所执行的字节码的行号指示器, 线程单独拥有,标识当前线程的运行轨迹以及将要运行的代码跳转逻辑; 记录的是正在执行的虚拟机字节码指令的地址, 对于java方法这个地址值才可以正确表示，而native方法，对应的地址值在这里是无法保存的; 唯一一个在Java虚拟机规范中没有规定任何OutOfMemoryError情况的区域

java虚拟机栈(Java Virtual Machine Stacks): 依然是线程私有；

1. 局部变量表所需的内存空间在编译期间完成分配,当进入一个方法时,这个方法需要在帧中分配多大的局部变量空间是完全确定的,在方法运行期间不会改变局部变量表的大小; 
2. 这个区域规定了两种异常状况:如果线程请求的栈深度大于虚拟机所允许的深度,将抛出StackOverflowError异常;如果虚拟机栈可以动态扩展(当前大部分的Java虚拟机都可动态扩展,只不过Java虚拟机规范中也允许固定长度的虚拟机栈),如果扩展时无法申请到足够的内存,就会抛出OutOfMemoryError异常；
3. 虚拟机栈中保存的东西为栈帧，栈帧包含存储局部变量表、操作数栈、动态链接、方法出口等信息，每一个方法从调用直至执行完成的过程,就对应着一个栈帧在虚拟机栈中入栈到出栈的过程，我认为可以打印java的函数调用栈，就是因为虚拟机栈对于每一次函数调用都一个当前函数的栈帧入栈，函数返回后，对应的栈帧才会出栈。
4. 局部变量表存放了编译期可知的各种基本数据类型(boolean、byte、char、short、int、float、long、double)、对象引用(reference类型,它不等同于对象本身,可能是一个指向对象起始地址的引用指针,也可能是指向一个代表对象的句柄或其他与此对象相关的位置)和returnAddress类型(指向了一条字节码指令的地址)。

本地方法栈(Native Method Stack):

1. 为虚拟机使用到的Native方法服务;虚拟机栈一样,本地方法栈区域也会抛出StackOverflowError和OutOfMemoryError异常

Java堆(Java Heap):

1. 被所有线程共享的一块内存区域,此内存区域的唯一目的就是存放对象实例,几乎所有的对象实例都在这里分配内存. 所有的对象实例以及数组都要在堆上分配 ,但是随着JIT编译器的发展与逃逸分析技术逐渐成熟,栈上分配、标量替换 优化技术将会导致一些微妙的变化发生,所有的对象都分配在堆上也渐渐变得不是那么“绝对”了。
2. Java堆是垃圾收集器管理的主要区域
3. 如果在堆中没有内存完成实例分配,并且堆也无法再扩展时,将会抛出OutOfMemoryError异常

方法区(Method Area)：

1. 各个线程共享的内存区域,用于存储已被虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码等数据；虽然Java虚拟机规范把方法区描述为堆的一个逻辑部分,但是它却有一个别名叫做Non-Heap(非堆),目的应该是与Java堆区分开来
2. 这区域的内存回收目标主要是针对常量池的回收和对类型的卸载,一般来说,这个区域的回收“成绩”比较难以令人满意,尤其是类型的卸载,条件相当苛刻,但是这部分区域的回收确实是必要的
3. 运行时常量池(Runtime Constant Pool)是方法区的一部分:
   运行时常量池相对于Class文件常量池的另外一个重要特征是具备动态性,Java语言并不要求常量一定只有编译期才能产生,也就是并非预置入Class文件中常量池的内容才能进入方法区运行时常量池,运行期间也可能将新的常量放入池中
   符号引用和直接引用？？？？？？？？

直接内存(Direct Memory):

1. 不是虚拟机运行时数据区的一部分,也不是Java虚拟机规范中定义的内存区域
2. 特点：在JDK 1.4中新加入了NIO(New Input/Output)类,引入了一种基于通道(Channel)与缓冲区(Buffer)的I/O方式,它可以使用Native函数库直接分配堆外内存,然后通过一个存储在Java堆中的DirectByteBuffer对象作为这块内存的引用进行操作。这样能在一些场景中显著提高性能,因为避免了在Java堆和Native堆中来回复制数据。

HotSpot虚拟机中对象的创建和对象的内存布局以及访问方式：

对象的创建：虚拟机遇到一条new指令时，首先根据符号引用找对对应的类（通过类加载检查，如果对应类已经加载，那么就可以确认类的大小，如果没有加载，那么就需要加载对应类;对象所需内存的大小在类加载完成后便可完全确定）；然后根据找到的类分配一块对应大小的内存，完成对象创建。

创建对象时，分配内存的方法：指针碰撞和空闲列表

1. 假设Java堆中内存是绝对规整的,所有用过的内存都放在一边,空闲的内存放在另一边,中间放着一个指针作为分界点的指示器,那所分配内存就仅仅是把那个指针向空闲空间那边挪动一段与对象大小相等的距离,这种分配方式称为“指针碰撞”(Bump the Pointer)
2. 如果Java堆中的内存并不是规整的,已使用的内存和空闲的内存相互交错,那就没有办法简单地进行指针碰撞了,虚拟机就必须维护一个列表,记录上哪些内存块是可用的,在分配的时候从列表中找到一块足够大的空间划分给对象实例,并更新列表上的记录,这种分配方式称为“空闲列表”(Free List)

选择哪种分配方式由Java堆是否规整决定,而Java堆是否规整又由所采用的垃圾收集器是否带有压缩整理功能决定。因此,在使用Serial、ParNew等带Compact过程的收集器时,系统采用的分配算法是指针碰撞,而使用CMS这种基于Mark-Sweep算法的收集器时,通常采用空闲列表。

由于java堆是线程共享的，因此除如何划分可用空间之外，还要考虑多线程下内存分配的同步问题，（在并发情况下也并不是线程安全的,可能出现正在给对象A分配内存,指针还没来得及修改,对象B又同时使用了原来的指针来分配内存的情况）,

解决这个问题的2个方法：

1. 一种是对分配内存空间的动作进行同步处理——实际上虚拟机采用CAS配上失败重试的方式保证更新操作的原子性;
2. 一种是把内存分配的动作按照线程划分在不同的空间之中进行,即每个线程在Java堆中预先分配一小块内存,称为本地线程分配缓冲(Thread Local Allocation Buffer,TLAB)。哪个线程要分配内存,就在哪个线程的TLAB上分配,只有TLAB用完并分配新的TLAB时,才需要同步锁定。虚拟机是否使用TLAB,可以通过-XX:+/-UseTLAB参数来设定。

内存分配到后，虚拟机会首先将分配的内存初始化为0，然后对对象进行必要的设置,例如这个对象是哪个类的实例、如何才能找到类的元数据信息、对象的哈希码、对象的GC分代年龄等信息，最后执行init方法，完成对象创建。

java对象的内存分布：对象头(Header)、实例数据(Instance Data)和对齐填充(Padding)

1. 对象头：第一部分用于存储对象自身的运行时数据,如哈希码(HashCode)、GC分代年龄、锁状态标志、线程持有的锁、偏向线程ID、偏向时间戳等,这部分数据的长度在32位和64位的虚拟机(未开启压缩指针)中分别为32bit和64bit,官方称它为“Mark Word”；对象头的另外一部分是类型指针,即对象指向它的类元数据的指针,虚拟机通过这个指针来确定这个对象是哪个类的实例
2. 实例数据部分是对象真正存储的有效信息,也是在程序代码中所定义的各种类型的字段内容。无论是从父类继承下来的,还是在子类中定义的,都需要记录起来。这部分的存储顺序会受到虚拟机分配策略参数(FieldsAllocationStyle)和字段在Java源码中定义顺序的影响。HotSpot虚拟机默认的分配策略为longs/doubles、ints、shorts/chars、bytes/booleans、oops(Ordinary Object Pointers),从分配策略中可以看出,相同宽度的字段总是被分配到一起。在满足这个前提条件的情况下,在父类中定义的变量会出现在子类之前。如果CompactFields参数值为true(默认为true),那么子类之中较窄的变量也可能会插入    到父类变量的空隙之中。
3. 对象的大小必须是8字节的整数倍

对象的访问定位：

1. 使用句柄：便于维护，维护句柄池中的地址即可
2. 直接指针:直接就是高效