7种JVM垃圾收集器特点，优劣势、及使⽤场景

题⽬描述

7种JVM垃圾收集器特点，优劣势、及使⽤场景

⾯试题分析

根据题⽬要求我们可以知道：

• 常⻅的垃圾回收器

• 新⽣代垃圾收集器

• ⽼年代垃圾收集器

• 新⽣代和⽼年代垃圾收集器

分析需要全⾯并且有深度

容易被忽略的坑

• 分析⽚⾯

• 没有深⼊

常⻅的垃圾收集器有3类

1.新⽣代的收集器包括：

1. Serial
2. PraNew
3. Parallel Scavenge

2.⽼年代的收集器包括：

1. Serial Old
2. Parallel Old
3. CMS

3.回收整个Java堆(新⽣代和⽼年代)

1. G1收集器

新⽣代垃圾收集器

1.Serial串⾏收集器-复制算法

Serial收集器是新⽣代单线程收集器，优点是简单⾼效，算是最基本、发展历史最悠久的收集器。它在进⾏垃圾收集时，必须暂停其他所有的⼯作线程，直到它收集完成。

Serial收集器依然是虚拟机运⾏在Client模式下默认新⽣代收集器，对于运⾏在Client模式下的虚拟机来说是⼀个很好的选择。

2.ParNew收集器-复制算法

ParNew收集器是新⽣代并⾏收集器，其实就是Serial收集器的多线程版本。

除了使⽤多线程进⾏垃圾收集之外，其余⾏为包括Serial收集器可⽤的所有控制参数、收集算法、Stop The Worl、对象分配规则、回收策略等都与Serial 收集器完全⼀样。

3.Parallel Scavenge（并⾏回收）收集器-复制算法

Parallel Scavenge收集器是新⽣代并⾏收集器，追求⾼吞吐量，⾼效利⽤ CPU。

该收集器的⽬标是达到⼀个可控制的吞吐量（Throughput）。所谓吞吐量就是CPU⽤于运⾏⽤户代码的时间与CPU总消耗时间的⽐值，即 吞吐量=运⾏⽤户代码时间/（运⾏⽤户代码时间+垃圾收集时间）

停顿时间越短就越适合需要与⽤户交互的程序，良好的响应速度能提升⽤户体验，⽽⾼吞吐量则可⽤⾼效率地利⽤CPU时间，尽快完成程序的运算任务，主要适合在后台运算⽽不需要太多交互的任务。

⽼年代垃圾收集器

1.Serial Old收集器-标记整理算法

Serial Old是Serial收集器的⽼年代版本，它同样是⼀个单线程(串⾏)收集器，使⽤标记整理算法。这个收集器的主要意义也是在于给Client模式下的虚拟机使⽤。

如果在Server模式下，主要两⼤⽤途：

（1）在JDK1.5以及之前的版本中与Parallel Scavenge收集器搭配使⽤

（2）作为CMS收集器的后备预案，在并发收集发⽣Concurrent Mode Failure时使⽤

2.Parallel Old收集器-标记整理算法

Parallel Old 是Parallel Scavenge收集器的⽼年代版本，使⽤多线程和“标记-整理”算法。这个收集器在1.6中才开始提供。

3.CMS收集器-标记整理算法

CMS(Concurrent Mark Sweep)收集器是⼀种以获取最短回收停顿时间为⽬标的收集器。

⽬前很⼤⼀部分的Java应⽤集中在互联⽹站或者B/S系统的服务端上，这类应⽤尤其重视服务器的响应速度，希望系统停顿时间最短，以给⽤户带来较好的体验。CMS收集器就⾮常符合这类应⽤的需求。

**CMS收集器是基于“标记-清除”算法实现的，**它的运作过程相对前⾯⼏种收集器来说更复杂⼀些，整个过程分为4个步骤：

（1）初始标记

（2）并发标记

（3）重新标记

（4）并发清除

其中，初始标记、重新标记这两个步骤仍然需要“Stop The World”

CMS收集器主要优点：

1. 并发收集
2. 低停顿

CMS三个明显的缺点：

（1）CMS收集器对CPU资源⾮常敏感。CPU个数少于4个时，CMS对于⽤户程序的影响就可能变得很⼤，为了应付这种情况，虚拟机提供了⼀种称为“增量式并发收集器”的CMS收集器变种。

（2）CMS收集器⽆法处理浮动垃圾，可能出现“Concurrent Mode Failure”失败⽽导致另⼀次Full GC的产⽣。在JDK1.5的默认设置下，CMS收集器当⽼年代使⽤了68%的空间后就会被激活。

（3）CMS是基于“标记-清除”算法实现的收集器，⼿机结束时会有⼤量空间碎⽚产⽣。空间碎⽚过多，可能会出现⽼年代还有很⼤空间剩余，但是⽆法找到⾜够⼤的连续空间来分配当前对象，不得不提前出发FullGC。

