星型模型：当所有的维度表都是和事实表直接相连的时候，整个图形看上去就像是一个星星，我们称之为星型模型。星型模型是一种非正规化的架构，因为多维数据集的每一个维度都和事实表直接相连，不存在渐变维度，所以有一定的数据冗余，因为有数据的冗余，很多的统计情况下，不需要和外表关联进行查询和数据分析，因此效率相对较高。
雪花模型：当有多个维度表没有直接和事实表相连，而是通过其它的维度表，间接的连接在事实表上，其图形就像是一个雪花，因此我们称之为雪花模型，雪花模型的优点是减少了数据冗余，在进行数据统计或分析的时候，需要和其他的表进行关联。
1、查询性能角度来看
星形模型做了字段冗余，不需要多表关联，性能较高。
雪花型要做多个表联接，性能会低于星型架构；
2、模型复杂度角度
星型模型设计简单
雪花模型设计复杂
3、可扩展性
星形模型可扩展性低
雪花模型可扩展性高
4、存储角度
雪花型架构具有关系数据模型的所有优点，不会产生冗余数据，
而相比之下星型架构会产生数据冗余。
1、分区和分桶都是细化数据管理，但是分区表是手动添加区分，由于hive是读模式，所以对添加进分区的数据不做模式校验。分桶表的数据时按住某些分桶字段进行hash散列 相乘的多个文件，所以数据的准确性高很多
2、分区表是指按照数据表的某列或某些列分为多个区，区从形式上可以理解为文件夹
3、分桶是相对分区进行更细粒度的划分。分桶将整个数据内容按照某列属性值的hash值进行区分，如要按照name属性分为3个桶，就是对name属性值的hash值对3取摸，按照取模结果对数据分桶。如取模结果为0的数据记录存放到一个文件，取模为1的数据存放到一个文件，取模为2的数据存放到一个文件
1、从概念是：
分区是将数据集分类为n个数据集
分桶是将一个完整的数据集分成若干部分
2、从表现形式上：
分区表是一个目录，分桶表是文件
3、从创建语句上：
分区表使用partitioned by 子句指定，以指定字段为伪列，需要指定字段类型
分桶表由clustered by 子句指定，指定字段为真实字段，需要指定桶的个数
4、从数量上：
分区表的分区个数可以增长，分桶表一旦指定，不能再增长
5、从作用上：
分区避免全表扫描，根据分区列查询指定目录提高查询速度
分桶保存分桶查询结果的分桶结构（数据已经按照分桶字段进行了hash散列）。
分桶表数据进行抽样和JOIN时可以提高MR程序效率
本文转自IO 流简介
IO 即 Input/Output，输入和输出。数据输入到计算机内存的过程即输入，反之输出到外部存储（比如数据库，文件，远程主机）的过程即输出。数据传输过程类似于水流，因此称为 IO 流。IO 流在 Java 中分为输入流和输出流，而根据数据的处理方式又分为字节流和字符流。
Java IO 流的 40 多个类都是从如下 4 个抽象类基类中派生出来的。
InputStream/Reader: 所有的输入流的基类，前者是字节输入流，后者是字符输入流。OutputStream/Writer: 所有输出流的基类，前者是字节输出流，后者是字符输出流。InputStream用于从源头（通常是文件）读取数据（字节信息）到内存中，java.io.InputStream抽象类是所有字节输入流的父类。
InputStream 常用方法 ：
read() ：返回输入流中下一个字节的数据。返回的值介于 0 到 255 之间。如果未读取任何字节，则代码返回 -1 ，表示文件结束。read(byte b[ ]) : 从输入流中读取一些字节存储到数组 b 中。如果数组 b 的长度为零，则不读取。如果没有可用字节读取，返回 -1。如果有可用字节读取，则最多读取的字节数最多等于 b.length ， 返回读取的字节数。这个方法等价于 read(b, 0, b.length)。read(byte b[], int off, int len) ：在read(byte b[ ]) 方法的基础上增加了 off 参数（偏移量）和 len 参数（要读取的最大字节数）。skip(long n) ：忽略输入流中的 n 个字节 ,返回实际忽略的字节数。available() ：返回输入流中可以读取的字节数。close() ：关闭输入流释放相关的系统资源。从 Java 9 开始，InputStream 新增加了多个实用的方法：
readAllBytes() ：读取输入流中的所有字节，返回字节数组。readNBytes(byte[] b, int off, int len) ：阻塞直到读取 len 个字节。transferTo(OutputStream out) ： 将所有字节从一个输入流传递到一个输出流。FileInputStream 是一个比较常用的字节输入流对象，可直接指定文件路径，可以直接读取单字节数据，也可以读取至字节数组中。
FileInputStream 代码示例：
1 | try (InputStream fis = new FileInputStream("input.txt)) { |
input.txt 文件内容：
输出：
1 | Number of remaining bytes:11 |
不过，一般我们是不会直接单独使用 FileInputStream ，通常会配合 BufferedInputStream（字节缓冲输入流，后文会讲到）来使用。
像下面这段代码在我们的项目中就比较常见，我们通过 readAllBytes() 读取输入流所有字节并将其直接赋值给一个 String 对象。
1 | // 新建一个 BufferedInputStream 对象 |
DataInputStream 用于读取指定类型数据，不能单独使用，必须结合 FileInputStream 。
1 | FileInputStream fileInputStream = new FileInputStream("input.txt"); |
ObjectInputStream 用于从输入流中读取 Java 对象（反序列化），ObjectOutputStream 用于将对象写入到输出流(序列化)。
1 | ObjectInputStream input = new ObjectInputStream(new FileInputStream("object.data")); |
另外，用于序列化和反序列化的类必须实现 Serializable 接口，对象中如果有属性不想被序列化，使用 transient 修饰。
OutputStream用于将数据（字节信息）写入到目的地（通常是文件），java.io.OutputStream抽象类是所有字节输出流的父类。
OutputStream 常用方法 ：
write(int b) ：将特定字节写入输出流。write(byte b[ ]) : 将数组b 写入到输出流，等价于 write(b, 0, b.length) 。write(byte[] b, int off, int len) : 在write(byte b[ ]) 方法的基础上增加了 off 参数（偏移量）和 len 参数（要读取的最大字节数）。flush() ：刷新此输出流并强制写出所有缓冲的输出字节。close() ：关闭输出流释放相关的系统资源。FileOutputStream 是最常用的字节输出流对象，可直接指定文件路径，可以直接输出单字节数据，也可以输出指定的字节数组。
FileOutputStream 代码示例：
1 | try (FileOutputStream output = new FileOutputStream("output.txt")) { |
运行结果：
类似于 FileInputStream，FileOutputStream 通常也会配合 BufferedOutputStream（字节缓冲输出流，后文会讲到）来使用。
1 | FileOutputStream fileOutputStream = new FileOutputStream("output.txt"); |
DataOutputStream 用于写入指定类型数据，不能单独使用，必须结合 FileOutputStream
1 | // 输出流 |
ObjectOutputStream 用于从输入流中读取 Java 对象（ObjectInputStream,反序列化）或者将对象写入到输出流(ObjectOutputStream，序列化)。
1 | ObjectOutputStream output = new ObjectOutputStream(new FileOutputStream("file.txt") |
不管是文件读写还是网络发送接收，信息的最小存储单元都是字节。 那为什么 I/O 流操作要分为字节流操作和字符流操作呢？
个人认为主要有两点原因：
乱码问题这个很容易就可以复现，我们只需要将上面提到的 FileInputStream 代码示例中的 input.txt 文件内容改为中文即可，原代码不需要改动。
输出：
1 | Number of remaining bytes:9 |
可以很明显地看到读取出来的内容已经变成了乱码。
因此，I/O 流就干脆提供了一个直接操作字符的接口，方便我们平时对字符进行流操作。如果音频文件、图片等媒体文件用字节流比较好，如果涉及到字符的话使用字符流比较好。
字符流默认采用的是 Unicode 编码，我们可以通过构造方法自定义编码。顺便分享一下之前遇到的笔试题：常用字符编码所占字节数？utf8 :英文占 1 字节，中文占 3 字节，unicode：任何字符都占 2 个字节，gbk：英文占 1 字节，中文占 2 字节。
Reader用于从源头（通常是文件）读取数据（字符信息）到内存中，java.io.Reader抽象类是所有字符输入流的父类。
Reader 用于读取文本， InputStream 用于读取原始字节。
Reader 常用方法 ：
read() : 从输入流读取一个字符。read(char[] cbuf) : 从输入流中读取一些字符，并将它们存储到字符数组 cbuf中，等价于 read(cbuf, 0, cbuf.length) 。read(char[] cbuf, int off, int len) ：在read(char[] cbuf) 方法的基础上增加了 off 参数（偏移量）和 len 参数（要读取的最大字节数）。skip(long n) ：忽略输入流中的 n 个字符 ,返回实际忽略的字符数。close() : 关闭输入流并释放相关的系统资源。InputStreamReader 是字节流转换为字符流的桥梁，其子类 FileReader 是基于该基础上的封装，可以直接操作字符文件。
1 | // 字节流转换为字符流的桥梁 |
FileReader 代码示例：
1 | try (FileReader fileReader = new FileReader("input.txt");) { |
input.txt 文件内容：
输出：
1 | The actual number of bytes skipped:3 |
Writer用于将数据（字符信息）写入到目的地（通常是文件），java.io.Writer抽象类是所有字节输出流的父类。
Writer 常用方法 ：
write(int c) : 写入单个字符。write(char[] cbuf) ：写入字符数组 cbuf，等价于write(cbuf, 0, cbuf.length)。write(char[] cbuf, int off, int len) ：在write(char[] cbuf) 方法的基础上增加了 off 参数（偏移量）和 len 参数（要读取的最大字节数）。write(String str) ：写入字符串，等价于 write(str, 0, str.length()) 。write(String str, int off, int len) ：在write(String str) 方法的基础上增加了 off 参数（偏移量）和 len 参数（要读取的最大字节数）。append(CharSequence csq) ：将指定的字符序列附加到指定的 Writer 对象并返回该 Writer 对象。append(char c) ：将指定的字符附加到指定的 Writer 对象并返回该 Writer 对象。flush() ：刷新此输出流并强制写出所有缓冲的输出字符。close():关闭输出流释放相关的系统资源。OutputStreamWriter 是字符流转换为字节流的桥梁，其子类 FileWriter 是基于该基础上的封装，可以直接将字符写入到文件。
1 | // 字符流转换为字节流的桥梁 |
FileWriter 代码示例：
1 | try (Writer output = new FileWriter("output.txt")) { |
输出结果：
IO 操作是很消耗性能的，缓冲流将数据加载至缓冲区，一次性读取/写入多个字节，从而避免频繁的 IO 操作，提高流的传输效率。
字节缓冲流这里采用了装饰器模式来增强 InputStream 和OutputStream子类对象的功能。
举个例子，我们可以通过 BufferedInputStream（字节缓冲输入流）来增强 FileInputStream 的功能。
1 | // 新建一个 BufferedInputStream 对象 |
字节流和字节缓冲流的性能差别主要体现在我们使用两者的时候都是调用 write(int b) 和 read() 这两个一次只读取一个字节的方法的时候。由于字节缓冲流内部有缓冲区（字节数组），因此，字节缓冲流会先将读取到的字节存放在缓存区，大幅减少 IO 次数，提高读取效率。
我使用 write(int b) 和 read() 方法，分别通过字节流和字节缓冲流复制一个 524.9 mb 的 PDF 文件耗时对比如下：
1 | 使用缓冲流复制PDF文件总耗时:15428 毫秒 |
两者耗时差别非常大，缓冲流耗费的时间是字节流的 1/165。
测试代码如下:
1 |
|
如果是调用 read(byte b[]) 和 write(byte b[], int off, int len) 这两个写入一个字节数组的方法的话，只要字节数组的大小合适，两者的性能差距其实不大，基本可以忽略。
这次我们使用 read(byte b[]) 和 write(byte b[], int off, int len) 方法，分别通过字节流和字节缓冲流复制一个 524.9 mb 的 PDF 文件耗时对比如下：
1 | 使用缓冲流复制PDF文件总耗时:695 毫秒 |
两者耗时差别不是很大，缓冲流的性能要略微好一点点。
测试代码如下：
1 |
|
BufferedInputStream 从源头（通常是文件）读取数据（字节信息）到内存的过程中不会一个字节一个字节的读取，而是会先将读取到的字节存放在缓存区，并从内部缓冲区中单独读取字节。这样大幅减少了 IO 次数，提高了读取效率。
BufferedInputStream 内部维护了一个缓冲区，这个缓冲区实际就是一个字节数组，通过阅读 BufferedInputStream 源码即可得到这个结论。
1 | public |
缓冲区的大小默认为 8192 字节，当然了，你也可以通过 BufferedInputStream(InputStream in, int size) 这个构造方法来指定缓冲区的大小。
BufferedOutputStream 将数据（字节信息）写入到目的地（通常是文件）的过程中不会一个字节一个字节的写入，而是会先将要写入的字节存放在缓存区，并从内部缓冲区中单独写入字节。这样大幅减少了 IO 次数，提高了读取效率
1 | try (BufferedOutputStream bos = new BufferedOutputStream(new FileOutputStream("output.txt"))) { |
类似于 BufferedInputStream ，BufferedOutputStream 内部也维护了一个缓冲区，并且，这个缓存区的大小也是 8192 字节。
BufferedReader （字符缓冲输入流）和 BufferedWriter（字符缓冲输出流）类似于 BufferedInputStream（字节缓冲输入流）和BufferedOutputStream（字节缓冲输入流），内部都维护了一个字节数组作为缓冲区。不过，前者主要是用来操作字符信息。
下面这段代码大家经常使用吧？
1 | System.out.print("Hello！"); |
System.out 实际是用于获取一个 PrintStream 对象，print方法实际调用的是 PrintStream 对象的 write 方法。
PrintStream 属于字节打印流，与之对应的是 PrintWriter （字符打印流）。PrintStream 是 OutputStream 的子类，PrintWriter 是 Writer 的子类。
1 | public class PrintStream extends FilterOutputStream |
这里要介绍的随机访问流指的是支持随意跳转到文件的任意位置进行读写的 RandomAccessFile 。
RandomAccessFile 的构造方法如下，我们可以指定 mode（读写模式）。
1 | // openAndDelete 参数默认为 false 表示打开文件并且这个文件不会被删除 |
读写模式主要有下面四种：
r : 只读模式。rw: 读写模式rws: 相对于 rw，rws 同步更新对“文件的内容”或“元数据”的修改到外部存储设备。rwd : 相对于 rw，rwd 同步更新对“文件的内容”的修改到外部存储设备。文件内容指的是文件中实际保存的数据，元数据则是用来描述文件属性比如文件的大小信息、创建和修改时间。
RandomAccessFile 中有一个文件指针用来表示下一个将要被写入或者读取的字节所处的位置。我们可以通过 RandomAccessFile 的 seek(long pos) 方法来设置文件指针的偏移量（距文件开头 pos 个字节处）。如果想要获取文件指针当前的位置的话，可以使用 getFilePointer() 方法。
RandomAccessFile 代码示例：
1 | RandomAccessFile randomAccessFile = new RandomAccessFile(new File("input.txt"), "rw"); |
input.txt 文件内容：
输出：
1 | 读取之前的偏移量：0,当前读取到的字符A，读取之后的偏移量：1 |
input.txt 文件内容变为 ABCDEFGHIJK 。
RandomAccessFile 的 write 方法在写入对象的时候如果对应的位置已经有数据的话，会将其覆盖掉。
1 | RandomAccessFile randomAccessFile = new RandomAccessFile(new File("input.txt"), "rw"); |
假设运行上面这段程序之前 input.txt 文件内容变为 ABCD ，运行之后则变为 HIJK 。
RandomAccessFile 比较常见的一个应用就是实现大文件的 断点续传 。何谓断点续传？简单来说就是上传文件中途暂停或失败（比如遇到网络问题）之后，不需要重新上传，只需要上传那些未成功上传的文件分片即可。分片（先将文件切分成多个文件分片）上传是断点续传的基础。
RandomAccessFile 可以帮助我们合并文件分片，示例代码如下：
我在《Java 面试指北》中详细介绍了大文件的上传问题。
RandomAccessFile 的实现依赖于 FileDescriptor (文件描述符) 和 FileChannel （内存映射文件）。
本文转载自归并排序
归并排序是稳定排序，它也是一种十分高效的排序，能利用完全二叉树特性的排序一般性能都不会太差。java中Arrays.sort()采用了一种名为TimSort的排序算法，就是归并排序的优化版本。从上文的图中可看出，每次合并操作的平均时间复杂度为$O(n)$，而完全二叉树的深度为$|log2n|$。总的平均时间复杂度为$O(nlogn)$。而且，归并排序的最好，最坏，平均时间复杂度均为$O(nlogn)$。
归并排序（MERGE-SORT）是利用归并的思想实现的排序方法，该算法采用经典的分治（divide-and-conquer）策略（分治法将问题分(divide)成一些小的问题然后递归求解，而治(conquer)的阶段则将分的阶段得到的各答案”修补”在一起，即分而治之)。
可以看到这种结构很像一棵完全二叉树，本文的归并排序我们采用递归去实现（也可采用迭代的方式去实现）。分阶段可以理解为就是递归拆分子序列的过程，递归深度为log2n。
再来看看治阶段，我们需要将两个已经有序的子序列合并成一个有序序列，比如上图中的最后一次合并，要将[4,5,7,8]和[1,2,3,6]两个已经有序的子序列，合并为最终序列[1,2,3,4,5,6,7,8]，来看下实现步骤。
代码实现
1 | package sortdemo; |
执行结果
1 | [1, 2, 3, 4, 5, 6, 7, 8, 9] |
本文转载自 Java IO模型详解
I/O 一直是很多小伙伴难以理解的一个知识点，这篇文章我会将我所理解的 I/O 讲给你听，希望可以对你有所帮助。
I/O（Input/Outpu） 即输入／输出 。
我们先从计算机结构的角度来解读一下 I/O。
根据冯.诺依曼结构，计算机结构分为 5 大部分：运算器、控制器、存储器、输入设备、输出设备。
输入设备（比如键盘）和输出设备（比如显示器）都属于外部设备。网卡、硬盘这种既可以属于输入设备，也可以属于输出设备。
输入设备向计算机输入数据，输出设备接收计算机输出的数据。
从计算机结构的视角来看的话， I/O 描述了计算机系统与外部设备之间通信的过程。
我们再先从应用程序的角度来解读一下 I/O。
根据大学里学到的操作系统相关的知识：为了保证操作系统的稳定性和安全性，一个进程的地址空间划分为 用户空间（User space） 和 内核空间（Kernel space ） 。
像我们平常运行的应用程序都是运行在用户空间，只有内核空间才能进行系统态级别的资源有关的操作，比如文件管理、进程通信、内存管理等等。也就是说，我们想要进行 IO 操作，一定是要依赖内核空间的能力。
并且，用户空间的程序不能直接访问内核空间。
当想要执行 IO 操作时，由于没有执行这些操作的权限，只能发起系统调用请求操作系统帮忙完成。
因此，用户进程想要执行 IO 操作的话，必须通过 系统调用 来间接访问内核空间
我们在平常开发过程中接触最多的就是 磁盘 IO（读写文件） 和 网络 IO（网络请求和响应）。
从应用程序的视角来看的话，我们的应用程序对操作系统的内核发起 IO 调用（系统调用），操作系统负责的内核执行具体的 IO 操作。也就是说，我们的应用程序实际上只是发起了 IO 操作的调用而已，具体 IO 的执行是由操作系统的内核来完成的。
当应用程序发起 I/O 调用后，会经历两个步骤：
UNIX 系统下， IO 模型一共有 5 种： 同步阻塞 I/O、同步非阻塞 I/O、I/O 多路复用、信号驱动 I/O 和异步 I/O。
这也是我们经常提到的 5 种 IO 模型。
BIO 属于同步阻塞 IO 模型 。
同步阻塞 IO 模型中，应用程序发起 read 调用后，会一直阻塞，直到内核把数据拷贝到用户空间。
在客户端连接数量不高的情况下，是没问题的。但是，当面对十万甚至百万级连接的时候，传统的 BIO 模型是无能为力的。因此，我们需要一种更高效的 I/O 处理模型来应对更高的并发量。
Java 中的 NIO 于 Java 1.4 中引入，对应 java.nio 包，提供了 Channel , Selector，Buffer 等抽象。NIO 中的 N 可以理解为 Non-blocking，不单纯是 New。它是支持面向缓冲的，基于通道的 I/O 操作方法。 对于高负载、高并发的（网络）应用，应使用 NIO 。
Java 中的 NIO 可以看作是 I/O 多路复用模型。也有很多人认为，Java 中的 NIO 属于同步非阻塞 IO 模型。
跟着我的思路往下看看，相信你会得到答案！
我们先来看看 同步非阻塞 IO 模型。
同步非阻塞 IO 模型中，应用程序会一直发起 read 调用，等待数据从内核空间拷贝到用户空间的这段时间里，线程依然是阻塞的，直到在内核把数据拷贝到用户空间。
相比于同步阻塞 IO 模型，同步非阻塞 IO 模型确实有了很大改进。通过轮询操作，避免了一直阻塞。
但是，这种 IO 模型同样存在问题：应用程序不断进行 I/O 系统调用轮询数据是否已经准备好的过程是十分消耗 CPU 资源的。
这个时候，I/O 多路复用模型 就上场了。
IO 多路复用模型中，线程首先发起 select 调用，询问内核数据是否准备就绪，等内核把数据准备好了，用户线程再发起 read 调用。read 调用的过程（数据从内核空间 -> 用户空间）还是阻塞的。
目前支持 IO 多路复用的系统调用，有 select，epoll 等等。select 系统调用，目前几乎在所有的操作系统上都有支持。
- select 调用 ：内核提供的系统调用，它支持一次查询多个系统调用的可用状态。几乎所有的操作系统都支持。
- epoll 调用 ：linux 2.6 内核，属于 select 调用的增强版本，优化了 IO 的执行效率。
IO 多路复用模型，通过减少无效的系统调用，减少了对 CPU 资源的消耗。
Java 中的 NIO ，有一个非常重要的选择器 ( Selector ) 的概念，也可以被称为 多路复用器。通过它，只需要一个线程便可以管理多个客户端连接。当客户端数据到了之后，才会为其服务。
AIO 也就是 NIO 2。Java 7 中引入了 NIO 的改进版 NIO 2,它是异步 IO 模型。
异步 IO 是基于事件和回调机制实现的，也就是应用操作之后会直接返回，不会堵塞在那里，当后台处理完成，操作系统会通知相应的线程进行后续的操作。
目前来说 AIO 的应用还不是很广泛。Netty 之前也尝试使用过 AIO，不过又放弃了。这是因为，Netty 使用了 AIO 之后，在 Linux 系统上的性能并没有多少提升。
最后，来一张图，简单总结一下 Java 中的 BIO、NIO、AIO。
本文转自 深入理解JVM - 解读GC日志
这次的文章会根据实战来介绍如何看JVM的日志，看JVM日志说难也难，说容易也容易，更多的是需要时间去不断的尝试进行总结。
另外，因为代码的实际运行效果在不同的机器是不一样的！这篇文章使用的是jdk1.8.0_221 的版本，具体的系统配置查看：
主要内容还是以讲解如何阅读日志，同时不同的机器运行的结果不同，文章更多的是介绍如何解读参数：
参数配置案例
1、新生代5M
2、最大新生代内存5M
3、初始化堆内存大小10M
4、最大堆内存大小10M
5、新生代eden区域大小，或者说survior配比：8 代表 8:1:1
6、使用ParNew+CMS收集器
1 | -verbose:gc -Xms20M -Xmx20M -Xmn10M -XX:+PrintGCDetails -XX:SurvivorRatio=8 -XX:+UseSerialGC |
参数的含义：
先从最简单的方法开始，我们运行一个没有任何代码的Main方法
1 | public class MinorGcTest { |
注意下面的内容是运行一个空Main方法的日志内容。
1 | Heap |
解释：
首先看下第二行：def new generation total 9216K, used 3977K，很明显，说明新生代总大小为9216K也就是9M的空间大小，为什么是9M呢，因为这里计算的是8M的eden区域+1M的survior from区域，剩下一个survior to的区域加起来一共10M，而可用空间根据复制算法只有9M也是正确的。
然后看下：eden space 8192K, 48% used，可以看到即使不运行任何的代码我们也使用了4M左右的空间，那么这4M的空间是什么东西呢，这部分对象其实是JVM自身运行产生的一些对象，这里也会放到后面的文章进行解读。
Metaspace代表着元空间，由于JDK8没有了永久代，所以JDK8之前的JVM看到的内容在这里是不一样的。
下面来看下堆溢出的情况下GC的日志打印了哪些内容，JAVA异常的信息忽略了，因为影响我们看日志：
1 | -verbose:gc -Xms20M -Xmx20M -Xmn10M -XX:+PrintGCDetails -XX:SurvivorRatio=8 -XX:+UseSerialGC |
1 | byte[] allocation1, allocation2, allocation3, allocation4, allocation5; |
下面是日志的结果：
1 | [GC (Allocation Failure) [DefNew: 7909K->1023K(9216K), 0.0025258 secs] 7909K->3242K(19456K), 0.0025739 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] |
1 | [GC (Allocation Failure) [DefNew: 7909K->1023K(9216K), 0.0025258 secs] 7909K->3242K(19456K), 0.0025739 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] |
我们先看一下第一行，这里使用的是serrial收集器，所以可以看到新生代打印7909K->1023K(9216K)，表示一共可用空间9216KB，而垃圾此时占用了7909K，回收之后剩下1023K。第二部分：7909K->3242K(19456K)，表示整个堆的回收情况，19456K表示整个堆的可用空间，同样从堆大小可以看到从7909K回收到剩下3242K的存活对象。最后一部分：[Times: user=0.00 sys=0.00, real=0.00 secs] 表示停顿的时间，以毫秒为单位，因为此次的垃圾回收时间太短，所以没有金酸进去，user表示用户线程停顿时间，sys表示系统回收时间，real表示实际的停顿时间。
接着看一下full gc的日志，可以看到这里直接对于新生代和老年代回收内存之后发现几乎没有空间剩余，还是放不下20M的大对象，所以直接抛出了oom。
1 | [Full GC (Allocation Failure) [Tenured: 2217K->2198K(10240K), 0.0017918 secs] 2217K->2198K(19456K), [Metaspace: 3254K->3254K(1056768K)], 0.0018074 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] |
注意最后使用了parnew+cms的组合
1 | -verbose:gc |
同样是不执行任何的代码，结果和其他的收集器类似
1 | Heap |
如果我们把上面的参数去掉-XX:+UseConcMarkSweepGC，会出现下面的内容：
1 | Heap |
这里注意一下最后一句：
这里说明的是不推荐使用parNew+serrial的组合，并且说明在未来的版本中会废弃这种组合，实际上在JDK9中就已经完全禁止parnew+serrial的组合了
1 | Java HotSpot(TM) 64-Bit Server VM warning: Using the ParNew young collector with the Serial old collector is deprecated and will likely be removed in a future release |
根据上面的几个测试案例可以看到，阅读GC的日志还是比较简单的，但是实际运行又会发现由于各种因素的干扰，实际运行的结果会和预期的结果不一样，这里不需要过多的担心，因为只要掌握了基础的理论，在根据实践模拟不断的熟悉会发现JVM的垃圾回收规律基本还是符合我们的理论基础介绍的。
如果对于对象分配策略的感兴趣可以阅读之前个人的文章：深入理解JVM虚拟机 - jvm的对象分配策略
阅读日志建议更多的是实操和练习，多尝试几遍之后更能加深记忆，由于个人机器本身不跑任何代码也会产生4M的对象，所以只能简单的介绍阅读日志的方法了…..
本文转自聊聊JVM的年轻代
我们先来屡屡，为什么需要把堆分代？不分代不能完成他所做的事情么？其实不分代完全可以，分代的唯一理由就是优化GC性能。你先想想，如果没有分代，那我们所有的对象都在一块，GC的时候我们要找到哪些对象没用，这样就会对堆的所有区域进行扫描。而我们的很多对象都是朝生夕死的，如果分代的话，我们把新创建的对象放到某一地方，当GC的时候先把这块存“朝生夕死”对象的区域进行回收，这样就会腾出很大的空间出来。
HotSpot JVM把年轻代分为了三部分：1个Eden区和2个Survivor区（分别叫from和to）。默认比例为8：1,为啥默认会是这个比例，接下来我们会聊到。一般情况下，新创建的对象都会被分配到Eden区(一些大对象特殊处理),这些对象经过第一次Minor GC后，如果仍然存活，将会被移到Survivor区。对象在Survivor区中每熬过一次Minor GC，年龄就会增加1岁，当它的年龄增加到一定程度时，就会被移动到年老代中。
因为年轻代中的对象基本都是朝生夕死的(80%以上)，所以在年轻代的垃圾回收算法使用的是复制算法，复制算法的基本思想就是将内存分为两块，每次只用其中一块，当这一块内存用完，就将还活着的对象复制到另外一块上面。复制算法不会产生内存碎片。
在GC开始的时候，对象只会存在于Eden区和名为“From”的Survivor区，Survivor区“To”是空的。紧接着进行GC，Eden区中所有存活的对象都会被复制到“To”，而在“From”区中，仍存活的对象会根据他们的年龄值来决定去向。年龄达到一定值(年龄阈值，可以通过-XX:MaxTenuringThreshold来设置)的对象会被移动到年老代中，没有达到阈值的对象会被复制到“To”区域。经过这次GC后，Eden区和From区已经被清空。这个时候，“From”和“To”会交换他们的角色，也就是新的“To”就是上次GC前的“From”，新的“From”就是上次GC前的“To”。不管怎样，都会保证名为To的Survivor区域是空的。Minor GC会一直重复这样的过程，直到“To”区被填满，“To”区被填满之后，会将所有对象移动到年老代中。
我是一个普通的java对象，我出生在Eden区，在Eden区我还看到和我长的很像的小兄弟，我们在Eden区中玩了挺长时间。有一天Eden区中的人实在是太多了，我就被迫去了Survivor区的“From”区，自从去了Survivor区，我就开始漂了，有时候在Survivor的“From”区，有时候在Survivor的“To”区，居无定所。直到我18岁的时候，爸爸说我成人了，该去社会上闯闯了。于是我就去了年老代那边，年老代里，人很多，并且年龄都挺大的，我在这里也认识了很多人。在年老代里，我生活了20年(每次GC加一岁)，然后被回收。
1)-XX:NewSize和-XX:MaxNewSize
用于设置年轻代的大小，建议设为整个堆大小的1/3或者1/4,两个值设为一样大。
2)-XX:SurvivorRatio
用于设置Eden和其中一个Survivor的比值，这个值也比较重要。
3)-XX:+PrintTenuringDistribution
这个参数用于显示每次Minor GC时Survivor区中各个年龄段的对象的大小。
4).-XX:InitialTenuringThreshol和-XX:MaxTenuringThreshold
用于设置晋升到老年代的对象年龄的最小值和最大值，每个对象在坚持过一次Minor GC之后，年龄就加1。
本文转自 Debugger 原理揭秘
代码写完会运行一下看下效果，开发的时候我们更多都是通过 dubugger 来单步或断点运行。我们整天在用 debugger，可是你有想过它的实现原理么。
本文会解答以下问题：
代码的运行方式可以分为直接执行和解释执行两类。
不知道平时你有没有注意，可执行文件直接 ./xxx 就可以执行，而执行 js 文件需要 node ./xxx，执行 python 文件需要 python ./xxx，这就是编译执行（直接执行）和解释执行的区别。
cpu 提供了一套指令集，基于这套指令集就可以控制整个计算机的运转，机器语言的代码就是由这些指令和对应的操作数构成的，这些机器码可以直接跑在计算机上，也就是可直接执行。由它们构成的文件叫做可执行文件。
不同操作系统可执行文件的格式不同，在 windows 上是 pe（Portable Executable） 格式，在 linux、unix 系统上是 elf（Executable Linkable Format） 格式，在 mac 上是 mash-o 格式。它们规定了不同的内容（.text 是代码、.data .bass 等是数据）放在文件中的什么位置。但其中真正可执行的部分还是由 cpu 提供的机器指令构成的。
编译型语言会经过编译、汇编、链接的阶段，编译是把源代码转成汇编语言构成的中间代码，汇编是把中间代码变成目标代码，链接会把目标代码组合成可执行文件。这个可执行文件是可以在操作系统上直接执行的。就因为它是由 cpu 的机器指令构成的，可以直接控制 cpu。所以可以直接 ./xxx 就可以执行。
编译型语言都是生成可执行文件直接在操作系统上来执行的，不需要安装解释器，而 js、python 等解释型语言的代码需要用解释器来跑。
为什么有了解释器就不需要生成机器码了，cpu 仍然不认识这些代码啊？
那是因为解释器是需要编译成机器码的，cpu 知道怎么执行解释器，而解释器知道怎么执行更上层的脚本代码，就这样，由机器码解释执行解释器，再由解释器解释执行上层代码，这就是脚本语言的原理。 包括 js、python 等都是这样。
但是解释器毕竟多了一层，所以有的时候会把它编译成机器码来直接执行，这就是 JIT 编译器。比如 js 引擎一般就是由 parser、解释器、JIT 编译器、GC 构成，大部分代码是由解释器解释执行的，而热点代码会经过 JIT 编译器编译成由机器码，直接在操作系统上执行以提高性能。
编译成机器码直接执行，或者是从源码解释执行，代码就这两种执行方式。两者各有各的好处，编译型速度快，解释型跨平台。这就是代码运行的原理。
王垠说过，计算机的本质就是解释器。就是说 cpu 用电路解释机器码，解释器用机器码解释更上层的脚本代码，所以计算机的本质是解释器。
我们知道，图灵完备的语言可以解释任何可计算问题，所以不管是编译型还是解释型都能够描述所有可计算的业务逻辑。
我们利用不同的语言描述业务逻辑，然后运行它看效果，当代码的逻辑比较复杂的时候，难免会出错，我们希望能够一步步运行或是运行到某个点停下来，然后看一下当时的环境中的变量，执行某个脚本。完成这个功能的就是 debugger。
也许还有很多初级程序员只会用 console.log 打日志，但是日志不能完全展现当时的环境，最好的方式还是 debugger。
狼叔说过，是否会用 debugger 是 nodejs 水平的一个明显的区分。
我们知道了 debugger 是调试程序必不可少的，那么它是怎么实现的呢？
其实 cpu、操作系统在设计的时候就支持了 debugger 的能力（可见 debugger 的重要性），cpu 里面有 4 个寄存器可以做硬中断，操作系统提供了系统调用来做软中断。这是编译型语言的 debugger 实现的基础。
cpu 只会不断的执行下一条指令，但程序运行过程中难免要处理一些外部的消息，比如 io、网络、异常等等，所以设计了中断的机制，cpu 每执行完一条指令，就会去看下中断标记，是否需要中断了。就像 event loop 每次 loop 完都要检查下是否需要渲染一样。
cpu 支持 INT 指令来触发中断，中断有编号，不同的编号有不同的处理程序，记录编号和中断处理程序的表叫做中断向量表。其中 INT 3 （3 号中断）可以触发 debugger，这是一种约定。
那么可执行文件是怎么利用这个 3 号中断来 debugger 的呢？其实就是运行时替换执行的内容，debugger 程序会在需要设置断点的位置把指令内容换成 INT 3，也就是 0xCC，这就断住了。就可以获取这时候的环境数据来做调试。
通过机器码替换成 0xcc （INT 3）是把程序断住了，可是怎么恢复执行呢？其实也比较简单，把当时替换的机器码记录下来，需要释放断点的时候再换回去就行了。
这就是可执行文件的 debugger 的原理了，最终还是靠 cpu 支持的中断机制来实现的。
上面说的 debugger 实现方式是修改内存中的机器码的方式，但有的时候修改不了代码，比如 ROM，这种情况就要通过 cpu 提供的 4 个中断寄存器（DR0 - DR3）来做了。这种叫做硬中断。
总之，INT 3 的软中断，还有中断寄存器的硬中断，是可执行文件实现 debugger 的两种方式。
编译型语言因为直接在操作系统之上执行，所以要利用 cpu 和操作系统的中断机制和系统调用来实现 debugger。但是解释型语言是自己实现代码的解释执行的，所以不需要那一套，但是实现思路还是一样的，就是插入一段代码来断住，支持环境数据的查看和代码的执行，当释放断点的时候就继续往下执行。
比如 javascript 中支持 debugger 语句，当解释器执行到这一条语句的时候就会断住。
解释型语言的 debugger 相对简单一些，不需要了解 cpu 的 INT 3 中断。
上面我们了解了直接执行和解释执行的代码的 debugger 分别是怎么实现的。我们知道了代码是怎么断住的，那么断住之后呢？怎么把环境数据暴露出去，怎么执行外部代码？
这就需要 debugger 客户端了。
比如 v8 引擎会把设置断点、获取环境信息、执行脚本的能力通过 socket 暴露出去，socket 传递的信息格式就是 v8 debug protocol 。
比如：
设置断点：
1 | { |
去掉断点：
1 | { |
继续：
1 | { |
执行代码：
1 | { |
感兴趣的同学可以去 v8 debug protocol 的文档中去查看全部的协议。
基于这些协议就可以控制 v8 的 debugger 了，所有的能够实现 debugger 的都是对接了这个协议，比如 chrome devtools、vscode debugger 还有其他各种 ide 的 debugger。
nodejs 可以通过添加 –inspect 的 option 来做调试（也可以是 –inspect-brk，这个会在首行就断住）。
它会起一个 debugger 的 websocket 服务端，我们可以用 vscode 来调试 nodejs 代码，也可以用 chrome devtools 来调试（见 nodejs debugger 文档）。
1 | ➜ node --inspect test.js |
原理就是实现了 v8 debug protocol。
我们如果自己做调试工具、做 ide，那就要对接这个协议。
上面介绍的 v8 debug protocol 可以实现 js 代码的调试，那么 python、c# 等肯定也有自己的调试协议，如果要实现 ide，都要对接一遍太过麻烦。所以后来出现了一个中间层协议，DAP（debugger adaptor protocol）。
debugger adaptor protocol， 顾名思义，就是适配的，一端适配各种 debugger 协议，一端提供给客户端统一的协议。这是适配器模式的一个很好的应用。
#总结
本文我们学习了 debugger 的实现原理和暴露出的调试协议。
首先我们了解了代码两种运行方式：直接执行和解释执行，然后分析了下为什么需要 debugger。
之后探索了直接执行的代码通过 INT 3 的中断的方式来实现 debugger 和解释型语言自己实现的 debugger。
然后 debugger 的能力会通过 socket 暴露给客户端，提供调试协议，比如 v8 debug protocol，各种客户端包括 chrome devtools、ide 等都实现了这个协议。
但是每种语言都要实现一次的话太过麻烦，所以后来出现了一个适配层协议，屏蔽了不同协议的区别，提供统一的协议接口给客户端用。
希望这篇文章能够让你理解 debugger 的原理，如果要实现调试工具也知道怎么该怎么去对接协议。能够知道 chrome devtools、vscode 为啥都可以调试 nodejs 代码。
问题答案在文中都有提到
当需要排查各种内存溢出问题、当垃圾收集成为系统达到更高并发的瓶颈时，我们就需要对这些“自动化”的技术实施必要的监控和调节。
Java 的自动内存管理主要是针对对象内存的回收和对象内存的分配。同时，Java 自动内存管理最核心的功能是 堆 内存中对象的分配与回收。
Java 堆是垃圾收集器管理的主要区域，因此也被称作GC 堆（Garbage Collected Heap）.从垃圾回收的角度，由于现在收集器基本都采用分代垃圾收集算法，所以 Java 堆还可以细分为：新生代和老年代：再细致一点有：Eden 空间、From Survivor、To Survivor 空间等。进一步划分的目的是更好地回收内存，或者更快地分配内存。
堆空间的基本结构：
上图所示的 Eden 区、From Survivor0(“From”) 区、To Survivor1(“To”) 区都属于新生代，Old Memory 区属于老年代。
大部分情况，对象都会首先在 Eden 区域分配，在一次新生代垃圾回收后，如果对象还存活，则会进入 s0 或者 s1，并且对象的年龄还会加 1(Eden 区->Survivor 区后对象的初始年龄变为 1)，当它的年龄增加到一定程度（默认为大于 15 岁），就会被晋升到老年代中。对象晋升到老年代的年龄阈值，可以通过参数 -XX:MaxTenuringThreshold 来设置默认值，这个值会在虚拟机运行过程中进行调整，可以通过-XX:+PrintTenuringDistribution来打印出当次 GC 后的 Threshold。
🐛 修正（参见：issue552）：“Hotspot 遍历所有对象时，按照年龄从小到大对其所占用的大小进行累积，当累积的某个年龄大小超过了 survivor 区的一半时，取这个年龄和 MaxTenuringThreshold 中更小的一个值，作为新的晋升年龄阈值”。
动态年龄计算的代码如下
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
//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) {
//sizes数组是每个年龄段对象大小
total += sizes[age];
if (total > desired_survivor_size) {
break;
}
age++;
}
uint result = age < MaxTenuringThreshold ? age : MaxTenuringThreshold;
...
}
经过这次 GC 后，Eden 区和”From”区已经被清空。这个时候，”From”和”To”会交换他们的角色，也就是新的”To”就是上次 GC 前的“From”，新的”From”就是上次 GC 前的”To”。不管怎样，都会保证名为 To 的 Survivor 区域是空的。Minor GC 会一直重复这样的过程，在这个过程中，有可能当次 Minor GC 后，Survivor 的”From”区域空间不够用，有一些还达不到进入老年代条件的实例放不下，则放不下的部分会提前进入老年代。
接下来我们提供一个调试脚本来测试这个过程。
调试代码参数如下
1 | -verbose:gc |
示例代码如下：
1 | /* |
注意:如下输出结果中老年代的信息为 concurrent mark-sweep generation 和以前版本略有不同。另外，还列出了某次 GC 后是否重新生成了 threshold，以及各个年龄占用空间的大小。
1 | 2021-07-01T10:41:32.257+0800: [GC (Allocation Failure) 2021-07-01T10:41:32.257+0800: [ParNew |
目前主流的垃圾收集器都会采用分代回收算法，因此需要将堆内存分为新生代和老年代，这样我们就可以根据各个年代的特点选择合适的垃圾收集算法。
大多数情况下，对象在新生代中 eden 区分配。当 eden 区没有足够空间进行分配时，虚拟机将发起一次 Minor GC.下面我们来进行实际测试以下。
测试：
1 | public class GCTest { |
通过以下方式运行：
添加的参数：-XX:+PrintGCDetails
运行结果 (红色字体描述有误，应该是对应于 JDK1.7 的永久代)：
从上图我们可以看出 eden 区内存几乎已经被分配完全（即使程序什么也不做，新生代也会使用 2000 多 k 内存）。假如我们再为 allocation2 分配内存会出现什么情况呢？
1 | allocation2 = new byte[900*1024]; |
简单解释一下为什么会出现这种情况： 因为给 allocation2 分配内存的时候 eden 区内存几乎已经被分配完了，我们刚刚讲了当 Eden 区没有足够空间进行分配时，虚拟机将发起一次 Minor GC.GC 期间虚拟机又发现 allocation1 无法存入 Survivor 空间，所以只好通过 分配担保机制 把新生代的对象提前转移到老年代中去，老年代上的空间足够存放 allocation1，所以不会出现 Full GC。执行 Minor GC 后，后面分配的对象如果能够存在 eden 区的话，还是会在 eden 区分配内存。可以执行如下代码验证：
1 | public class GCTest { |
大对象就是需要大量连续内存空间的对象（比如：字符串、数组）。
为什么要这样呢？
为了避免为大对象分配内存时由于分配担保机制带来的复制而降低效率。
既然虚拟机采用了分代收集的思想来管理内存，那么内存回收时就必须能识别哪些对象应放在新生代，哪些对象应放在老年代中。为了做到这一点，虚拟机给每个对象一个对象年龄（Age）计数器。
如果对象在 Eden 出生并经过第一次 Minor GC 后仍然能够存活，并且能被 Survivor 容纳的话，将被移动到 Survivor 空间中，并将对象年龄设为 1.对象在 Survivor 中每熬过一次 MinorGC,年龄就增加 1 岁，当它的年龄增加到一定程度（默认为 15 岁），就会被晋升到老年代中。对象晋升到老年代的年龄阈值，可以通过参数 -XX:MaxTenuringThreshold 来设置。
大部分情况，对象都会首先在 Eden 区域分配，在一次新生代垃圾回收后，如果对象还存活，则会进入 s0 或者 s1，并且对象的年龄还会加 1(Eden 区->Survivor 区后对象的初始年龄变为 1)，当它的年龄增加到一定程度（默认为 15 岁），就会被晋升到老年代中。对象晋升到老年代的年龄阈值，可以通过参数 -XX:MaxTenuringThreshold 来设置。
修正（issue552）：“Hotspot 遍历所有对象时，按照年龄从小到大对其所占用的大小进行累积，当累积的某个年龄大小超过了 survivor 区的 50% 时（默认值是 50%，可以通过
-XX:TargetSurvivorRatio=percent来设置，参见 issue1199 ），取这个年龄和 MaxTenuringThreshold 中更小的一个值，作为新的晋升年龄阈值”。jdk8 官方文档引用 ：https://docs.oracle.com/javase/8/docs/technotes/tools/unix/java.html 。
动态年龄计算的代码如下：
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
//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) {
//sizes数组是每个年龄段对象大小
total += sizes[age];
if (total > desired_survivor_size) {
break;
}
age++;
}
uint result = age < MaxTenuringThreshold ? age : MaxTenuringThreshold;
...
}额外补充说明(issue672)：关于默认的晋升年龄是 15，这个说法的来源大部分都是《深入理解 Java 虚拟机》这本书。
如果你去 Oracle 的官网阅读相关的虚拟机参数，你会发现-XX:MaxTenuringThreshold=threshold这里有个说明Sets the maximum tenuring threshold for use in adaptive GC sizing. The largest value is 15. The default value is 15 for the parallel (throughput) collector, and 6 for the CMS collector.默认晋升年龄并不都是 15，这个是要区分垃圾收集器的，CMS 就是 6.
周志明先生在《深入理解 Java 虚拟机》第二版中 P92 如是写道：
“老年代 GC（Major GC/Full GC），指发生在老年代的 GC……”
上面的说法已经在《深入理解 Java 虚拟机》第三版中被改正过来了。感谢 R 大的回答：
总结：
针对 HotSpot VM 的实现，它里面的 GC 其实准确分类只有两大种：
部分收集 (Partial GC)：
整堆收集 (Full GC)：收集整个 Java 堆和方法区。
空间分配担保是为了确保在 Minor GC 之前老年代本身还有容纳新生代所有对象的剩余空间。
《深入理解 Java 虚拟机》第三章对于空间分配担保的描述如下：
JDK 6 Update 24 之前，在发生 Minor GC 之前，虚拟机必须先检查老年代最大可用的连续空间是否大于新生代所有对象总空间，如果这个条件成立，那这一次 Minor GC 可以确保是安全的。如果不成立，则虚拟机会先查看
-XX:HandlePromotionFailure参数的设置值是否允许担保失败(Handle Promotion Failure);如果允许，那会继续检查老年代最大可用的连续空间是否大于历次晋升到老年代对象的平均大小，如果大于，将尝试进行一次 Minor GC，尽管这次 Minor GC 是有风险的;如果小于，或者-XX: HandlePromotionFailure设置不允许冒险，那这时就要改为进行一次 Full GC。JDK 6 Update 24 之后的规则变为只要老年代的连续空间大于新生代对象总大小或者历次晋升的平均大小，就会进行 Minor GC，否则将进行 Full GC。
堆中几乎放着所有的对象实例，对堆垃圾回收前的第一步就是要判断哪些对象已经死亡（即不能再被任何途径使用的对象）。
给对象中添加一个引用计数器，每当有一个地方引用它，计数器就加 1；当引用失效，计数器就减 1；任何时候计数器为 0 的对象就是不可能再被使用的。
这个方法实现简单，效率高，但是目前主流的虚拟机中并没有选择这个算法来管理内存，其最主要的原因是它很难解决对象之间相互循环引用的问题。 所谓对象之间的相互引用问题，如下面代码所示：除了对象 objA 和 objB 相互引用着对方之外，这两个对象之间再无任何引用。但是他们因为互相引用对方，导致它们的引用计数器都不为 0，于是引用计数算法无法通知 GC 回收器回收他们。
1 | public class ReferenceCountingGc { |
这个算法的基本思想就是通过一系列的称为 “GC Roots” 的对象作为起点，从这些节点开始向下搜索，节点所走过的路径称为引用链，当一个对象到 GC Roots 没有任何引用链相连的话，则证明此对象是不可用的，需要被回收。
下图中的 Object 6 ~ Object 10 之间虽有引用关系，但它们到 GC Roots 不可达，因此为需要被回收的对象。
哪些对象可以作为 GC Roots 呢？
对象可以被回收，就代表一定会被回收吗？
即使在可达性分析法中不可达的对象，也并非是“非死不可”的，这时候它们暂时处于“缓刑阶段”，要真正宣告一个对象死亡，至少要经历两次标记过程；可达性分析法中不可达的对象被第一次标记并且进行一次筛选，筛选的条件是此对象是否有必要执行 finalize 方法。当对象没有覆盖 finalize 方法，或 finalize 方法已经被虚拟机调用过时，虚拟机将这两种情况视为没有必要执行。
被判定为需要执行的对象将会被放在一个队列中进行第二次标记，除非这个对象与引用链上的任何一个对象建立关联，否则就会被真的回收。
Object类中的finalize方法一直被认为是一个糟糕的设计，成为了 Java 语言的负担，影响了 Java 语言的安全和 GC 的性能。JDK9 版本及后续版本中各个类中的finalize方法会被逐渐弃用移除。忘掉它的存在吧！参考：
无论是通过引用计数法判断对象引用数量，还是通过可达性分析法判断对象的引用链是否可达，判定对象的存活都与“引用”有关。
JDK1.2 之前，Java 中引用的定义很传统：如果 reference 类型的数据存储的数值代表的是另一块内存的起始地址，就称这块内存代表一个引用。
JDK1.2 以后，Java 对引用的概念进行了扩充，将引用分为强引用、软引用、弱引用、虚引用四种（引用强度逐渐减弱）
1．强引用（StrongReference）
以前我们使用的大部分引用实际上都是强引用，这是使用最普遍的引用。如果一个对象具有强引用，那就类似于必不可少的生活用品，垃圾回收器绝不会回收它。当内存空间不足，Java 虚拟机宁愿抛出 OutOfMemoryError 错误，使程序异常终止，也不会靠随意回收具有强引用的对象来解决内存不足问题。
2．软引用（SoftReference）
如果一个对象只具有软引用，那就类似于可有可无的生活用品。如果内存空间足够，垃圾回收器就不会回收它，如果内存空间不足了，就会回收这些对象的内存。只要垃圾回收器没有回收它，该对象就可以被程序使用。软引用可用来实现内存敏感的高速缓存。
软引用可以和一个引用队列（ReferenceQueue）联合使用，如果软引用所引用的对象被垃圾回收，JAVA 虚拟机就会把这个软引用加入到与之关联的引用队列中。
3．弱引用（WeakReference）
如果一个对象只具有弱引用，那就类似于可有可无的生活用品。弱引用与软引用的区别在于：只具有弱引用的对象拥有更短暂的生命周期。在垃圾回收器线程扫描它所管辖的内存区域的过程中，一旦发现了只具有弱引用的对象，不管当前内存空间足够与否，都会回收它的内存。不过，由于垃圾回收器是一个优先级很低的线程， 因此不一定会很快发现那些只具有弱引用的对象。
弱引用可以和一个引用队列（ReferenceQueue）联合使用，如果弱引用所引用的对象被垃圾回收，Java 虚拟机就会把这个弱引用加入到与之关联的引用队列中。
4．虚引用（PhantomReference）
“虚引用”顾名思义，就是形同虚设，与其他几种引用都不同，虚引用并不会决定对象的生命周期。如果一个对象仅持有虚引用，那么它就和没有任何引用一样，在任何时候都可能被垃圾回收。
虚引用主要用来跟踪对象被垃圾回收的活动。
虚引用与软引用和弱引用的一个区别在于： 虚引用必须和引用队列（ReferenceQueue）联合使用。当垃圾回收器准备回收一个对象时，如果发现它还有虚引用，就会在回收对象的内存之前，把这个虚引用加入到与之关联的引用队列中。程序可以通过判断引用队列中是否已经加入了虚引用，来了解被引用的对象是否将要被垃圾回收。程序如果发现某个虚引用已经被加入到引用队列，那么就可以在所引用的对象的内存被回收之前采取必要的行动。
特别注意，在程序设计中一般很少使用弱引用与虚引用，使用软引用的情况较多，这是因为软引用可以加速 JVM 对垃圾内存的回收速度，可以维护系统的运行安全，防止内存溢出（OutOfMemory）等问题的产生。
运行时常量池主要回收的是废弃的常量。那么，我们如何判断一个常量是废弃常量呢？
JDK1.7 及之后版本的 JVM 已经将运行时常量池从方法区中移了出来，在 Java 堆（Heap）中开辟了一块区域存放运行时常量池。
- JDK1.7 之前运行时常量池逻辑包含字符串常量池存放在方法区, 此时 hotspot 虚拟机对方法区的实现为永久代
- JDK1.7 字符串常量池被从方法区拿到了堆中, 这里没有提到运行时常量池,也就是说字符串常量池被单独拿到堆,运行时常量池剩下的东西还在方法区, 也就是 hotspot 中的永久代 。
- JDK1.8 hotspot 移除了永久代用元空间(Metaspace)取而代之, 这时候字符串常量池还在堆, 运行时常量池还在方法区, 只不过方法区的实现从永久代变成了元空间(Metaspace)
假如在字符串常量池中存在字符串 “abc”，如果当前没有任何 String 对象引用该字符串常量的话，就说明常量 “abc” 就是废弃常量，如果这时发生内存回收的话而且有必要的话，”abc” 就会被系统清理出常量池了。
方法区主要回收的是无用的类，那么如何判断一个类是无用的类的呢？
判定一个常量是否是“废弃常量”比较简单，而要判定一个类是否是“无用的类”的条件则相对苛刻许多。类需要同时满足下面 3 个条件才能算是 “无用的类” ：
ClassLoader 已经被回收。java.lang.Class 对象没有在任何地方被引用，无法在任何地方通过反射访问该类的方法。虚拟机可以对满足上述 3 个条件的无用类进行回收，这里说的仅仅是“可以”，而并不是和对象一样不使用了就会必然被回收。
该算法分为“标记”和“清除”阶段：首先标记出所有不需要回收的对象，在标记完成后统一回收掉所有没有被标记的对象。它是最基础的收集算法，后续的算法都是对其不足进行改进得到。这种垃圾收集算法会带来两个明显的问题：
为了解决效率问题，“标记-复制”收集算法出现了。它可以将内存分为大小相同的两块，每次使用其中的一块。当这一块的内存使用完后，就将还存活的对象复制到另一块去，然后再把使用的空间一次清理掉。这样就使每次的内存回收都是对内存区间的一半进行回收。
根据老年代的特点提出的一种标记算法，标记过程仍然与“标记-清除”算法一样，但后续步骤不是直接对可回收对象回收，而是让所有存活的对象向一端移动，然后直接清理掉端边界以外的内存。
当前虚拟机的垃圾收集都采用分代收集算法，这种算法没有什么新的思想，只是根据对象存活周期的不同将内存分为几块。一般将 java 堆分为新生代和老年代，这样我们就可以根据各个年代的特点选择合适的垃圾收集算法。
比如在新生代中，每次收集都会有大量对象死去，所以可以选择”标记-复制“算法，只需要付出少量对象的复制成本就可以完成每次垃圾收集。而老年代的对象存活几率是比较高的，而且没有额外的空间对它进行分配担保，所以我们必须选择“标记-清除”或“标记-整理”算法进行垃圾收集。
延伸面试问题： HotSpot 为什么要分为新生代和老年代？
根据上面的对分代收集算法的介绍回答。
如果说收集算法是内存回收的方法论，那么垃圾收集器就是内存回收的具体实现。
虽然我们对各个收集器进行比较，但并非要挑选出一个最好的收集器。因为直到现在为止还没有最好的垃圾收集器出现，更加没有万能的垃圾收集器，我们能做的就是根据具体应用场景选择适合自己的垃圾收集器。试想一下：如果有一种四海之内、任何场景下都适用的完美收集器存在，那么我们的 HotSpot 虚拟机就不会实现那么多不同的垃圾收集器了。
Serial（串行）收集器是最基本、历史最悠久的垃圾收集器了。大家看名字就知道这个收集器是一个单线程收集器了。它的 “单线程” 的意义不仅仅意味着它只会使用一条垃圾收集线程去完成垃圾收集工作，更重要的是它在进行垃圾收集工作的时候必须暂停其他所有的工作线程（ “Stop The World” ），直到它收集结束。
新生代采用标记-复制算法，老年代采用标记-整理算法。
虚拟机的设计者们当然知道 Stop The World 带来的不良用户体验，所以在后续的垃圾收集器设计中停顿时间在不断缩短（仍然还有停顿，寻找最优秀的垃圾收集器的过程仍然在继续）。
但是 Serial 收集器有没有优于其他垃圾收集器的地方呢？当然有，它简单而高效（与其他收集器的单线程相比）。Serial 收集器由于没有线程交互的开销，自然可以获得很高的单线程收集效率。Serial 收集器对于运行在 Client 模式下的虚拟机来说是个不错的选择。
ParNew 收集器其实就是 Serial 收集器的多线程版本，除了使用多线程进行垃圾收集外，其余行为（控制参数、收集算法、回收策略等等）和 Serial 收集器完全一样。
新生代采用标记-复制算法，老年代采用标记-整理算法。
它是许多运行在 Server 模式下的虚拟机的首要选择，除了 Serial 收集器外，只有它能与 CMS 收集器（真正意义上的并发收集器，后面会介绍到）配合工作。
并行和并发概念补充：
并行（Parallel） ：指多条垃圾收集线程并行工作，但此时用户线程仍然处于等待状态。
并发（Concurrent）：指用户线程与垃圾收集线程同时执行（但不一定是并行，可能会交替执行），用户程序在继续运行，而垃圾收集器运行在另一个 CPU 上。
Parallel Scavenge 收集器也是使用标记-复制算法的多线程收集器，它看上去几乎和 ParNew 都一样。 那么它有什么特别之处呢？
1 | -XX:+UseParallelGC |
Parallel Scavenge 收集器关注点是吞吐量（高效率的利用 CPU）。CMS 等垃圾收集器的关注点更多的是用户线程的停顿时间（提高用户体验）。所谓吞吐量就是 CPU 中用于运行用户代码的时间与 CPU 总消耗时间的比值。 Parallel Scavenge 收集器提供了很多参数供用户找到最合适的停顿时间或最大吞吐量，如果对于收集器运作不太了解，手工优化存在困难的时候，使用 Parallel Scavenge 收集器配合自适应调节策略，把内存管理优化交给虚拟机去完成也是一个不错的选择。
新生代采用标记-复制算法，老年代采用标记-整理算法。
这是 JDK1.8 默认收集器
使用 java -XX:+PrintCommandLineFlags -version 命令查看
1 | -XX:InitialHeapSize=262921408 -XX:MaxHeapSize=4206742528 -XX:+PrintCommandLineFlags -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:+UseParallelGC |
JDK1.8 默认使用的是 Parallel Scavenge + Parallel Old，如果指定了-XX:+UseParallelGC 参数，则默认指定了-XX:+UseParallelOldGC，可以使用-XX:-UseParallelOldGC 来禁用该功能
Serial 收集器的老年代版本，它同样是一个单线程收集器。它主要有两大用途：一种用途是在 JDK1.5 以及以前的版本中与 Parallel Scavenge 收集器搭配使用，另一种用途是作为 CMS 收集器的后备方案。
Parallel Scavenge 收集器的老年代版本。使用多线程和“标记-整理”算法。在注重吞吐量以及 CPU 资源的场合，都可以优先考虑 Parallel Scavenge 收集器和 Parallel Old 收集器。
CMS（Concurrent Mark Sweep）收集器是一种以获取最短回收停顿时间为目标的收集器。它非常符合在注重用户体验的应用上使用。
CMS（Concurrent Mark Sweep）收集器是 HotSpot 虚拟机第一款真正意义上的并发收集器，它第一次实现了让垃圾收集线程与用户线程（基本上）同时工作。
从名字中的Mark Sweep这两个词可以看出，CMS 收集器是一种 “标记-清除”算法实现的，它的运作过程相比于前面几种垃圾收集器来说更加复杂一些。整个过程分为四个步骤：
从它的名字就可以看出它是一款优秀的垃圾收集器，主要优点：并发收集、低停顿。但是它有下面三个明显的缺点：
G1 (Garbage-First) 是一款面向服务器的垃圾收集器,主要针对配备多颗处理器及大容量内存的机器. 以极高概率满足 GC 停顿时间要求的同时,还具备高吞吐量性能特征.
被视为 JDK1.7 中 HotSpot 虚拟机的一个重要进化特征。它具备以下特点：
G1 收集器的运作大致分为以下几个步骤：
G1 收集器在后台维护了一个优先列表，每次根据允许的收集时间，优先选择回收价值最大的 Region(这也就是它的名字 Garbage-First 的由来) 。这种使用 Region 划分内存空间以及有优先级的区域回收方式，保证了 G1 收集器在有限时间内可以尽可能高的收集效率（把内存化整为零）。
与 CMS 中的 ParNew 和 G1 类似，ZGC 也采用标记-复制算法，不过 ZGC 对该算法做了重大改进。
在 ZGC 中出现 Stop The World 的情况会更少！
详情可以看 ： 《新一代垃圾回收器 ZGC 的探索与实践》