第二部分、内存管理机制
1、运行时数据区
2、内存溢出异常
3、垃圾收集器
4、内存分配策略
5、内存调优分析
Java的内存管理就是对象的分配和释放问题。
分配 ：内存的分配是由程序完成的，程序员需要通过关键字new (或者反射newinstance)为每个对象申请内存空间 (基本类型除外)，所有的对象都在堆 (Heap)中分配空间。
释放 ：对象的释放是由垃圾回收机制决定和执行的，这样做确实简化了程序员的工作。但同时加重了JVM的工作。因为，GC为了能够正确释放对象，GC必须监控每一个对象的运行状态，包括对象的申请、引用、被引用、赋值等，GC都需要进行监控。
JVM主要包含三大核心部分：运行时数据区，类加载器和执行引擎。
根据《Java虚拟机规范（第2版）》的规定，Java虚拟机所管理的内存将会包括以下几个运行时数据区域：
1、程序计数器（Program Counter Register ）
程序计数器是一块较小的线程私有内存，它的作用是记录 当前线程所执行的字节码行数。解释器java.exe通过改变计数器值来选取下一条字节码指令；
java多线程是通过线程切换来实现几个线程同时进行，但一个处理器（对于多核处理器来说是一个内核）只会执行一条线程，为了线程切换后能恢复到正确的执行位置，每条线程都需要有一个独立的程序计数器；
如果线程执行的是一个Java方法，计数器记录的是字节码语句的地址；如果执行的是Natvie方法，计数器值自设为空（Undefined）。
2、Java虚拟机栈（Java Virtual Machine Stacks）
虚拟机栈也是线程私有的，虚拟机栈描述的是Java方法执行时的内存模型：每个方法被执行时会创建一个栈帧（StackFrame）用于存储局部变量表、操作数栈、动态链接、方法出口(见16章，字节码执行引擎)等信息。一个方法被调用到完成，就对应着一个栈帧 在虚拟机栈中 入栈和出栈。
局部变量表存放了编译期可知的各种基本数据类型（boolean、byte、char、short、int、float、long、double）、reference类型（指针或句柄）和returnAddress类型。局部变量表所需的内存空间在编译期间完成分配，当进入一个方法时，这个方法需要在帧中分配多大的局部变量空间是完全确定的，在方法运行期间不会改变局部变量表的大小。
局部变量表(参数和局部变量)是线程私有的；
虚拟机栈会出现的两种异常：线程请求深度大于允许深度，将抛出StackOverflowError异常；如果虚拟机栈支持动态扩展(Groovy)当扩展时无法申请到足够的内存时会抛出OutOfMemoryError异常。
3、本地方法栈（Native Method Stacks）
本地方法栈同样也是线程私有的，与虚拟机栈作用是相似，区别是本地方法栈只为Native方法服务。虚拟机规范中对本地方法栈强制规定，虚拟机可以自由实现它。甚至有的虚拟机（HotSpot虚拟机）直接就把本地方法栈和虚拟机栈合二为一，本地方法栈区域也会抛出StackOverflowError和OutOfMemoryError异常。
4、Java堆（JavaHeap）
堆是占jvm内存最大的一块，Java堆是所有线程共享的一块内存，在虚拟机启动时创建。该内存的唯一目的就是存放对象实例，所有的对象实例以及数组都要在堆上分配，但是随着JIT编译器的发展与逃逸分析技术的逐渐成熟，栈上分配、标量替换优化技术将会导致一些微妙的变化发生，所有的对象都分配在堆上也渐渐变得不是那么“绝对”了。
堆是垃圾收集器的主要工作区域，也被称做“GC堆”（Garbage Collected Heap）。如果从内存回收的角度看，现在收集器基本采用分代收集算法，所以Java堆可以细分为：新生代和老年代；再细致一点的有Eden空间、FromSurvivor空间、ToSurvivor空间等。如果从内存分配的角度看，Java堆可以分线程私有缓冲区（ThreadLocalAllocationBuffer，TLAB）。
根据Java虚拟机规范的规定，Java堆可以划分在物理上不连续的内存空间中，只要逻辑上是连续的即可，就像磁盘空间一样。在实现时，heap即可以是固定大小的，也可以是可扩展的，当前主流的虚拟机都是可扩展的（通过-Xmx和-Xms控制）。如果在堆中没有内存完成实例分配，且也无法再扩展时，将会抛出OutOfMemoryError异常。
5、方法区（Method Area）
方法区也是所有线程共享内存，它用于存储(已被)虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码等数据。虽然Java虚拟机规范把方法区描述为堆的一个逻辑部分，但是它却有一个别名叫做Non-Heap（非堆），目的应该是与Java堆区分开来。
在HotSpot虚拟机上习惯称为“永久代”（Permanent Generation），本质上两者并不等价，仅仅是因为HotSpot虚拟机的设计团队选择把GC分代收集扩展至方法区，或者说使用永久代来实现方法区而已。对于其他虚拟机（如BEAJRockit、IBMJ9等）来说是不存在永久代的概念的。即使是HotSpot虚拟机本身，根据官方发布的路线图信息，现在也有放弃永久代并“搬家”至NativeMemory来实现方法区的规划了。当方法区无法满足内存分配需求时，将抛出OutOfMemoryError异常。
#方法编译后存放位置？在方法区，线程共享，执行时在jvm栈。
6、运行时常量池(Runtime Constant Pool)是方法区的一部分
存放方法执行时的符号引用(不是直接引用，在字节码执行引擎时转换为直接引用，一般编译时生成,如果支持动态扩展，在执行引擎时也可以生成符号引用；
字节码常量池是静态的，运行时常量池可能是动态的，但他们的初始是相同的；
7、直接内存(Direct Memory)
直接内存不是jvm管理的内存，是java NIO使用Native函数库直接分配堆外内存，然后通过一个存储在Java堆里面的DirectByteBuffer对象作为这块内存的引用进行操作。避免在Java堆和Native堆中来回复制数据，本机直接内存的分配不会受到Java堆大小的限制，但是，既然是内存，则肯定还是会受到本机总内存（包括RAM及SWAP区或者分页文件）的大小及处理器寻址空间的限制。服务器管理员配置虚拟机参数时，一般会根据实际内存设置-Xmx等参数信息，但经常会忽略掉直接内存，使得各个内存区域的总和大于物理内存限制（包括物理上的和操作系统级的限制），从而导致动态扩展时出现OutOfMemoryError异常。
$对象的创建、布局、访问：
#对象的创建(详见类加载机制)：
创建对象通常是一个new关键字生成，在jvm中，对象创建是怎样实现的呢？
对象占用内存大小 是在编译后确定的还是在类加载完后确定的？
jvm遇到一条new指令时(没有被初始化的情况)，首先去通过这个指令的参数 在运行时常量池中找到这个类的符号引用，再执行类加载(加载、验证、准备、解析、初始化)；执行类加载就会为新生的对象实例分配堆内存，对象所需要的内存大小在类加载完后就完全确定。
如果内存是规整(将空闲和使用中的内存绝对分开，中间位置为临界指针)，使用时向空闲区移动，如果不是规整的jvm有一个空闲列表，来记录哪块内存是空闲的，在分配内存时找到一块适合对象大小的内存块给对象使用；jvm的gc算法决定了使用哪种内存分配方式，serial、parnew带compat的采用规整的指针位移，使用CMS基于mark-sweep算法采用空闲列表；
在创建对象实例的过程，涉及到指针偏移和指向某个内存块的过程，然而在多线程并发的时候，可能会出现线程安全问题，比如：指针正在给new A()分配内存，new B()同时请求指针分配内存，jvm提供两种解决方案：一种是对分配内存空间过程实行同步处理(锁定，即所有实例按顺序分配)；另一种是线程预先分配到小块内存，称为本地线程分配缓冲(thread local alloction buffer,TLAB),在线程用完tlab再获得新的tlab时进行同步锁定，显然第二种是常用方法，虚拟机是否使用tlab，通过-xx.+/-usertlab参数设定。