新⽣代和⽼年代垃圾收集器

1.G1收集器-标记整理算法

JDK1.7后全新的回收器,⽤于取代CMS收集器。

G1收集器的优势：

1. 独特的分代垃圾回收器,分代GC: 分代收集器, 同时兼顾年轻代和⽼年代
2. 使⽤分区算法, 不要求eden, 年轻代或⽼年代的空间都连续
3. 并⾏性: 回收期间, 可由多个线程同时⼯作, 有效利⽤多核cpu资源
4. 空间整理: 回收过程中, 会进⾏适当对象移动, 减少空间碎⽚
5. 可预⻅性: G1可选取部分区域进⾏回收, 可以缩⼩回收范围, 减少全局停顿

G1收集器的运作⼤致可划分为⼀下步骤：

G1收集器的阶段分以下⼏个步骤：

1、初始标记（它标记了从GC Root开始直接可达的对象）

2、并发标记（从GC Roots开始对堆中对象进⾏可达性分析，找出存活对象）

3、最终标记（标记那些在并发标记阶段发⽣变化的对象，将被回收）

4、筛选回收（⾸先对各个Regin的回收价值和成本进⾏排序，根据⽤户所期待的GC停顿时间指定回收计划，回收⼀部分Region）

扩展内容

不同的业务需求，如何选择合理的垃圾回收器

深入详解JVM内存模型与JVM参数详细配置

题目描述

深入详解JVM内存模型与JVM参数详细配置？

面试题分析

JVM基本是BAT面试必考的内容，今天我们先从JVM内存模型开启详解整个JVM系列，希望看完整个系列后，可以轻松通过BAT关于JVM的考核。

1 JVM内存结构

由上图可以清楚的看到JVM的内存空间分为3大部分：

1. 堆内存
2. 方法区
3. 栈内存

其中栈内存可以再细分为**java虚拟机栈和本地方法栈,堆内存可以划分为新生代和老年代,**新生代中还可以再次划分为Eden区、From Survivor区和To Survivor区。

其中一部分是线程共享的，包括 Java 堆和方法区；另一部分是线程私有的，包括虚拟机栈和本地方法栈，以及程序计数器这一小部分内存。

2 堆内存（Heap）

java 堆（Java Heap）是Java 虚拟机所管理的内存中最大的一块。堆是被所有线程共享的区域，实在虚拟机启动时创建的。堆里面存放的都是对象的实例（new 出来的对象都存在堆中）。

此内存区域的唯一目的就是存放对象实例（new的对象），几乎所有的对象实例都在这里分配内存。

堆内存分为两个部分：年轻代和老年代。我们平常所说的垃圾回收，主要回收的就是堆区。更细一点划分新生代又可划分为Eden区和2个Survivor区（From Survivor和To Survivor）。

下图中的Perm代表的是永久代，但是注意永久代并不属于堆内存中的一部分，同时jdk1.8之后永久代已经被移除。

新生代 ( Young ) 与老年代 ( Old ) 的比例的值为 1:2 ( 该值可以通过参数 –XX:NewRatio 来指定 )

默认的，Eden : from : to = 8 : 1 : 1 ( 可以通过参数 –XX:SurvivorRatio 来设定 )，即： Eden = 8/10的新生代空间大小，from = to = 1/10 的新生代空间大小。

3 方法区（Method Area）

方法区也称”永久代“，它用于存储虚拟机加载的类信息、常量、静态变量、是各个线程共享的内存区域。

在JDK8之前的HotSpot JVM，存放这些”永久的”的区域叫做“永久代(permanent generation)”。永久代是一片连续的堆空间，在JVM启动之前通过在命令行设置参数-XX:MaxPermSize来设定永久代最大可分配的内存空间，默认大小是64M（64位JVM默认是85M）。

随着JDK8的到来，JVM不再有 永久代(PermGen)。但类的元数据信息（metadata）还在，只不过不再是存储在连续的堆空间上，而是移动到叫做“Metaspace”的本地内存（Native memory。

方法区或永生代相关设置

• -XX:PermSize=64MB 最小尺寸，初始分配

• -XX:MaxPermSize=256MB 最大允许分配尺寸，按需分配

• XX:+CMSClassUnloadingEnabled -XX:+CMSPermGenSweepingEnabled 设置垃圾不回收

• 默认大小

  • -server选项下默认MaxPermSize为64m
  • -client选项下默认MaxPermSize为32m

4 虚拟机栈(JVM Stack)

java虚拟机栈是线程私有，生命周期与线程相同。创建线程的时候就会创建一个java虚拟机栈。

虚拟机执行java程序的时候，每个方法都会创建一个栈帧，栈帧存放在java虚拟机栈中，通过压栈出栈的方式进行方法调用。

栈帧又分为一下几个区域：局部变量表、操作数栈、动态连接、方法出口等。

