近期做项目遇到了FullGC的问题，干脆总结一下Java内存区域分布和垃圾回收是咋回事。
Java内存区域按照线程隔离状态直接分成三大块空间：
线程私有：
程序计数器
是一块较小的内存空间，可以看做当前线程所执行的字节码的行号指示器。在虚拟机概念模型里，字节码解释器工作时就是通过改变这个计数器的值来选取下一条需要执行的字节码指令，分支，循环，跳转，异常处理，线程恢复等基础功能都需要依赖这个计数器来完成。
由于 JVM 的多线程是通过线程轮流切换并分配处理器执行时间的方式来实现的，在任何一个确定的时刻，一个处理器都只会执行一条线程中的指令。因此未来线程切换后能恢复到正确的执行位置，每条线程都需要有一个独立的程序计数器，各条线程之间计数器互不影响，独立存储，故程序计数器是线程私有的。
如果线程正在执行的是一个 Java 方法，这个计数器记录的则是正在执行的虚拟机字节码指令的地址；如果正在执行的是 Native 方法，这个计数器则为空（undefined）。
此内存区域是唯一一个在 Java 虚拟机规范中没有规定任何 OutOfMemoryError 情况的区域。
虚拟机栈
和程序计数器一样，虚拟机栈也是线程私有的，且其生命周期与线程相同。
在栈中，每执行一个方法前都会创建一个栈帧，来储存局部变量表、操作数栈、动态链接以及方法出口等信息。每个方法从调用到完成，就对应着栈中一个栈帧的压栈到弹出的过程。
同时一个方法对应的栈帧中局部变量表所需内存空间早已在编译期间就分配完成，当进入一个方法，虚拟机栈对应压入一个栈帧，次栈帧局部变量表空间大小完全确定。
在 Java 虚拟机规范中，对此区域规定了两种异常状况：如果线程请求的栈深度大于虚拟机所允许的深度，将会抛出 Stack OverflowError 异常；如果虚拟机栈可以动态扩展时无法申请到足够的内存，就会抛出 OutOfMemoryError 异常。
本地方法栈
与虚拟机栈的作用是一样的，只不过虚拟机栈是服务 Java 方法的，而本地方法栈是为虚拟机调用 Native 方法服务的。
但在我们最常用的 HotSpot 虚拟机中,本地方法栈与 Java 虚拟机栈合二为一。
线程共享：
堆
Java 堆是一块线程共享的内存区域，它在虚拟机启动时分配创建，它是 JVM 内存里最大的一块内存，但是它的目的只有一个：存放对象实例。
但是随着 JIT 编译器的发展和逃逸分析技术逐渐成熟，栈上分配，标量替换优化技术将会导致一些微妙的变化发生，所有的对象都分配在堆上也就变得不那么绝对了。
方法区
又被称非堆（Non-Heap），JVM 虚拟机规范中把方法区描述为堆的一个逻辑部分，它与 Java 堆一样，是各个线程共享的内存区域，用于存储已被虚拟机加载的类型信息、常量、静态变量、即时编译器编译后的代码缓存等数据。
但这部分区域又比较特殊，且虚拟机如何实现方法区不受虚拟机规范约束。比如 HotSpot 中，JDK 1.7 之前方法区为永久代，其垃圾回收受 Java 堆 GC 分代收集算法管理，1.7 将 String 常量池移入堆中，1.8 中永久代被完全移除，将类加载信息放入一个线程共享的元空间内。
直接内存
直接内存并不是虚拟机运行时数据区的一部分，也不是 JVM 虚拟机规范中定义的内存区域。但是这部分内存也被频繁地使用，而且也可能导致 OutOfMemoryError 出现。
如 NIO 使用 Native 函数库直接分配堆外内存，然后通过一个 DirectByteBuffer 对象作为这块内存的引用，可以大幅度减轻堆的负担，提高虚拟机性能。
