1. Java内存区域（运行时数据区）
jdk1.8之前：
线程共享：堆、方法区（运行时常量池）；（进程）
线程私有：虚拟机栈、本地方法栈、程序计数器；
直接内存；
jdk1.8之后：
线程共享：堆；（进程）
线程私有：虚拟机栈、本地方法栈、程序计数器；
直接内存（元空间）；
2.程序计数器：
较⼩的内存空间，当前线程所执⾏的字节码的⾏号指示器。字节码解释器⼯作时通过改变这个计数器的值来选取下⼀条需要执⾏的字节码指令，分⽀、循环、跳转、异常处理、线程恢复等功能都需要依赖这个计数器来完成。
每条线程都需要有⼀个独⽴的程序计数器，各线程之间计数器互不影响，独⽴存储，线程私有。从上⾯的介绍中我们知道程序计数器主要有两个作⽤：
1. 字节码解释器通过改变程序计数器来依次读取指令，从⽽实现代码的流程控制，如：顺序执⾏、选择、循环、异常处理。
2. 在多线程的情况下，程序计数器⽤于记录当前线程执⾏的位置，从⽽当线程被切换回来的时候能够知道该线程上次运⾏到哪⼉了。注意：程序计数器是唯⼀⼀个不会出现 OutOfMemoryError 的内存区域，它的⽣命周期随着线程的创建⽽创建，随着线程的结束⽽死亡。
3.Java 虚拟机栈
线程私有，它的⽣命周期和线程相同，描述的是 Java ⽅法执⾏的内存模型，每次⽅法调⽤的数据都是通过栈传递的。
Java 内存可以分为堆内存（Heap）和栈内存 (Stack),栈就是虚拟机栈，或者说是虚拟机栈中局部变量表部分。
Java 虚拟机栈是由⼀个个栈帧组成；
栈帧中都拥有：局部变量表、操作数栈、动态链接、⽅法出⼝信息。
局部变量表主要存放了编译期可知的各种数据类型（boolean、byte、char、short、int、float、long、double）、对象引⽤（reference 类型，它不同于对象本身，可能是⼀个指向对象起始地址的引⽤指针，也可能是指向⼀个代表对象的句柄或其他与此对象相关的位置）。
Java 虚拟机栈会出现两种错误：StackOverFlowError 和 OutOfMemoryError。
StackOverFlowError： 若 Java 虚拟机栈的内存⼤⼩不允许动态扩展，那么当线程请求栈的深度超过当前 Java 虚拟机栈的最⼤深度的时候。
OutOfMemoryError： 若 Java 虚拟机堆中没有空闲内存，并且垃圾回收器也⽆法提供更多内存的话。
扩展：那么⽅法/函数如何调⽤？Java 栈可⽤类⽐数据结构中栈，Java 栈中保存的主要内容是栈帧，每⼀次函数调⽤都会有⼀个对应的栈帧被压⼊ Java 栈，每⼀个函数调⽤结束后，都会有⼀个栈帧被弹出。Java ⽅法有两种返回⽅式：1. return 语句。2. 抛出异常。不管哪种返回⽅式都会导致栈帧被弹出。
4 本地⽅法栈
和虚拟机栈相似，区别是： 虚拟机栈为虚拟机执⾏ Java ⽅法 （也就是字节码）服务，⽽本地⽅法栈则为虚拟机使⽤到的 Native ⽅法服务。 在 HotSpot 虚拟机中和 Java 虚拟机栈合⼆为⼀。本地⽅法被执⾏的时候，在本地⽅法栈也会创建⼀个栈帧，⽤于存放该本地⽅法的局部变量表、操作数栈、动态链接、出⼝信息。⽅法执⾏完毕后相应的栈帧也会出栈并释放内存空间，也会出现 StackOverFlowError 和 OutOfMemoryError 两种错误。
5.堆
内存中最⼤的⼀块区域，线程共享，在虚拟机启动时创建。此内存区域的唯⼀⽬的就是存放对象实例，⼏乎所有的对象实例以及数组都在这⾥分配内存。
Java世界中“⼏乎”所有的对象都在堆中分配变得不那么“绝对”了。从jdk 1.7开始开启逃逸分析，如果某些⽅法中的对象引⽤没有被返回或者未被外⾯使⽤（也就是未逃逸出去），那么对象可以直接在栈上分配内存。
Java 堆是垃圾收集器管理的主要区域，因此也被称作GC 堆（Garbage Collected Heap）.从垃圾回收的⻆度，由于现在收集器基本都采⽤分代垃圾收集算法。
Java 堆还可以细分为：新⽣代和⽼年代：再细致⼀点有：Eden 空间、From Survivor、To Survivor 空间等。进⼀步划分的⽬的是更好地回收内存，或者更快地分配内存。在 JDK 7 版本及JDK 7 版本之前，堆内存被通常被分为下⾯三部分：
1. 新⽣代内存(Young Generation)
2. ⽼⽣代(Old Generation)
3. 永⽣代(Permanent Generation)JDK 8 版本之后⽅法区（HotSpot 的永久代）被彻底移除了（JDK1.7 就已经开始了），取⽽代之是元空间，元空间使⽤的是直接内存。
Eden 区、两个 Survivor 区都属于新⽣代（为了区分，这两个 Survivor 区域按照顺序被命名为 from 和 to），中间⼀层属于⽼年代。⼤部分情况，对象都会⾸先在 Eden 区域分配，在⼀次新⽣代垃圾回收后，如果对象还存活，则会进⼊ s0 或者 s1，并且对象的年龄还会加 1(Eden 区->Survivor 区后对象的初始年龄变为 1)，当它的年龄增加到⼀定程度（默认为 15 岁），就会被晋升到⽼年代中。对象晋升到⽼年代的年龄阈值，可以通过参数 -XX:MaxTenuringThreshold 来设置。
（Hotspot遍历所有对象时，按照年龄从⼩到⼤对其所占⽤的⼤⼩进⾏累积，当累积的某个年龄⼤⼩超过了survivor区的⼀半时，取这个年龄和MaxTenuringThreshold中更⼩的⼀个值，作为新的晋升年龄阈值”。）
uint ageTable::compute_tenuring_threshold(size_t survivor_capacity) {
//survivor_capacity是survivor空间的⼤⼩
size_t desired_survivor_size = (size_t)((((double)survivor_capacity)*TargetSurvivorRatio)/100);
size_t total = 0;
uint age = 1;
while (age < table_size)
{
total += sizes[age];
//sizes数组是每个年龄段对象⼤⼩
if (total > desired_survivor_size) break;
age++;
}
uint result = age < MaxTenuringThreshold ? age : MaxTenuringThreshold; ...}OutOfMemoryError 错误:
1. OutOfMemoryError: GC Overhead Limit Exceeded ： 当JVM花太多时间执⾏垃圾回收并且只能回收很少的堆空间时，就会发⽣此错误。
2. java.lang.OutOfMemoryError: Java heap space :假如在创建新的对象时, 堆内存中的空间不⾜以存放新创建的对象, 就会引发.(和本机物理内存⽆关，和你配置的内存⼤⼩有关！)
6. ⽅法区
线程共享的内存区域，存储已被虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码等数据。堆的⼀个逻辑部分，叫做 Non-Heap（⾮堆），⽬的应该是与 Java 堆区分开来。⽅法区也被称为永久代。
1. ⽅法区和永久代的关系
《Java 虚拟机规范》只是规定了有⽅法区这么个概念和它的作⽤，并没有规定如何去实现它。那么，在不同的 JVM 上⽅法区的实现肯定是不同的了。 ⽅法区和永久代的关系很像 Java 中接⼝和类的关系，类实现了接⼝，⽽永久代就是 HotSpot 虚拟机对虚拟机规范中⽅法区的⼀种实现⽅式。
2.常⽤参数
JDK 1.8 之前永久代还没被彻底移除的时候通常通过下⾯这些参数来调节⽅法区⼤⼩相对⽽⾔，垃圾收集⾏为在这个区域是⽐较少出现的，但并⾮数据进⼊⽅法区后就“永久存在”了。
-XX:PermSize=N //⽅法区 (永久代) 初始⼤⼩
-XX:MaxPermSize=N //⽅法区 (永久代) 最⼤⼤⼩,超过这个值将会抛出 OutOfMemoryError 异常:java.lang.OutOfMemoryError: PermGen
JDK 1.8 的时候，⽅法区（HotSpot 的永久代）被彻底移除了（JDK1.7 就已经开始了），取⽽代之是元空间，元空间使⽤的是直接内存。下⾯是⼀些常⽤参数：与永久代很⼤的不同就是，如果不指定⼤⼩的话，随着更多类的创建，虚拟机会耗尽所有可⽤的系统内存。
-XX:MetaspaceSize=N //设置 Metaspace 的初始（和最⼩⼤⼩）
-XX:MaxMetaspaceSize=N //设置 Metaspace 的最⼤⼤⼩
3.为什么要将永久代 (PermGen) 替换为元空间 (MetaSpace) 呢?
1. 整个永久代有⼀个 JVM 本身设置固定⼤⼩上限，⽆法进⾏调整，⽽元空间使⽤的是直接内存，受本机可⽤内存的限制，虽然元空间仍旧可能溢出，但是⽐原来出现的⼏率会更⼩。当你元空间溢出时会得到如下错误： java.lang.OutOfMemoryError: MetaSpace
-XX MaxMetaspaceSize 标志设置最m⼤元空间⼤⼩，默认值为 unlimited，这意味着它只受系统内存的限制。
-XX MetaspaceSize 调整标志定义元空间的初始⼤⼩如果未指定此标志，则 Metaspace 将根据运⾏时的应⽤程序需求动态地重新调整⼤⼩。
2. 元空间⾥⾯存放的是类的元数据，这样加载多少类的元数据就不由 MaxPermSize 控制了, ⽽由系统的实际可⽤空间来控制，这样能加载的类就更多了。
3. 在 JDK8，合并 HotSpot 和 JRockit 的代码时, JRockit 从来没有⼀个叫永久代的东⻄, 合并之后就没有必要额外的设置这么⼀个永久代的地⽅了。
7. 运⾏时常量池
运⾏时常量池是⽅法区的⼀部分。
还有常量池表（⽤于存放编译期⽣成的各种字⾯量和符号引⽤）既然运⾏时常量池是⽅法区的⼀部分，⾃然受到⽅法区内存的限制，当常量池⽆法再申请到内存时会抛出 OutOfMemoryError 错误。
JDK1.7 及之后版本的 JVM 已经将运⾏时常量池从⽅法区中移了出来，在 Java 堆（Heap）中开辟了⼀块区域存放字符串常量池。
修正(issue747，reference)： 1. JDK1.7之前运⾏时常量池逻辑包含字符串常量池存放在⽅法区, 此时hotspot虚拟机对⽅法区的实现为永久代2. JDK1.7 字符串常量池被从⽅法区拿到了堆中, 这⾥没有提到运⾏时常量池,也就是说字符串常量池被单独拿到堆,运⾏时常量池剩下的东⻄还在⽅法区, 也就是hotspot中的永久代 。3. JDK1.8 hotspot移除了永久代⽤元空间(Metaspace)取⽽代之, 这时候字符串常量池还在堆, 运⾏时常量池还在⽅法区, 只不过⽅法区的实现从永久代变成了元空间(Metaspace)
相关问题：JVM 常量池中存储的是对象还是引⽤呢？（jdk1.8版本的字符串常量池存放的是字符串对象和字符串常量池，元空间的常量池寻访的是引用。）
8. 直接内存
直接内存并不是虚拟机运⾏时数据区的⼀部分，也不是虚拟机规范中定义的内存区域，但是这部分内存也被频繁地使⽤。⽽且也可能导致 OutOfMemoryError 错误出现。JDK1.4 中新加⼊的 NIO(New Input/Output) 类，引⼊了⼀种基于通道（Channel） 与缓存区（Buffer） 的 I/O ⽅式，它可以直接使⽤ Native 函数库直接分配堆外内存，然后通过⼀个存储在 Java 堆中的 DirectByteBuffer 对象作为这块内存的引⽤进⾏操作。这样就能在⼀些场景中显著提⾼性能，因为避免了在 Java 堆和 Native 堆之间来回复制数据。本机直接内存的分配不会受到 Java 堆的限制，但是，既然是内存就会受到本机总内存⼤⼩以及处理器寻址空间的限制。
9.Java对象的创建过程
1.类加载检查 2.分配内存 3.初始化零值 4.设置对象头 5.执行init方法
Step1:类加载检查
虚拟机遇到⼀条 new 指令时，⾸先将去检查这个指令的参数是否能在常量池中定位到这个类的符号引⽤，并且检查这个符号引⽤代表的类是否已被加载过、解析和初始化过。如果没有，那必须先执⾏相应的类加载过程。
Step2:分配内存
在类加载检查通过后，接下来虚拟机将为新⽣对象分配内存。对象所需的内存⼤⼩在类 加载完成后便可确定，为对象分配空间的任务等同于把⼀块确定⼤⼩的内存从 Java 堆中划分出来。分配⽅式有 “指针碰撞” 和 “空闲列表” 两种，选择哪种分配⽅式由 Java 堆是否规整决定，⽽ Java 堆是否规整⼜由所采⽤的垃圾收集器是否带有压缩整理功能决定。
内存分配的两种⽅式：（补充内容，需要掌握）
选择以上两种⽅式中的哪⼀种，取决于 Java 堆内存是否规整。⽽ Java 堆内存是否规整，取决于 GC 收集器的算法是"标记-清除"，还是"标记-整理"（也称作"标记-压缩"），值得注意的是，复制算法内存也是规整的。
内存分配并发问题（补充内容，需要掌握）
在创建对象的时候有⼀个很重要的问题，就是线程安全，因为在实际开发过程中，创建对象是很频繁的事情，作为虚拟机来说，必须要保证线程是安全的，通常来讲，虚拟机采⽤两种⽅式来保证线程安全：
CAS+失败重试： CAS 是乐观锁的⼀种实现⽅式。所谓乐观锁就是，每次不加锁⽽是假设没有冲突⽽去完成某项操作，如果因为冲突失败就重试，直到成功为⽌。虚拟机采⽤ CAS 配上失败重试的⽅式保证更新操作的原⼦性。
TLAB： 为每⼀个线程预先在 Eden 区分配⼀块⼉内存，JVM 在给线程中的对象分配内存时，⾸先在 TLAB 分配，当对象⼤于 TLAB 中的剩余内存或 TLAB 的内存已⽤尽时，再采⽤上述的 CAS 进⾏内存分配。
Step3:初始化零值
内存分配完成后，虚拟机需要将分配到的内存空间都初始化为零值（不包括对象头），这⼀步操作保证了对象的实例字段在 Java 代码中可以不赋初始值就直接使⽤，程序能访问到这些字段的数据类型所对应的零值。
Step4:设置对象头
初始化零值完成之后，虚拟机要对对象进⾏必要的设置，例如这个对象是哪个类的实例、如何才能找到类的元数据信息、对象的哈希码、对象的 GC 分代年龄等信息。 这些信息存放在对象头中。 另外，根据虚拟机当前运⾏状态的不同，如是否启⽤偏向锁等，对象头会有不同的设置⽅式。
Step5:执⾏ init ⽅法
在上⾯⼯作都完成之后，从虚拟机的视⻆来看，⼀个新的对象已经产⽣了，但从 Java 程序的视⻆来看，对象创建才刚开始，<init> ⽅法还没有执⾏，所有的字段都还为零。所以⼀般来说，执⾏ new 指令之后会接着执⾏ <init> ⽅法，把对象按照程序员的意愿进⾏初始化，这样⼀个真正可⽤的对象才算完全产⽣出来。
10.对象的访问定位有哪两种⽅式?
建⽴对象就是为了使⽤对象，我们的Java程序通过栈上的 reference 数据来操作堆上的具体对象。对象的访问⽅式有虚拟机实现⽽定，⽬前主流的访问⽅式有①使⽤句柄和②直接指针两种：
1. 句柄： 如果使⽤句柄的话，那么Java堆中将会划分出⼀块内存来作为句柄池，reference 中存储的就是对象的句柄地址，⽽句柄中包含了对象实例数据与类型数据各⾃的具体地址信息；
对象实例数据（堆）:对象中各个实例字段的数据对象类型数据（方法区）：对象的类型、父类、实现的接口、方法等静态区（也在方法区中）用来存放静态变量，静态块
2. 直接指针： 如果使⽤直接指针访问，那么 Java 堆对象的布局中就必须考虑如何放置访问类型数据的相关信息，⽽reference 中存储的直接就是对象的地址。
使⽤句柄来访问的最⼤好处是 reference 中存储的是稳定的句柄地址，在对象被移动时只会改变句柄中的实例数据指针，⽽ reference 本身不需要修改。使⽤直接指针访问⽅式最⼤的好处就是速度快，它节省了⼀次指针定位的时间开销。
11. JVM 内存分配与回收
Java 的⾃动内存管理主要是针对对象内存的回收和对象内存的分配。同时，Java ⾃动内存管理最核⼼的功能是 堆 内存中对象的分配与回收。Java 堆是垃圾收集器管理的主要区域，因此也被称作GC 堆（Garbage Collected Heap）.从垃圾回收的⻆度，由于现在收集器基本都采⽤分代垃圾收集算法，所以 Java 堆还可以细分为：新⽣代和⽼年代：再细致⼀点有：Eden 空间、From Survivor、To Survivor 空间等。进⼀步划分的⽬的是更好地回收内存，或者更快地分配内存。
Eden 区、两个 Survivor 区都属于新⽣代（为了区分，这两个 Survivor 区域按照顺序被命名为 from 和 to），中间⼀层属于⽼年代。⼤部分情况，对象都会⾸先在 Eden 区域分配，在⼀次新⽣代垃圾回收后，如果对象还存活，则会进⼊ s0 或者 s1，并且对象的年龄还会加 1(Eden 区->Survivor 区后对象的初始年龄变为 1)，当它的年龄增加到⼀定程度（默认为 15 岁），就会被晋升到⽼年代中。对象晋升到⽼年代的年龄阈值，可以通过参数 -XX:MaxTenuringThreshold 来设置。
（Hotspot遍历所有对象时，按照年龄从⼩到⼤对其所占⽤的⼤⼩进⾏累积，当累积的某个年龄⼤⼩超过了survivor区的⼀半时，取这个年龄和MaxTenuringThreshold中更⼩的⼀个值，作为新的晋升年龄阈值”。）
经过这次 GC 后，Eden 区和"From"区已经被清空。这个时候，"From"和"To"会交换他们的⻆⾊，也就是新的"To"就是上次 GC 前的“From”，新的"From"就是上次 GC 前的"To"。不管怎样，都会保证名为 To 的 Survivor 区域是空的。Minor GC 会⼀直重复这样的过程，直到“To”区被填满，"To"区被填满之后，会将所有对象移动到⽼年代中。
12.说⼀下堆内存中对象的分配的基本策略
1. 对象优先在 eden 区分配
⽬前主流的垃圾收集器都会采⽤分代回收算法，因此需要将堆内存分为新⽣代和⽼年代，这样我们就可以根据各个年代的特点选择合适的垃圾收集算法。
⼤多数情况下，对象在新⽣代中 eden 区分配。当 eden 区没有⾜够空间进⾏分配时，虚拟机将发起⼀次 Minor GC.下⾯我们来进⾏实际测试以下。
-XX:+PrintGCDetails测试
2. ⼤对象直接进⼊⽼年代
为了避免为⼤对象分配内存时由于分配担保机制带来的复制⽽降低效率。
3. ⻓期存活的对象将进⼊⽼年代
采⽤了分代收集的思想来管理内存，能识别哪些对象应放在新⽣代，哪些对象应放在⽼年代中。虚拟机给每个对象⼀个对象年龄（Age）计数器。如果对象在 Eden 出⽣并经过第⼀次 Minor GC 后仍然能够存活，并且能被 Survivor 容纳的话，将被移动到 Survivor 空间中，并将对象年龄设为 1.对象在 Survivor 中每熬过⼀次 MinorGC,年龄就增加 1 岁，当它的年龄增加到⼀定程度（默认为 15 岁），就会被晋升到⽼年代中。对象晋升到⽼年代的年龄阈值，可以通过参数 -XX:MaxTenuringThreshold 来设置。
（默认晋升年龄并不都是 15，这个是要区分垃圾收集器的，CMS 就是 6.）
4.进⾏ gc 的区域
部分收集 (Partial GC)：
新⽣代收集（Minor GC / Young GC）：只对新⽣代进⾏垃圾收集；
⽼年代收集（Major GC / Old GC）：只对⽼年代进⾏垃圾收集。需要注意的是 Major GC 在有的语境中也⽤于指代整堆收集；
混合收集（Mixed GC）：对整个新⽣代和部分⽼年代进⾏垃圾收集。
整堆收集 (Full GC)：收集整个 Java 堆和⽅法区。
5. 如何判断对象是否死亡?
(两种⽅法) 堆中⼏乎放着所有的对象实例，对堆垃圾回收前的第⼀步就是要判断哪些对象已经死亡（即不能再被任何途径使⽤的对象）。
1. 引⽤计数法
给对象中添加⼀个引⽤计数器，每当有⼀个地⽅引⽤它，计数器就加1；当引⽤失效，计数器就减1；任何时候计数器为0的对象就是不可能再被使⽤的。
2. 可达性分析算法
这个算法的基本思想就是通过⼀系列的称为 “GC Roots” 的对象作为起点，从这些节点开始向下搜索，节点所⾛过的路径称为引⽤链，当⼀个对象到 GC Roots 没有任何引⽤链相连的话，则证明此对象是不可⽤的。
6.简单的介绍⼀下强引⽤,软引⽤,弱引⽤,虚引⽤
⽆论是通过引⽤计数法判断对象引⽤数量，还是通过可达性分析法判断对象的引⽤链是否可达，判定对象的存活都与“引⽤”有关。
1. 强引⽤(StrongReference) 以前我们使⽤的⼤部分引⽤实际上都是强引⽤，这是使⽤最普遍的引⽤。如果⼀个对象具有强引⽤，那就类似于必不可少的⽣活⽤品，垃圾回收器绝不会回收它。当内存空 间不⾜，Java虚拟机宁愿抛出OutOfMemoryError错误，使程序异常终⽌，也不会靠随意回收具有强引⽤的对象来解决内存不⾜问题。
2. 软引⽤(SoftReference) 如果⼀个对象只具有软引⽤，那就类似于可有可⽆的⽣活⽤品。如果内存空间⾜够，垃圾回收器就不会回收它，如果内存空间不⾜了，就会回收这些对象的内存。只要垃圾回收器没有回收它，该对象就可以被程序使⽤。软引⽤可⽤来实现内存敏感的⾼速缓存。软引⽤可以和⼀个引⽤队列（ReferenceQueue）联合使⽤，如果软引⽤所引⽤的对象被垃圾回收，JAVA虚拟机就会把这个软引⽤加⼊到与之关联的引⽤队列中。
3. 弱引⽤(WeakReference) 如果⼀个对象只具有弱引⽤，那就类似于可有可⽆的⽣活⽤品。弱引⽤与软引⽤的区别在于：只具有弱引⽤的对象拥有更短暂的⽣命周期。在垃圾回收器线程扫描它所管辖的内存区域的过程中，⼀旦发现了只具有弱引⽤的对象，不管当前内存空间⾜够与否，都会回收它的内存。不过，由于垃圾回收器是⼀个优先级很低的线程， 因此不⼀定会很快发现那些只具有弱引⽤的对象。 弱引⽤可以和⼀个引⽤队列（ReferenceQueue）联合使⽤，如果弱引⽤所引⽤的对象被垃圾回收，Java虚拟机就会把这个弱引⽤加⼊到与之关联的引⽤队列中。
4．虚引⽤（PhantomReference）"虚引⽤"顾名思义，就是形同虚设，与其他⼏种引⽤都不同，虚引⽤并不会决定对象的⽣命周期。如果⼀个对象仅持有虚引⽤，那么它就和没有任何引⽤⼀样，在任何时候都可能被垃圾回收。虚引⽤主要⽤来跟踪对象被垃圾回收的活动。虚引⽤与软引⽤和弱引⽤的⼀个区别在于： 虚引⽤必须和引⽤队列（ReferenceQueue）联合使⽤。当垃 圾回收器准备回收⼀个对象时，如果发现它还有虚引⽤，就会在回收对象的内存之前，把这个虚引⽤加⼊到与之关联的引⽤队列中。程序可以通过判断引⽤队列中是 否已经加⼊了虚引⽤，来了解被引⽤的对象是否将要被垃圾回收。程序如果发现某个虚引⽤已经被加⼊到引⽤队列，那么就可以在所引⽤的对象的内存被回收之前采取必要的⾏动。 特别注意，在程序设计中⼀般很少使⽤弱引⽤与虚引⽤，使⽤软引⽤的情况多，这是因为软引⽤可以加速JVM对垃圾内存的回收速度，可以维护系统的运⾏安全，防⽌内存溢出（OutOfMemory）等问题的产⽣。
7.如何判断⼀个常量是废弃常量?
如果当前没有任何String对象引⽤该字符串常量的话，就说明常量 "abc" 就是废弃常量。
8.如何判断⼀个类是⽆⽤的类?
1.该类所有的实例都已经被回收，也就是 Java 堆中不存在该类的任何实例。
2.加载该类的 ClassLoader 已经被回收。
3.该类对应的 java.lang.Class 对象没有在任何地⽅被引⽤，⽆法在任何地⽅通过反射访问该类的⽅法。
虚拟机可以对满⾜上述 3 个条件的⽆⽤类进⾏回收，这⾥说的仅仅是“可以”，⽽并不是和对象⼀样不使⽤了就会必然被回收。
9.垃圾收集有哪些算法，各⾃的特点？
1. 标记-清除算法 该算法分为“标记”和“清除”阶段：⾸先标记出所有不需要回收的对象，在标记完成后统⼀回收掉所有没有被标记的对象。它是最基础的收集算法，后续的算法都是对其不⾜进⾏改进得到。这种垃圾收集算法会带来两个明显的问题：1. 效率问题2. 空间问题（标记清除后会产⽣⼤量不连续的碎⽚）
2. 复制算法 为了解决效率问题，“复制”收集算法出现了。它可以将内存分为⼤⼩相同的两块，每次使⽤其中的⼀块。当这⼀块的内存使⽤完后，就将还存活的对象复制到另⼀块去，然后再把使⽤的空间⼀次清理掉。这样就使每次的内存回收都是对内存区间的⼀半进⾏回收。
3. 标记-整理算法 根据⽼年代的特点提出的⼀种标记算法，标记过程仍然与“标记-清除”算法⼀样，但后续步骤不是直接对可回收对象回收，⽽是让所有存活的对象向⼀端移动，然后直接清理掉端边界以外的内存。
4. 分代收集算法 当前虚拟机的垃圾收集都采⽤分代收集算法，这种算法没有什么新的思想，只是根据对象存活周期的不同将内存分为⼏块。⼀般将 java 堆分为新⽣代和⽼年代，这样我们就可以根据各个年代的特点选择合适的垃圾收集算法。⽐如在新⽣代中，每次收集都会有⼤量对象死去，所以可以选择复制算法，只需要付出少量对象的复制成本就可以完成每次垃圾收集。⽽⽼年代的对象存活⼏率是⽐较⾼的，⽽且没有额外的空间对它进⾏分配担保，所以我们必须选择“标记-清除”或“标记-整理”算法进⾏垃圾收集。
延伸⾯试问题： HotSpot 为什么要分为新⽣代和⽼年代？根据上⾯的对分代收集算法的介绍回答。（为了提升 GC 效率）
10.常⻅的垃圾回收器有那些？
根据具体应⽤场景选择适合⾃⼰的垃圾收集器；
1. Serial 收集器 Serial（串⾏）
收集器是最基本、历史最悠久的垃圾收集器了。是⼀个单线程收集器了。它的 “单线程” 的意义不仅仅意味着它只会使⽤⼀条垃圾收集线程去完成垃圾收集⼯作，更重要的是它在进⾏垃圾收集⼯作的时候必须暂停其他所有的⼯作线程（ "Stop The World" ），直到它收集结束。新⽣代采⽤复制算法，⽼年代采⽤标记-整理算法。它简单⽽⾼效。Serial 收集器由于没有线程交互的开销，⾃然可以获得很⾼的单线程收集效率。Serial 收集器对于运⾏在 Client 模式下的虚拟机来说是个不错的选择。
2. ParNew 收集器
ParNew 收集器其实就是 Serial 收集器的多线程版本，除了使⽤多线程进⾏垃圾收集外，其余⾏为（控制参数、收集算法、回收策略等等）和 Serial 收集器完全⼀样。新⽣代采⽤复制算法，⽼年代采⽤标记-整理算法。它是许多运⾏在 Server 模式下的虚拟机的⾸要选择，除了 Serial 收集器外，只有它能与 CMS 收集器（真正意义上的并发收集器，后⾯会介绍到）配合⼯作。
3. Parallel Scavenge 收集器
Parallel Scavenge 收集器也是使⽤复制算法的多线程收集器，它看上去⼏乎和 ParNew 都⼀样。
-XX:+UseParallelGC 使⽤ Parallel 收集器+ ⽼年代串⾏ -XX:+UseParallelOldGC 使⽤ Parallel 收集器+ ⽼年代并⾏。
Parallel Scavenge 收集器关注点是吞吐量（⾼效率的利⽤ CPU）。
CMS 等垃圾收集器的关注点更多的是⽤户线程的停顿时间（提⾼⽤户体验）。所谓吞吐量就是 CPU 中⽤于运⾏⽤户代码的时间与 CPU 总消耗时间的⽐值。 Parallel Scavenge 收集器提供了很多参数供⽤户找到最合适的停顿时间或最⼤吞吐量，如果对于收集器运作不太了解，⼿⼯优化存在困难的时候，使⽤ Parallel Scavenge 收集器配合⾃适应调节策略，把内存管理优化交给虚拟机去完成也是⼀个不错的选择。新⽣代采⽤复制算法，⽼年代采⽤标记-整理算法。
JDK1.8 默认使⽤的是 Parallel Scavenge + Parallel Old，如果指定了-XX:+UseParallelGC 参数，则默认指定了-XX:+UseParallelOldGC，可以使⽤-XX:-UseParallelOldGC 来禁⽤该功能
4. Serial Old 收集器
Serial 收集器的⽼年代版本，它同样是⼀个单线程收集器。它主要有两⼤⽤途：⼀种⽤途是在 JDK1.5 以及以前的版本中与 Parallel Scavenge 收集器搭配使⽤，另⼀种⽤途是作为 CMS 收集器的后备⽅案。
5. Parallel Old 收集器
Parallel Scavenge 收集器的⽼年代版本。使⽤多线程和“标记-整理”算法。在注重吞吐量以及 CPU 资源的场合，都可以优先考虑 Parallel Scavenge 收集器和 Parallel Old 收集器。
6. CMS 收集器（Concurrent Mark Sweep）
CMS收集器是⼀种以获取最短回收停顿时间为⽬标的收集器。注重⽤户体验。CMS收集器是 HotSpot 虚拟机第⼀款真正意义上的并发收集器，它第⼀次实现了让垃圾收集线程与⽤户线程（基本上）同时⼯作。是⼀种 “标记-清除”算法实现的，
整个过程分为四个步骤：
初始标记： 暂停所有的其他线程，并记录下直接与 root 相连的对象，速度很快 ；
并发标记： 同时开启 GC 和⽤户线程，⽤⼀个闭包结构去记录可达对象。但在这个阶段结束，这个闭包结构并不能保证包含当前所有的可达对象。因为⽤户线程可能会不断的更新引⽤域，所以 GC 线程⽆法保证可达性分析的实时性。所以这个算法⾥会跟踪记录这些发⽣引⽤更新的地⽅。
重新标记： 重新标记阶段就是为了修正并发标记期间因为⽤户程序继续运⾏⽽导致标记产⽣变动的那⼀部分对象的标记记录，这个阶段的停顿时间⼀般会⽐初始标记阶段的时间稍⻓，远远⽐并发标记阶段时间短。
并发清除： 开启⽤户线程，同时 GC 线程开始对未标记的区域做清扫。
优点：并发收集、低停顿；
缺点：对 CPU 资源敏感；⽆法处理浮动垃圾；它使⽤的回收算法-“标记-清除”算法会导致收集结束时会有⼤量空间碎⽚产⽣。
7. G1 收集器
G1 (Garbage-First) 是⼀款⾯向服务器的垃圾收集器,主要针对配备多颗处理器及⼤容量内存的机器. 以极⾼概率满⾜ GC 停顿时间要求的同时,还具备⾼吞吐量性能特征.
被视为 JDK1.7 中 HotSpot 虚拟机的⼀个重要进化特征。它具备⼀下特点：并⾏与并发：G1 能充分利⽤ CPU、多核环境下的硬件优势，使⽤多个 CPU（CPU 或者 CPU 核⼼）来缩短 Stop-The-World 停顿时间。部分其他收集器原本需要停顿 Java 线程执⾏的 GC 动作，G1 收集器仍然可以通过并发的⽅式让 java 程序继续执⾏。
分代收集：虽然 G1 可以不需要其他收集器配合就能独⽴管理整个 GC 堆，但是还是保留了分代的概念。空间整合：与 CMS 的“标记--清理”算法不同，G1 从整体来看是基于“标记整理”算法实现的收集器；从局部上来看是基于“复制”算法实现的。可预测的停顿：这是 G1 相对于 CMS 的另⼀个⼤优势，降低停顿时间是 G1 和 CMS 共同的关注点，但 G1 除了追求低停顿外，还能建⽴可预测的停顿时间模型，能让使⽤者明确指定在⼀个⻓度为 M 毫秒的时间⽚段内。
G1 收集器的运作⼤致分为以下⼏个步骤：初始标记并发标记最终标记筛选回收G1 收集器在后台维护了⼀个优先列表，每次根据允许的收集时间，优先选择回收价值最⼤的 Region(这也就是它的名字 Garbage-First 的由来)。这种使⽤ Region 划分内存空间以及有优先级的区域回收⽅式，保证了 G1 收集器在有限时间内可以尽可能⾼的收集效率（把内存化整为零）。
8. ZGC 收集器
与 CMS 中的 ParNew 和 G1 类似，ZGC 也采⽤标记-复制算法，不过 ZGC 对该算法做了重⼤改进。在 ZGC 中出现 Stop The World 的情况会更少！
垃圾回收器中都是做两件事情标记和回收，当进行回收的时候应用线程就会停止工作STW。
CMS和G1的区别：
a）初始标记（只去找GCRoot直接关联的对象）
b）并发标记（和应用线程并发执行，去遍历所有对象）
cms会一直执行下去、G1发现老年代没有存活的对象之后就会直接回收。
c）最终标记（为了修正b产生的误差）
d）筛选回收
604
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