平时我们所说的变量存在栈中，这句话说的不太严谨，应该说局部变量存放在java虚拟机栈的局部变量表中。

java的8中基本类型的局部变量的值存放在虚拟机栈的局部变量表中，如果是引用型的变量，则只存储对象的引用地址。

5 本地方法栈(Native Stack)

本地方法栈（Native Method Stacks）与虚拟机栈所发挥的作用是非常相似的，其区别不过是虚拟机栈为虚拟机执行Java方法（也就是字节码）服务，而本地方法栈则是为虚拟机使用到的Native方法服务。

6 程序计数器（PC Register）

程序计数器就是记录当前线程执行程序的位置，改变计数器的值来确定执行的下一条指令，比如循环、分支、方法跳转、异常处理，线程恢复都是依赖程序计数器来完成。

Java虚拟机多线程是通过线程轮流切换并分配处理器执行时间的方式实现的。为了线程切换能恢复到正确的位置，每条线程都需要一个独立的程序计数器，所以它是线程私有的。

7 直接内存

直接内存并不是虚拟机内存的一部分，也不是Java虚拟机规范中定义的内存区域。jdk1.4中新加入的NIO，引入了通道与缓冲区的IO方式，它可以调用Native方法直接分配堆外内存，这个堆外内存就是本机内存，不会影响到堆内存的大小。

8 JVM内存参数设置

• -Xms设置堆的最小空间大小。

• -Xmx设置堆的最大空间大小。

• -Xmn:设置年轻代大小

• -XX:NewSize设置新生代最小空间大小。

• -XX:MaxNewSize设置新生代最大空间大小。

• -XX:PermSize设置永久代最小空间大小。

• -XX:MaxPermSize设置永久代最大空间大小。

• -Xss设置每个线程的堆栈大小

• -XX:+UseParallelGC:选择垃圾收集器为并行收集器。此配置仅对年轻代有效。即上述配置下,年轻代使用并发收集,而年老代仍旧使用串行收集。

• -XX:ParallelGCThreads=20:配置并行收集器的线程数,即:同时多少个线程一起进行垃圾回收。此值最好配置与处理器数目相等。

9 典型JVM参数配置参考

• java-Xmx3550m-Xms3550m-Xmn2g-Xss128k

• -XX:ParallelGCThreads=20

• -XX:+UseConcMarkSweepGC-XX:+UseParNewGC

-Xmx3550m:设置JVM最大可用内存为3550M。

-Xms3550m:设置JVM促使内存为3550m。此值可以设置与-Xmx相同,以避免每次垃圾回收完成后JVM重新分配内存。

-Xmn2g:设置年轻代大小为2G。整个堆大小=年轻代大小+年老代大小+持久代大小。持久代一般固定大小为64m,所以增大年轻代后,将会减小年老代大小。此值对系统性能影响较大,官方推荐配置为整个堆的3/8。

-Xss128k:设置每个线程的堆栈大小。JDK5.0以后每个线程堆栈大小为1M,以前每个线程堆栈大小为256K。更具应用的线程所需内存大小进行调整。在相同物理内存下,减小这个值能生成更多的线程。但是操作系统对一个进程内的线程数还是有限制的,不能无限生成,经验值在3000~5000左右。

java性能优化，有哪些衡量指标？需要注意什么？

主要从理论分析入手来介绍性能优化的衡量指标，及其理论方法和注意点。

指标是我们衡量很多事物，以及做出行为决策的重要参考。例如在生活中，当你打算买汽车时，会关注很多指标，比如动力性、燃油经济性、制动性、操纵稳定性、平顺性、通过性、排放与噪声等，而这些指标也都有相关的测试和参数，同时也会对这些指标进行一一参考。

这个道理大家都懂，但一旦到了性能优化上，却往往因为缺乏理论依据而选择了错误的优化方向，陷入了盲猜的窘境。在衡量一项优化是否能达到目的之时，不能仅靠感觉，它同样有一系列的指标来衡量你的改进。如果在改动之后，性能不升反降，那就不能叫性能优化了。

所谓性能，就是使用有限的资源在有限的时间内完成工作。最主要的衡量因素就是时间，所以很多衡量指标，都可以把时间作为横轴。

加载缓慢的网站，会受到搜索排名算法的惩罚，从而导致网站排名下降。 因此加载的快慢是性能优化是否合理的一个非常直观的判断因素，但性能指标不仅仅包括单次请求的速度，它还包含更多因素。

接下来看一下，都有哪些衡量指标能够帮我们进行决策。

衡量指标有哪些？

1.吞吐量和响应速度

分布式的高并发应用并不能把单次请求作为判断依据，它往往是一个统计结果。其中最常用的衡量指标就是吞吐量和响应速度，而这两者也是考虑性能时非常重要的概念。要理解这两个指标的意义，我们可以类比为交通环境中的十字路口。

