java内存区域，也称运行时数据区
线程私有：
- 程序计数器
- 虚拟机栈
- 本地方法栈
线程共享的：
- 堆
- 方法区
JVM会分配一个运行时内存空间。包括5大部分：程序计数器(Program Counter Register)、虚拟机栈(VM Stack)、本地方法栈(Native Method Stack)、方法区(Method Area)、堆(Heap)。线程私有的空间，会随着线程而生，随着线程而亡。这3个区域内存分配和回收都是确定了的，无需考虑内存回收的问题。但方法区和堆就不同了，一个接口的多个实现类需要的内存可能不一样，只有在程序运行期间才会知道会创建哪些对象，这部分内存的分配和回收都是动态的，GC主要关注的是这部分内存。
程序计数器：程序计数器是一块较小的内存空间，可以看作是当前线程所执行的字节码的行号指示器。字节码解释器工作时通过改变这个计数器的值来选取下一条需要执行的字节码指令，分支、循环、跳转、异常处理、线程恢复等功能都需要依赖这个计数器来完。
另外，为了线程切换后能恢复到正确的执行位置，每条线程都需要有一个独立的程序计数器，各线程之间计数器互不影响，独立存储，我们称这类内存区域为“线程私有”的内存。
从上面的介绍中我们知道程序计数器主要有两个作用：
- 字节码解释器通过改变程序计数器来依次读取指令，从而实现代码的流程控制，如：顺序执行、选择、循环、异常处理。
- 在多线程的情况下，程序计数器用于记录当前线程执行的位置，从而当线程被切换回来的时候能够知道该线程上次运行到哪儿了。
注意：程序计数器是唯一一个不会出现OutOfMemoryError的内存区域，它的生命周期随着线程的创建而创建，随着线程的结束而死亡。
虚拟机栈：与程序计数器一样，Java虚拟机栈也是线程私有的，它的生命周期和线程相同，描述的是 Java 方法执行的内存模型。
Java 内存可以粗糙的区分为堆内存（Heap）和栈内存(Stack),其中栈就是现在说的虚拟机栈，或者说是虚拟机栈中局部变量表部分。 （实际上，Java虚拟机栈是由一个个栈帧组成，而每个栈帧中都拥有：局部变量表、操作数栈、动态链接、方法出口信息。）
局部变量表主要存放了编译器可知的各种数据类型（boolean、byte、char、short、int、float、long、double）、对象引用（reference类型，它不同于对象本身，可能是一个指向对象起始地址的引用指针，也可能是指向一个代表对象的句柄或其他与此对象相关的位置）。
Java 虚拟机栈会出现两种异常：StackOverFlowError 和 OutOfMemoryError。
- StackOverFlowError： 若Java虚拟机栈的内存大小不允许动态扩展，那么当线程请求栈的深度超过当前Java虚拟机栈的最大深度的时候，就抛出StackOverFlowError异常。
- OutOfMemoryError： 若 Java 虚拟机栈的内存大小允许动态扩展，且当线程请求栈时内存用完了，无法再动态扩展了，此时抛出OutOfMemoryError异常。
Java 虚拟机栈也是线程私有的，每个线程都有各自的Java虚拟机栈，而且随着线程的创建而创建，随着线程的死亡而死亡。
本地方法栈：和虚拟机栈所发挥的作用非常相似，区别是： 虚拟机栈为虚拟机执行 Java 方法 （也就是字节码）服务，而本地方法栈则为虚拟机使用到的 Native 方法服务。 在 HotSpot 虚拟机中和 Java 虚拟机栈合二为一。
本地方法被执行的时候，在本地方法栈也会创建一个栈帧，用于存放该本地方法的局部变量表、操作数栈、动态链接、出口信息。
方法执行完毕后相应的栈帧也会出栈并释放内存空间，也会出现 StackOverFlowError 和 OutOfMemoryError 两种异常。
堆：Java 虚拟机所管理的内存中最大的一块，Java 堆是所有线程共享的一块内存区域，在虚拟机启动时创建。此内存区域的唯一目的就是存放对象实例，几乎所有的对象实例以及数组都在这里分配内存。
Java 堆是垃圾收集器管理的主要区域，因此也被称作GC堆（Garbage Collected Heap）.从垃圾回收的角度，由于现在收集器基本都采用分代垃圾收集算法，所以Java堆还可以细分为：新生代和老年代：再细致一点有：Eden空间、From Survivor、To Survivor空间等。进一步划分的目的是更好地回收内存，或者更快地分配内存。
下图是JDK1.7版本时的堆空间的内存分配示意图：
方法区：方法区与 Java 堆一样，是各个线程共享的内存区域，它用于存储已被虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码等数据。虽然Java虚拟机规范把方法区描述为堆的一个逻辑部分，但是它却有一个别名叫做 Non-Heap（非堆），目的应该是与 Java 堆区分开来。
HotSpot 虚拟机中方法区也常被称为 “永久代”，本质上两者并不等价。仅仅是因为 HotSpot 虚拟机设计团队用永久代来实现方法区而已，这样 HotSpot 虚拟机的垃圾收集器就可以像管理 Java 堆一样管理这部分内存了。但是这并不是一个好主意，因为这样更容易遇到内存溢出问题。
相对而言，垃圾收集行为在这个区域是比较少出现的，但并非数据进入方法区后就“永久存在”了。
常量池：Java中有三种常量池，字符串常量池、class常量池、运行时常量池
字符串常量池：
在jdk1.6以及之前的版本，字符串常量池是放到方法区中的，在1.7及之后就被移到了堆中；在HotSpot VM里实现string pool功能的是一个StringTable类，它是一个Hash表，默认长度是1009；StringTable在每个HotSpot VM的实例只有一份，被所有的类共享。字符串常量由一个个字符组成，放在了StringTable上。
字符串常量池里放的是什么？
在JDK6.0及之前的版本中，String Pool里放的都是字符串常量；在JDK7.0中，String Pool中可以存放放于堆内的字符串对象的引用。
class常量池：
每一个Java类都会被编译成class文件；class文件中除了包含类的版本、字段、方法、接口等描述信息外，还有一项信息就是常量池，用于存放编译器生成的各种字面量和符号引用，每个class文件都有一个class常量池。
什么是字面量和符号引用：
- 字面量包括：1.文本字符串 2.八种基本类型的值 3.被声明为final的常量等;
- 符号引用包括：1.类和方法的全限定名 2.字段的名称和描述符 3.方法的名称和描述符。
运行时常量池：
运行时常量池存在于方法区中（JDK1.7及之后版本的 JVM 已经将运行时常量池从方法区中移了出来，在 Java 堆（Heap）中开辟了一块区域存放运行时常量池。），也就是class常量池被加载到内存之后的版本。
不同之处是：它的字面量可以动态的添加，符号引用可以被解析为直接引用。当类加载到内存中后，jvm就会将class常量池中的内容存放到运行时常量池中，由此可知，运行时常量池也是每个类都有一个。在解析阶段，会把符号引用替换为直接引用，解析的过程会去查询字符串常量池，以保证运行时常量池所引用的字符串与字符串常量池中是一致的。
既然运行时常量池时方法区的一部分，自然受到方法区内存的限制，当常量池无法再申请到内存时会抛出 OutOfMemoryError 异常。
GC机制
Java GC（Garbage Collection）垃圾回收机制，Java VM中，存在自动内存管理和垃圾清理机制。GC机制对JVM（Java Virtual Machine）中的内存进行标记，并确定哪些内存需要回收，根据一定的回收策略，自动的回收内存，永不停息（Nerver Stop）的保证JVM中的内存空间，防止出现内存泄露和溢出问题。Java中不能显式分配和注销内存。有些开发者把对象设置为null或者调用System.gc()显式清理内存。设置为null至少没什么坏处，但是调用System.gc()会一定程度上影响系统性能。Java开发人员通常无须直接在程序代码中清理内存，而是由垃圾回收器自动寻找不必要的垃圾对象，并且清理掉它们。
Java GC主要做三件事：
（a）哪些内存需要GC？
（b）何时需要执行GC？
（c）以何策略执行GC？
Java中什么哪些内存需要GC回收？
JVM会分配一个运行时内存空间。包括5大部分：程序计数器(Program Counter Register)、虚拟机栈(VM Stack)、本地方法栈(Native Method Stack)、方法区(Method Area)、堆(Heap)。其中程序计数器、虚拟机栈、本地方法栈是每个线程私有内存空间，随线程而生，随线程而亡。这3个区域内存分配和回收都是确定的，无需考虑内存回收的问题。
但方法区和堆就不同了，一个接口的多个实现类需要的内存可能不一样，只有在程序运行期间才会知道会创建哪些对象，这部分内存的分配和回收都是动态的，GC主要关注的是这部分内存。GC主要进行回收的内存是JVM中的方法区和堆，涉及到多线程(指堆)、多个对该对象不同类型的引用(指方法区)，才会涉及GC的回收。
小结：Java GC针对的是JVM中堆和方法区。Java GC机制启动之前，需要确定堆内存中哪些对象是存活的，一般有两种方法：引用计数法和可达性分析法。
引用计数：每个对象有一个引用计数属性，新增一个引用时计数加1，引用释放时计数减1，计数为0时可以回收。引用计数法实现简单，判定高效，但不能解决对象之间相互引用的问题。
可达性分析（Reachability Analysis）：从GC Roots开始向下搜索，搜索所走过的路径称为引用链。当一个对象到GC Roots没有任何引用链相连时，则证明此对象是不可用的。通过称为 “GC Roots” 的对象作为起点，从这些节点开始向下搜索，搜索路径称为 “引用链(Reference Chain)”，以下对象可作为GC Roots：(a)、虚拟机栈（栈帧中的本地变量表）中引用的对象；
(b)、方法区中的类静态变量引用的对象；
(c)、方法区中常量引用的对象
(d)、本地方法栈中JNI（即一般说的Native方法）中引用的对象
小结：当一个对象到 GC Roots 没有任何引用链时，意味着该对象可以被回收。
小结：Java GC垃圾回收机制，回收的是已死的Java对象（引用无法可达）。
Java GC垃圾回收算法：
标记-清除：当堆中的有效内存空间被耗尽的时候，就会停止整个程序，然后进行标记和清除。
标记：标记的过程其实就是，遍历所有的GC Roots，然后将所有的GC Roots可达对象标记为存活的对象。
清除：清除的过程将遍历堆中所有的对象，将没有标记的对象全部清除掉。
之所以说它是最基础的内存回收算法，是因为后续的算法都是基于这种思路、并对其缺点进行改进而得到的。
主要缺点有两个：一个是效率问题，标记和清除过程的效率都不高(需要递归标记和全堆对象遍历清理)；另外一个是空间问题，标记清除之后会产生大量不连续的内存碎片，空间碎片太多可能会导致，当程序在以后的运行过程中需要分配较大对象时无法找到足够的连续内存时候，不得不提前触发另一次垃圾收集动作。
标记-压缩：该算法与标记-清除算法类似，都是先对存活的对象进行标记，但是在清除后会把活的对象向左端空闲空间移动，然后再更新其引用对象的指针。
复制：它将可用内存按容量划分为大小相等的两块，每次只使用其中的一块。当这一块的内存用完了，就将还存活着的对象复制到另外一块上面，然后再把已使用过的内存空间一次清理掉。
这样使得每次都是对其中的一块进行内存回收，内存分配时也就不用考虑内存碎片等复杂情况，只要移动堆顶指针，按顺序分配内存即可，实现简单，运行高效。只是这种算法的代价是将内存缩小为原来的一半，持续复制长生存期的对象则导致效率降低。
Java GC的分代垃圾回收机制
GC分代的假设：绝大部分对象的生命周期都非常短暂，存活时间短。
“分代回收”（Generational Collection）算法，把Java堆分为新生代和老年代，这样就可以根据各个年代的特点采用适当的收集算法。在新生代中，每次垃圾收集时都发现有大批对象死去，只有少量存活，那就选用复制算法，只需要付出少量存活对象的复制成本就可以完成收集。而老年代中因为对象存活率高、没有额外空间对它进行分配担保，就必须使用“标记-清理”或“标记-整理”算法来进行回收。
新生代：
在新生代中，使用“停止-复制”算法进行内存清理。绝大多数最新被创建的对象会被分配到这里，由于大部分对象在创建后会很快变得不可到达，所以很多对象被创建在新生代，然后消失。对象从这个区域消失的过程称为“Minor GC” 。
老年代：
对象没有变得不可达，并且从新生代中存活下来，会被拷贝到这里。其所占用的空间要比新生代多。也正由于其相对较大的空间，发生在老年代上的GC要比新生代少得多。对象如果在年轻代存活了足够长的时间而没有被清理掉（即在几次Young GC后存活了下来），则会被复制到年老代，年老代的空间一般比年轻代大，能存放更多的对象，在年老代上发生的GC次数也比年轻代少。当年老代内存不足时，将执行Major GC，这种情况下也叫Full GC。老年代存储的对象比年轻代多得多，而且不乏大对象。
对老年代进行内存清理时，如果使用停止-复制算法，则相当低效。一般，老年代用的算法是标记-整理算法，即：标记出仍然存活的对象（存在引用的），将所有存活的对象向一端移动，以保证内存的连续。
JVM内存分配策略
- 对象优先分配在Eden区
- 大对象直接进入老年代
- 长期存活的对象将进入老年代
- 空间担保分配（老年代剩余空间要多于幸存区的一般，否则要进行Full GC）
小结：Java内存分配和回收机制是：分代分配，分代回收。新生代中，每次垃圾收集时都有大批对象死去，只有少量存活，就选用复制算法，只需要付出少量存活对象的复制成本就可以完成收集。老年代中，其存活率较高、没有额外空间对它进行分配担保，就应该使用“标记-整理”或“标记-清理”算法进行回收。
新生代垃圾回收过程(复制)
基于大多数新生对象都会在GC中被收回的假设。新生代的GC 使用复制算法。在GC前To 幸存区(survivor)保持清空,对象保存在 Eden 和 From 幸存区(survivor)中。GC运行时,Eden中的幸存对象被复制到 To 幸存区(survivor)，针对 From 幸存区(survivor)中的幸存对象，会考虑对象年龄,如果年龄没达到阀值(tenuring threshold)，对象会被复制到To 幸存区(survivor)，如果达到阀值对象被复制到老年代。复制阶段完成后，Eden 和From 幸存区中只保存死对象，可以视为清空。如果在复制过程中To 幸存区被填满了，剩余的对象会被复制到老年代中。最后 From 幸存区和 To幸存区会调换下名字，在下次GC时，To 幸存区会成为From 幸存区。
上图演示GC过程，黄色表示死对象，绿色表示剩余空间，红色表示幸存对象
总结一下，对象一般出生在Eden区，年轻代GC过程中，对象在2个幸存区之间移动，如果对象存活到适当的年龄，会被移动到老年代。当对象在老年代死亡时，就需要更高级别的GC，更重量级的GC算法(复制算法不适用于老年代，因为没有多余的空间用于复制)
现在应该能理解为什么新生代大小非常重要了(译者,有另外一种说法：新生代大小并不重要，影响GC的因素主要是幸存对象的数量)，如果新生代过小，会导致新生对象很快就晋升到老年代中，在老年代中对象很难被回收。如果新生代过大，会发生过多的复制过程。我们需要找到一个合适大小，不幸的是，要想获得一个合适的大小，只能通过不断的测试调优。
参考博客：
http://ifeve.com/useful-jvm-flags-part-5-young-generation-garbage-collection/
https://blog.csdn.net/anjoyandroid/article/details/78609971