在交通非常繁忙的情况下，十字路口是典型的瓶颈点，当红绿灯放行时间非常长时，后面往往会排起长队。

从我们开车开始排队，到车经过红绿灯，这个过程所花费的时间，就是响应时间。

当然，我们可以适当地调低红绿灯的间隔时间，这样对于某些车辆来说，通过时间可能会短一些。但是，如果信号灯频繁切换，反而会导致单位时间内通过的车辆减少，换一个角度，我们也可以认为这个十字路口的车辆吞吐量减少了。

像我们平常开发中经常提到的，QPS 代表每秒查询的数量，TPS 代表每秒事务的数量，HPS 代表每秒的HTTP 请求数量等，这都是常用的与吞吐量相关的量化指标。

在性能优化的时候，我们要搞清楚优化的目标，到底是吞吐量还是响应速度。 有些时候，虽然响应速度比较慢，但整个吞吐量却非常高，比如一些数据库的批量操作、一些缓冲区的合并等。虽然信息的延迟增加了，但如果我们的目标就是吞吐量，那么这显然也可以算是比较大的性能提升。

一般情况下，我们认为：

响应速度是串行执行的优化，通过优化执行步骤解决问题；

吞吐量是并行执行的优化，通过合理利用计算资源达到目标。

我们平常的优化主要侧重于响应速度，因为一旦响应速度提升了，那么整个吞吐量自然也会跟着提升。

但对于高并发的互联网应用来说，响应速度和吞吐量两者都需要。这些应用都会标榜为高吞吐、高并发的场景，用户对系统的延迟忍耐度很差，我们需要使用有限的硬件资源，从中找到一个平衡点。

2.响应时间衡量

既然响应时间这么重要，我们就着重看一下响应时间的衡量方法。

（1）平均响应时间

我们最常用的指标，即平均响应时间(AVG)，该指标能够体现服务接口的平均处理能力。它的本质是把所有的请求耗时加起来，然后除以请求的次数。举个最简单的例子，有 10 个请求，其中有 2 个 1ms、3 个 5ms、5 个 10ms，那么它的平均耗时就是(21+35+5*10)/10=6.7ms。

除非服务在一段时间内出现了严重的问题，否则平均响应时间都会比较平缓。因为高并发应用请求量都特别大，所以长尾请求的影响会被很快平均，导致很多用户的请求变慢，但这不能体现在平均耗时指标中。

为了解决这个问题，另外一个比较常用的指标，就是百分位数(Percentile)。

（2）百分位数

这个也比较好理解。我们圈定一个时间范围，把每次请求的耗时加入一个列表中，然后按照从小到大的顺序将这些时间进行排序。这样，我们取出特定百分位的耗时，这个数字就是 TP 值。可以看到，TP 值(Top Percentile)和中位数、平均数等是类似的，都是一个统计学里的术语。

它的意义是，超过 N% 的请求都在 X 时间内返回。比如 TP90 = 50ms，意思是超过 90th 的请求，都在50ms 内返回。

这个指标也是非常重要的，它能够反映出应用接口的整体响应情况。比如，某段时间若发生了长时间的GC，那它的某个时间段之上的指标就会产生严重的抖动，但一些低百分位的数值却很少有变化。

我们一般分为 TP50、TP90、TP95、TP99、TP99.9 等多个段，对高百分位的值要求越高，对系统响应能力的稳定性要求越高。

在这些高稳定性系统中，目标就是要干掉严重影响系统的长尾请求。这部分接口性能数据的收集，我们会采用更加详细的日志记录方式，而不仅仅靠指标。比如，我们将某个接口，耗时超过 1s 的入参及执行步骤，详细地输出在日志系统中。

3.并发量

并发量是指系统同时能处理的请求数量，这个指标反映了系统的负载能力。

在高并发应用中，仅仅高吞吐是不够的，它还必须同时能为多个用户提供服务。并发高时，会导致很严重的共享资源争用问题，我们需要减少资源冲突，以及长时间占用资源的行为。

针对响应时间进行设计，一般来说是万能的。因为响应时间减少，同一时间能够处理的请求必然会增加。值得注意的是，即使是一个秒杀系统，经过层层过滤处理，最终到达某个节点的并发数，大概也就五六十左右。我们在平常的设计中，除非并发量特别低，否则都不需要太过度关注这个指标。

4.秒开率

在移动互联网时代，尤其对于 App 中的页面，秒开是一种极佳的用户体验。如果能在 1 秒内加载完成页面，那用户可以获得流畅的体验，并且不会产生更多的焦虑感。

通常而言，可以根据业务情况设定不同的页面打开标准，比如低于 1 秒内的数据占比是秒开率。业界优秀的公司，比如手淘，其页面的秒开率基本可达到 80% 以上。

5.正确性

说一个比较有意思的事情。我们有个技术团队，在进行测试的时候，发现接口响应非常流畅，把并发数增加到 20 以后，应用接口响应依旧非常迅速。

但等应用真正上线时，却发生了重大事故，这是因为接口返回的都是无法使用的数据。

其问题原因也比较好定位，就是项目中使用了熔断。在压测的时候，接口直接超出服务能力，触发熔断了，但是压测并没有对接口响应的正确性做判断，造成了非常低级的错误。

所以在进行性能评估的时候，不要忘记正确性这一关键要素。

有哪些理论方法？

性能优化有很多理论方法，比如木桶理论、基础测试、Amdahl 定律等。下面我们简单地讲解一下最常用的两个理论。

1.木桶理论

一只木桶若想要装最多的水，则需要每块木板都一样长而且没有破损才行。如果有一块木板不满足条件，那么这只桶就无法装最多的水。

能够装多少水，取决于最短的那块木板，而不是最长的那一块。

木桶效应在解释系统性能上，也非常适合。组成系统的组件，在速度上是良莠不齐的。系统的整体性能，就取决于系统中最慢的组件。

比如，在数据库应用中，制约性能最严重的是落盘的 I/O 问题，也就是说，硬盘是这个场景下的短板，我们首要的任务就是补齐这个短板。

2.基准测试、预热

基准测试(Benchmark)并不是简单的性能测试，是用来测试某个程序的最佳性能。

应用接口往往在刚启动后都有短暂的超时。在测试之前，我们需要对应用进行预热，消除 JIT 编译器等因素的影响。而在 Java 里就有一个组件，即 JMH，就可以消除这些差异。

注意点

1.依据数字而不是猜想

有些同学对编程有很好的感觉，能够靠猜测列出系统的瓶颈点，这种情况固然存在，但却非常不可取。

复杂的系统往往有多个影响因素，我们应将性能分析放在第一位，把性能优化放在次要位置，直觉只是我们的辅助，但不能作为下结论的工具。

进行性能优化时，我们一般会把分析后的结果排一个优先级（根据难度和影响程度），从大处着手，首先击破影响最大的点，然后将其他影响因素逐一击破。

有些优化会引入新的性能问题，有时候这些新问题会引起更严重的性能下降，你需要评估这个连锁反应，确保这种优化确实需要，同时需要使用数字去衡量这个过程，而不是靠感觉猜想。

2.个体数据不足信

你是否有这样的经历：某个知名网站的访问速度真慢，光加载就花费了 x 秒。其实，仅凭一个人的一次请求，就下了“慢”这个结论，是不合适的，而在我们进行性能评估的时候，也往往会陷入这样的误区。

这是因为个体请求的小批量数据，可参考价值并不是非常大。响应时间可能因用户的数据而异，也可能取决于设备和网络条件。

合理的做法，是从统计数据中找到一些规律，比如上面所提到的平均响应时间、TP 值等，甚至是响应时间分布的直方图，这些都能够帮我们评估性能质量。

3.不要过早优化和过度优化

虽然性能优化有这么多好处，但并不代表我们要把每个地方都做到极致，性能优化也是要有限度的。程序要运行地正确，要比程序运行得更快还要困难。

计算机科学的鼻祖"Donald Knuth" 曾说：“过早的优化是万恶之源”，就是这个道理。

如果一项改进并不能产生明显的价值，那我们为什么还要花大力气耗在上面呢？比如，某个应用已经满足了用户的吞吐量需求和响应需求，但有的同学热衷于 JVM 的调优，依然花很大力气在参数测试上，这种优化就属于过度优化。

时间要花在刀刃上，我们需要找到最迫切需要解决的性能点，然后将其击破。比如，一个系统主要是慢在了数据库查询上，结果你却花了很大的精力去优化 Java 编码规范，这就是偏离目标的典型情况。

一般地，性能优化后的代码，由于太过于追求执行速度，读起来都比较晦涩，在结构上也会有很多让步。很显然，过早优化会让这种难以维护的特性过早介入到你的项目中，等代码重构的时候，就会花更大的力气去解决它。

正确的做法是，项目开发和性能优化，应该作为两个独立的步骤进行，要做性能优化，要等到整个项目的架构和功能大体进入稳定状态时再进行。

4.保持良好的编码习惯

我们上面提到，不要过早地优化和过度优化，但并不代表大家在编码时就不考虑这些问题。

比如，保持好的编码规范，就可以非常方便地进行代码重构；使用合适的设计模式，合理的划分模块，就可以针对性能问题和结构问题进行聚焦、优化。

在追求高性能、高质量编码的过程中，一些好的习惯都会积累下来，形成人生道路上优秀的修养和品质，这对我们是大有裨益的。

小结

在本课时，我们简单地了解了衡量性能的一些指标，比如常见的吞吐量和响应速度，还探讨了一些其他的影响因素，比如并发量、秒开率、容错率等。

同时，我们也谈到了木桶理论和基准测试等两种过程方法，并对性能测试中的一些误区和注意点进行了介绍，现在你应该对如何描述性能有了更好的理解。像一些专业的性能测试软件，如 JMeter、LoadRunner 等，就是在这些基础性能指标上进行的扩展。我们在平常的工作中，也应该尽量使用专业术语，这样才能对系统性能进行正确评估。

VM的4种垃圾回收算法、垃圾回收机制

题目描述

JVM的4种垃圾回收算法、垃圾回收机制？

面试题分析

可以从垃圾回收算法，垃圾回收机制 等方面进行介绍

垃圾回收算法

1.标记清除

标记-清除算法将垃圾回收分为两个阶段：标记阶段和清除阶段。

在标记阶段首先通过根节点(GC Roots)，标记所有从根节点开始的对象，未被标记的对象就是未被引用的垃圾对象。然后，在清除阶段，清除所有未被标记的对象

适用场合：

• 存活对象较多的情况下比较高效

• 适用于年老代（即旧生代）

缺点：

• 容易产生内存碎片，再来一个比较大的对象时（典型情况：该对象的大小大于空闲表中的每一块儿大小但是小于其中两块儿的和），会提前触发垃圾回收

• 扫描了整个空间两次（第一次：标记存活对象；第二次：清除没有标记的对象）

2.复制算法

从根集合节点进行扫描，标记出所有的存活对象，并将这些存活的对象复制到一块儿新的内存（图中下边的那一块儿内存）上去，之后将原来的那一块儿内存（图中上边的那一块儿内存）全部回收掉

现在的商业虚拟机都采用这种收集算法来回收新生代。

适用场合：

• 存活对象较少的情况下比较高效

• 扫描了整个空间一次（标记存活对象并复制移动）

• 适用于年轻代（即新生代）：基本上98%的对象是”朝生夕死”的，存活下来的会很少

缺点：

• 需要一块儿空的内存空间

• 需要复制移动对象

3.标记整理

复制算法的高效性是建立在存活对象少、垃圾对象多的前提下的。

这种情况在新生代经常发生，但是在老年代更常见的情况是大部分对象都是存活对象。如果依然使用复制算法，由于存活的对象较多，复制的成本也将很高。

标记-压缩算法是一种老年代的回收算法，它在标记-清除算法的基础上做了一些优化。

首先也需要从根节点开始对所有可达对象做一次标记，但之后，它并不简单地清理未标记的对象，而是将所有的存活对象压缩到内存的一端。之后，清理边界外所有的空间。这种方法既避免了碎片的产生，又不需要两块相同的内存空间，因此，其性价比比较高。

4.分代收集算法

分代收集算法就是目前虚拟机使用的回收算法，它解决了标记整理不适用于老年代的问题，将内存分为各个年代。一般情况下将堆区划分为老年代（Tenured Generation）和新生代（Young Generation），在堆区之外还有一个代就是永久代（Permanet Generation）。

在不同年代使用不同的算法，从而使用最合适的算法，新生代存活率低，可以使用复制算法。而老年代对象存活率搞，没有额外空间对它进行分配担保，所以只能使用标记清除或者标记整理算法。

垃圾回收机制

年轻代分为Eden区和survivor区（两块儿：from和to），且Eden:from:to==8:1:1。

jvm内存结构

1）新产生的对象优先分配在Eden区（除非配置了-XX:PretenureSizeThreshold，大于该值的对象会直接进入年老代）；

2）当Eden区满了或放不下了，这时候其中存活的对象会复制到from区。

这里，需要注意的是，如果存活下来的对象from区都放不下，则这些存活下来的对象全部进入年老代。之后Eden区的内存全部回收掉。

3）之后产生的对象继续分配在Eden区，当Eden区又满了或放不下了，这时候将会把Eden区和from区存活下来的对象复制到to区（同理，如果存活下来的对象to区都放不下，则这些存活下来的对象全部进入年老代），之后回收掉Eden区和from区的所有内存。

4）如上这样，会有很多对象会被复制很多次（每复制一次，对象的年龄就+1），默认情况下，当对象被复制了15次（这个次数可以通过：-XX:MaxTenuringThreshold来配置），就会进入年老代了。

5）当年老代满了或者存放不下将要进入年老代的存活对象的时候，就会发生一次Full GC（这个是我们最需要减少的，因为耗时很严重）。

垃圾回收有两种类型：Minor GC和Full GC。

1.Minor GC

对新生代进行回收，不会影响到年老代。因为新生代的 Java 对象大多死亡频繁，所以 Minor GC 非常频繁，一般在这里使用速度快、效率高的算法，使垃圾回收能尽快完成。

2.Full GC

也叫Major GC，对整个堆进行回收，包括新生代和老年代。由于Full GC需要对整个堆进行回收，所以比Minor GC要慢，因此应该尽可能减少Full GC的次数，导致Full

GC的原因包括：老年代被写满、永久代（Perm）被写满和System.gc()被显式调用等。

垃圾回收算法总结

1.年轻代：复制算法

1)所有新生成的对象首先都是放在年轻代的。年轻代的目标就是尽可能快速的收集掉那些生命周期短的对象。

2)新生代内存按照8:1:1的比例分为一个eden区和两个survivor(survivor0,survivor1)区。一个Eden区，两个Survivor区(一般而言)。大部分对象在Eden区中生成。回收时先将eden区存活对象复制到一个survivor0区，然后清空eden区，当这个survivor0区也存放满了时，则将eden区和survivor0区存活对象复制到另一个survivor1区，然后清空eden和这个survivor0区，此时survivor0区是空的，然后将survivor0区和survivor1区交换，即保持survivor1区为空，如此往复。

3)当survivor1区不足以存放 eden和survivor0的存活对象时，就将存活对象直接存放到老年代。若是老年代也满了就会触发一次Full GC(Major GC)，也就是新生代、老年代都进行回收。

4)新生代发生的GC也叫做Minor GC，MinorGC发生频率比较高(不一定等Eden区满了才触发)。

2.年老代：标记-清除或标记-整理

1)在年轻代中经历了N次垃圾回收后仍然存活的对象，就会被放到年老代中。因此，可以认为年老代中存放的都是一些生命周期较长的对象。

2)内存比新生代也大很多(大概比例是1:2)，当老年代内存满时触发Major GC即Full GC，Full GC发生频率比较低，老年代对象存活时间比较长，存活率标记高。

以上这种年轻代与年老代分别采用不同回收算法的方式称为”分代收集算法”，这也是当下企业使用的一种方式

3)每一种算法都会有很多不同的垃圾回收器去实现，在实际使用中，根据自己的业务特点做出选择就好。

JVM内存调优

题目描述

JVM内存调优？

面试题分析

对JVM内存的系统级的调优主要的目的是减少GC的频率和Full GC的次数

JVM内存调优

1.Full GC

会对整个堆进行整理，包括Young、Tenured和Perm。Full GC因为需要对整个堆进行回收，所以比较慢，因此应该尽可能减少Full GC的次数。

2.导致Full GC的原因

1)年老代（Tenured）被写满

调优时尽量让对象在新生代GC时被回收、让对象在新生代多存活一段时间和不要创建过大的对象及数组避免直接在旧生代创建对象 。

2)持久代Pemanet Generation空间不足

增大Perm Gen空间，避免太多静态对象 ， 控制好新生代和旧生代的比例

3)System.gc()被显示调用

垃圾回收不要手动触发，尽量依靠JVM自身的机制

在对JVM调优的过程中，很大一部分工作就是对于FullGC的调节，下面详细介绍对应JVM调优的方法和步骤。

JVM性能调优方法和步骤

1.监控GC的状态

使用各种JVM工具，查看当前日志，分析当前JVM参数设置，并且分析当前堆内存快照和gc日志，根据实际的各区域内存划分和GC执行时间，觉得是否进行优化。

举一个例子：系统崩溃前的一些现象：

• 每次垃圾回收的时间越来越长，由之前的10ms延长到50ms左右，FullGC的时间也有之前的0.5s延长到4、5s

• FullGC的次数越来越多，最频繁时隔不到1分钟就进行一次FullGC

• 年老代的内存越来越大并且每次FullGC后年老代没有内存被释放

之后系统会无法响应新的请求，逐渐到达OutOfMemoryError的临界值，这个时候就需要分析JVM内存快照dump。

2.生成堆的dump文件

通过JMX的MBean生成当前的Heap信息，大小为一个3G（整个堆的大小）的hprof文件，如果没有启动JMX可以通过Java的jmap命令来生成该文件。

3.分析dump文件

打开这个3G的堆信息文件，显然一般的Window系统没有这么大的内存，必须借助高配置的Linux，几种工具打开该文件：

• Visual VM

• IBM HeapAnalyzer

• JDK 自带的Hprof工具

• Mat(Eclipse专门的静态内存分析工具)推荐使用

备注：文件太大，建议使用Eclipse专门的静态内存分析工具Mat打开分析。

4.分析结果，判断是否需要优化

如果各项参数设置合理，系统没有超时日志出现，GC频率不高，GC耗时不高，那么没有必要进行GC优化，如果GC时间超过1-3秒，或者频繁GC，则必须优化。

注：如果满足下面的指标，则一般不需要进行GC：

• Minor GC执行时间不到50ms；

• Minor GC执行不频繁，约10秒一次；

• Full GC执行时间不到1s；

• Full GC执行频率不算频繁，不低于10分钟1次；

5.调整GC类型和内存分配

如果内存分配过大或过小，或者采用的GC收集器比较慢，则应该优先调整这些参数，并且先找1台或几台机器进行beta，然后比较优化过的机器和没有优化的机器的性能对比，并有针对性的做出最后选择。

6.不断的分析和调整

通过不断的试验和试错，分析并找到最合适的参数，如果找到了最合适的参数，则将这些参数应用到所有服务器。

cms参数优化步流程

JVM调优参数参考

• 1.针对JVM堆的设置，一般可以通过-Xms -Xmx限定其最小、最大值，为了防止垃圾收集器在最小、最大之间收缩堆而产生额外的时间，通常把最大、最小设置为相同的值;

• 2.年轻代和年老代将根据默认的比例（1：2）分配堆内存， 可以通过调整二者之间的比率NewRadio来调整二者之间的大小，也可以针对回收代。

比如年轻代，通过 -XX:newSize -XX:MaxNewSize来设置其绝对大小。同样，为了防止年轻代的堆收缩，我们通常会把-XX:newSize -XX:MaxNewSize设置为同样大小。

• 3.年轻代和年老代设置多大才算合理

1）更大的年轻代必然导致更小的年老代，大的年轻代会延长普通GC的周期，但会增加每次GC的时间；小的年老代会导致更频繁的Full GC

2）更小的年轻代必然导致更大年老代，小的年轻代会导致普通GC很频繁，但每次的GC时间会更短；大的年老代会减少Full GC的频率

如何选择应该依赖应用程序对象生命周期的分布情况： 如果应用存在大量的临时对象，应该选择更大的年轻代；如果存在相对较多的持久对象，年老代应该适当增大。但很多应用都没有这样明显的特性。

在抉择时应该根据以下两点：

（1）本着Full GC尽量少的原则，让年老代尽量缓存常用对象，JVM的默认比例1：2也是这个道理 。

（2）通过观察应用一段时间，看其他在峰值时年老代会占多少内存，在不影响Full GC的前提下，根据实际情况加大年轻代，比如可以把比例控制在1：1。但应该给年老代至少预留1/3的增长空间。

• 4.在配置较好的机器上（比如多核、大内存），可以为年老代选择并行收集算法： -XX:+UseParallelOldGC。

• 5.线程堆栈的设置：每个线程默认会开启1M的堆栈，用于存放栈帧、调用参数、局部变量等，对大多数应用而言这个默认值太了，一般256K就足用。

理论上，在内存不变的情况下，减少每个线程的堆栈，可以产生更多的线程，但这实际上还受限于操作系统。

Jvm组成，运行时区，堆、栈、队列的区别

题目描述

JVM主要组成部分?及其作用?

组成部分:

• 类的加载器(ClassLoader)
• 运行时数据区(Runtime Data Area)
• 执行引擎(Execution Engine)
• 本地库接口(Native Interface)

**组件作用:**首先通过类加载器(ClassLoader)会把java代码转换为字节码，运行时数据区(RuntimeData Area)会把再把字节码加载到内存中,而字节码文件只是JVM的一套指令规范，并不能直接交给底层操作系统去执行，因此需要特定命令解析器执行引擎(Execution Engine),将字节码翻译成底层系统指令，再交由CDu执行，而这个过程中需要调用其他语言的本地接口(NativeInterface)来实现整个程序的功能。

JVM运行时数据区

• 程序计数器
• 虚拟机栈
• 本地方法栈
• 堆
• 方法区

有的区域随着虚拟机进程的启动而存在，有的区域则依赖用户进程的启动和结束而创建销毁的。

堆栈有什么区别

• 栈内存存储的是局部变量，而堆内存存储的是实体。
• 栈内存快于堆内存，因为局部变量生命周期很短。
• 栈内存存放的变量生命周期一旦结束就会被释放,而堆内存对象会被垃圾回收，机制不定时回收。

队列和堆栈是什么?有什么区别?

• 队列和栈都是被用来预存数据的。
• 队列允许先进先出检查元素，但也有例外情况。Deque接口允许从两端检索元素。
• 栈和队列相似，但他运行对元素后进先出进行检索。

说一下类加载的过程

类加载分为五个部分:

• 加载: 根据查找路径找到相对应的class文件然后导入
• 检查: 检查加载的class文件的正确性
• 准备: 给类中静态变量分配内存空间
• 解析:虚拟机将常量池中的符号引用替换成直接引用的过程。符号引用就理解为一个标示，而在直接引用直接指向内存地址中。
• 初始化: 对静态变量和静态代码块执行初始化工作

怎么判断对象是否可以被回收。

**引用计数器:**为每一个对象创建一个引用计数，有对象引用是计数器+1,引用被释放时-1，当计数器为0时就可以被回收。 当然这样有一个缺点，不能解决循环引用的问题。

**可达性分析:**从GC ROOTS开始向下搜索，搜索走过的路径成为引用链。当一个对象到GC Roots没有任何引用相连接的时候，则证明此链接可以被回收。