用户标签画像分为哪几类

用户画像建模其实就是对用户“打标签”, 从打标签的方式来看，一般分为三种类型：统计类、规则类、挖掘类

统计类

统计类标签又被习惯性叫作定量标签，通过客观数据计算得来。例如，性别、年龄、注册日期、近七天登录频率、近30天充值金额。这些字段都可以从用户的注册数据、登录数据、充值数据中统计得出。

统计类标签在实时性上还可以细分成离线标签和流式标签。这就要根据业务需求来定，如果实时性要求比较高那就必须把流式标签考虑进去。

此类标签构成了用户画像的基础。

规则类

规则类标签基于用户行为及确定的规则产生，也被叫作定性标签。在实际开发过程中，一般由业务人员及开发人员共同协商确定。

例如，对平台上”大R”用户的定义口径为“月登陆次数>10 && 月充值次数>20 && 月充值额度>1000元”。

挖掘类

该类标签通过机器学习挖掘产生，对用户的某些行为进行预测。机器学习开发周期长，成本高。

例如，针对用户最近的登陆频率以及相关行为预测用户流失预警。

一、星型模型

星型模型：当所有的维度表都是和事实表直接相连的时候，整个图形看上去就像是一个星星，我们称之为星型模型。星型模型是一种非正规化的架构，因为多维数据集的每一个维度都和事实表直接相连，不存在渐变维度，所以有一定的数据冗余，因为有数据的冗余，很多的统计情况下，不需要和外表关联进行查询和数据分析，因此效率相对较高。

二、雪花模型

雪花模型：当有多个维度表没有直接和事实表相连，而是通过其它的维度表，间接的连接在事实表上，其图形就像是一个雪花，因此我们称之为雪花模型，雪花模型的优点是减少了数据冗余，在进行数据统计或分析的时候，需要和其他的表进行关联。

三、区别

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程序效率

参考

1、一分钟搞明白hive分区表和分桶表的区别

转载

本文转自IO 流简介

IO 流简介

IO 即 Input/Output，输入和输出。数据输入到计算机内存的过程即输入，反之输出到外部存储（比如数据库，文件，远程主机）的过程即输出。数据传输过程类似于水流，因此称为 IO 流。IO 流在 Java 中分为输入流和输出流，而根据数据的处理方式又分为字节流和字符流。

Java IO 流的 40 多个类都是从如下 4 个抽象类基类中派生出来的。

• InputStream/Reader: 所有的输入流的基类，前者是字节输入流，后者是字符输入流。
• OutputStream/Writer: 所有输出流的基类，前者是字节输出流，后者是字符输出流。

字节流

InputStream（字节输入流）

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
2
3
4
5
6
7
8
9
10
11
12
13

try (InputStream fis = new FileInputStream("input.txt)) {
    System.out.println("Number of remaining bytes:"
            + fis.available());
    int content;
    long skip = fis.skip(2);
    System.out.println("The actual number of bytes skipped:" + skip);
    System.out.print("The content read from file:");
    while ((content = fis.read()) != -1) {
        System.out.print((char) content);
    }
} catch (IOException e) {
    e.printStackTrace();
}

input.txt 文件内容：

输出：

1
2
3

Number of remaining bytes:11
The actual number of bytes skipped:2
The content read from file:JavaGuide

不过，一般我们是不会直接单独使用 FileInputStream ，通常会配合 BufferedInputStream（字节缓冲输入流，后文会讲到）来使用。

像下面这段代码在我们的项目中就比较常见，我们通过 readAllBytes() 读取输入流所有字节并将其直接赋值给一个 String 对象。

1
2
3
4
5

// 新建一个 BufferedInputStream 对象
BufferedInputStream bufferedInputStream = new BufferedInputStream(new FileInputStream("input.txt"));
// 读取文件的内容并复制到 String 对象中
String result = new String(bufferedInputStream.readAllBytes());
System.out.println(result);

DataInputStream 用于读取指定类型数据，不能单独使用，必须结合 FileInputStream 。

1
2
3
4
5
6
7

FileInputStream fileInputStream = new FileInputStream("input.txt");
//必须将fileInputStream作为构造参数才能使用
DataInputStream dataInputStream = new DataInputStream(fileInputStream);
//可以读取任意具体的类型数据
dataInputStream.readBoolean();
dataInputStream.readInt();
dataInputStream.readUTF();

ObjectInputStream 用于从输入流中读取 Java 对象（反序列化），ObjectOutputStream 用于将对象写入到输出流(序列化)。

1
2
3

ObjectInputStream input = new ObjectInputStream(new FileInputStream("object.data"));
MyClass object = (MyClass) input.readObject();
input.close();

另外，用于序列化和反序列化的类必须实现 Serializable 接口，对象中如果有属性不想被序列化，使用 transient 修饰。

OutputStream（字节输出流）

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
2
3
4
5
6

try (FileOutputStream output = new FileOutputStream("output.txt")) {
    byte[] array = "JavaGuide".getBytes();
    output.write(array);
} catch (IOException e) {
    e.printStackTrace();
}

运行结果：

类似于 FileInputStream，FileOutputStream 通常也会配合 BufferedOutputStream（字节缓冲输出流，后文会讲到）来使用。

1
2

FileOutputStream fileOutputStream = new FileOutputStream("output.txt");
BufferedOutputStream bos = new BufferedOutputStream(fileOutputStream)

DataOutputStream 用于写入指定类型数据，不能单独使用，必须结合 FileOutputStream

1
2
3
4
5
6

// 输出流
FileOutputStream fileOutputStream = new FileOutputStream("out.txt");
DataOutputStream dataOutputStream = new DataOutputStream(fileOutputStream);
// 输出任意数据类型
dataOutputStream.writeBoolean(true);
dataOutputStream.writeByte(1);

ObjectOutputStream 用于从输入流中读取 Java 对象（ObjectInputStream,反序列化）或者将对象写入到输出流(ObjectOutputStream，序列化)。

1
2
3

ObjectOutputStream output = new ObjectOutputStream(new FileOutputStream("file.txt")
Person person = new Person("Guide哥", "JavaGuide作者");
output.writeObject(person);

字符流

不管是文件读写还是网络发送接收，信息的最小存储单元都是字节。 那为什么 I/O 流操作要分为字节流操作和字符流操作呢？

个人认为主要有两点原因：

• 字符流是由 Java 虚拟机将字节转换得到的，这个过程还算是比较耗时。
• 如果我们不知道编码类型就很容易出现乱码问题。

乱码问题这个很容易就可以复现，我们只需要将上面提到的 FileInputStream 代码示例中的 input.txt 文件内容改为中文即可，原代码不需要改动。

输出：

1
2
3

Number of remaining bytes:9
The actual number of bytes skipped:2
The content read from file:§å®¶å¥½

可以很明显地看到读取出来的内容已经变成了乱码。

因此，I/O 流就干脆提供了一个直接操作字符的接口，方便我们平时对字符进行流操作。如果音频文件、图片等媒体文件用字节流比较好，如果涉及到字符的话使用字符流比较好。

字符流默认采用的是 Unicode 编码，我们可以通过构造方法自定义编码。顺便分享一下之前遇到的笔试题：常用字符编码所占字节数？utf8 :英文占 1 字节，中文占 3 字节，unicode：任何字符都占 2 个字节，gbk：英文占 1 字节，中文占 2 字节。

Reader（字符输入流）

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
2
3
4
5
6

// 字节流转换为字符流的桥梁
public class InputStreamReader extends Reader {
}
// 用于读取字符文件
public class FileReader extends InputStreamReader {
}

FileReader 代码示例：

1
2
3
4
5
6
7
8
9
10
11

try (FileReader fileReader = new FileReader("input.txt");) {
    int content;
    long skip = fileReader.skip(3);
    System.out.println("The actual number of bytes skipped:" + skip);
    System.out.print("The content read from file:");
    while ((content = fileReader.read()) != -1) {
        System.out.print((char) content);
    }
} catch (IOException e) {
    e.printStackTrace();
}

input.txt 文件内容：

输出：

1
2

The actual number of bytes skipped:3
The content read from file:我是Guide。

Writer（字符输出流）

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
2
3
4
5
6

// 字符流转换为字节流的桥梁
public class InputStreamReader extends Reader {
}
// 用于写入字符到文件
public class FileWriter extends OutputStreamWriter {
}

FileWriter 代码示例：

1
2
3
4
5

try (Writer output = new FileWriter("output.txt")) {
    output.write("你好，我是Guide。");
} catch (IOException e) {
    e.printStackTrace();
}

输出结果：

字节缓冲流

IO 操作是很消耗性能的，缓冲流将数据加载至缓冲区，一次性读取/写入多个字节，从而避免频繁的 IO 操作，提高流的传输效率。

字节缓冲流这里采用了装饰器模式来增强 InputStream 和OutputStream子类对象的功能。

举个例子，我们可以通过 BufferedInputStream（字节缓冲输入流）来增强 FileInputStream 的功能。

1
2

// 新建一个 BufferedInputStream 对象
BufferedInputStream bufferedInputStream = new BufferedInputStream(new FileInputStream("input.txt"));

字节流和字节缓冲流的性能差别主要体现在我们使用两者的时候都是调用 write(int b) 和 read() 这两个一次只读取一个字节的方法的时候。由于字节缓冲流内部有缓冲区（字节数组），因此，字节缓冲流会先将读取到的字节存放在缓存区，大幅减少 IO 次数，提高读取效率。

我使用 write(int b) 和 read() 方法，分别通过字节流和字节缓冲流复制一个 524.9 mb 的 PDF 文件耗时对比如下：

1
2

使用缓冲流复制PDF文件总耗时:15428 毫秒
使用普通字节流复制PDF文件总耗时:2555062 毫秒

两者耗时差别非常大，缓冲流耗费的时间是字节流的 1/165。

测试代码如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

@Test
void copy_pdf_to_another_pdf_buffer_stream() {
    // 记录开始时间
    long start = System.currentTimeMillis();
    try (BufferedInputStream bis = new BufferedInputStream(new FileInputStream("深入理解计算机操作系统.pdf"));
         BufferedOutputStream bos = new BufferedOutputStream(new FileOutputStream("深入理解计算机操作系统-副本.pdf"))) {
        int content;
        while ((content = bis.read()) != -1) {
            bos.write(content);
        }
    } catch (IOException e) {
        e.printStackTrace();
    }
    // 记录结束时间
    long end = System.currentTimeMillis();
    System.out.println("使用缓冲流复制PDF文件总耗时:" + (end - start) + " 毫秒");
}

@Test
void copy_pdf_to_another_pdf_stream() {
    // 记录开始时间
    long start = System.currentTimeMillis();
    try (FileInputStream fis = new FileInputStream("深入理解计算机操作系统.pdf");
         FileOutputStream fos = new FileOutputStream("深入理解计算机操作系统-副本.pdf")) {
        int content;
        while ((content = fis.read()) != -1) {
            fos.write(content);
        }
    } catch (IOException e) {
        e.printStackTrace();
    }
    // 记录结束时间
    long end = System.currentTimeMillis();
    System.out.println("使用普通流复制PDF文件总耗时:" + (end - start) + " 毫秒");
}

如果是调用 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
2

使用缓冲流复制PDF文件总耗时:695 毫秒
使用普通字节流复制PDF文件总耗时:989 毫秒

两者耗时差别不是很大，缓冲流的性能要略微好一点点。

测试代码如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37

@Test
void copy_pdf_to_another_pdf_with_byte_array_buffer_stream() {
    // 记录开始时间
    long start = System.currentTimeMillis();
    try (BufferedInputStream bis = new BufferedInputStream(new FileInputStream("深入理解计算机操作系统.pdf"));
         BufferedOutputStream bos = new BufferedOutputStream(new FileOutputStream("深入理解计算机操作系统-副本.pdf"))) {
        int len;
        byte[] bytes = new byte[4 * 1024];
        while ((len = bis.read(bytes)) != -1) {
            bos.write(bytes, 0, len);
        }
    } catch (IOException e) {
        e.printStackTrace();
    }
    // 记录结束时间
    long end = System.currentTimeMillis();
    System.out.println("使用缓冲流复制PDF文件总耗时:" + (end - start) + " 毫秒");
}

@Test
void copy_pdf_to_another_pdf_with_byte_array_stream() {
    // 记录开始时间
    long start = System.currentTimeMillis();
    try (FileInputStream fis = new FileInputStream("深入理解计算机操作系统.pdf");
         FileOutputStream fos = new FileOutputStream("深入理解计算机操作系统-副本.pdf")) {
        int len;
        byte[] bytes = new byte[4 * 1024];
        while ((len = fis.read(bytes)) != -1) {
            fos.write(bytes, 0, len);
        }
    } catch (IOException e) {
        e.printStackTrace();
    }
    // 记录结束时间
    long end = System.currentTimeMillis();
    System.out.println("使用普通流复制PDF文件总耗时:" + (end - start) + " 毫秒");
}

BufferedInputStream（字节缓冲输入流）

BufferedInputStream 从源头（通常是文件）读取数据（字节信息）到内存的过程中不会一个字节一个字节的读取，而是会先将读取到的字节存放在缓存区，并从内部缓冲区中单独读取字节。这样大幅减少了 IO 次数，提高了读取效率。

BufferedInputStream 内部维护了一个缓冲区，这个缓冲区实际就是一个字节数组，通过阅读 BufferedInputStream 源码即可得到这个结论。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

public
class BufferedInputStream extends FilterInputStream {
    // 内部缓冲区数组
    protected volatile byte buf[];
    // 缓冲区的默认大小
    private static int DEFAULT_BUFFER_SIZE = 8192;
    // 使用默认的缓冲区大小
    public BufferedInputStream(InputStream in) {
        this(in, DEFAULT_BUFFER_SIZE);
    }
    // 自定义缓冲区大小
    public BufferedInputStream(InputStream in, int size) {
        super(in);
        if (size <= 0) {
            throw new IllegalArgumentException("Buffer size <= 0");
        }
        buf = new byte[size];
    }
}

缓冲区的大小默认为 8192 字节，当然了，你也可以通过 BufferedInputStream(InputStream in, int size) 这个构造方法来指定缓冲区的大小。

BufferedOutputStream（字节缓冲输出流）

BufferedOutputStream 将数据（字节信息）写入到目的地（通常是文件）的过程中不会一个字节一个字节的写入，而是会先将要写入的字节存放在缓存区，并从内部缓冲区中单独写入字节。这样大幅减少了 IO 次数，提高了读取效率

1
2
3
4
5
6

try (BufferedOutputStream bos = new BufferedOutputStream(new FileOutputStream("output.txt"))) {
    byte[] array = "JavaGuide".getBytes();
    bos.write(array);
} catch (IOException e) {
    e.printStackTrace();
}

类似于 BufferedInputStream ，BufferedOutputStream 内部也维护了一个缓冲区，并且，这个缓存区的大小也是 8192 字节。

字符缓冲流

BufferedReader （字符缓冲输入流）和 BufferedWriter（字符缓冲输出流）类似于 BufferedInputStream（字节缓冲输入流）和BufferedOutputStream（字节缓冲输入流），内部都维护了一个字节数组作为缓冲区。不过，前者主要是用来操作字符信息。

打印流

下面这段代码大家经常使用吧？

1
2

System.out.print("Hello！");
System.out.println("Hello！");

System.out 实际是用于获取一个 PrintStream 对象，print方法实际调用的是 PrintStream 对象的 write 方法。

PrintStream 属于字节打印流，与之对应的是 PrintWriter （字符打印流）。PrintStream 是 OutputStream 的子类，PrintWriter 是 Writer 的子类。

1
2
3
4
5

public class PrintStream extends FilterOutputStream
    implements Appendable, Closeable {
}
public class PrintWriter extends Writer {
}

随机访问流

这里要介绍的随机访问流指的是支持随意跳转到文件的任意位置进行读写的 RandomAccessFile 。

RandomAccessFile 的构造方法如下，我们可以指定 mode（读写模式）。

1
2
3
4
5
6
7
8
9

// openAndDelete 参数默认为 false 表示打开文件并且这个文件不会被删除
public RandomAccessFile(File file, String mode)
    throws FileNotFoundException {
    this(file, mode, false);
}
// 私有方法
private RandomAccessFile(File file, String mode, boolean openAndDelete)  throws FileNotFoundException{
  // 省略大部分代码
}

读写模式主要有下面四种：

• r : 只读模式。
• rw: 读写模式
• rws: 相对于 rw，rws 同步更新对“文件的内容”或“元数据”的修改到外部存储设备。
• rwd : 相对于 rw，rwd 同步更新对“文件的内容”的修改到外部存储设备。

文件内容指的是文件中实际保存的数据，元数据则是用来描述文件属性比如文件的大小信息、创建和修改时间。

RandomAccessFile 中有一个文件指针用来表示下一个将要被写入或者读取的字节所处的位置。我们可以通过 RandomAccessFile 的 seek(long pos) 方法来设置文件指针的偏移量（距文件开头 pos 个字节处）。如果想要获取文件指针当前的位置的话，可以使用 getFilePointer() 方法。

RandomAccessFile 代码示例：

1
2
3
4
5
6
7
8
9
10

RandomAccessFile randomAccessFile = new RandomAccessFile(new File("input.txt"), "rw");
System.out.println("读取之前的偏移量：" + randomAccessFile.getFilePointer() + ",当前读取到的字符" + (char) randomAccessFile.read() + "，读取之后的偏移量：" + randomAccessFile.getFilePointer());
// 指针当前偏移量为 6
randomAccessFile.seek(6);
System.out.println("读取之前的偏移量：" + randomAccessFile.getFilePointer() + ",当前读取到的字符" + (char) randomAccessFile.read() + "，读取之后的偏移量：" + randomAccessFile.getFilePointer());
// 从偏移量 7 的位置开始往后写入字节数据
randomAccessFile.write(new byte[]{'H', 'I', 'J', 'K'});
// 指针当前偏移量为 0，回到起始位置
randomAccessFile.seek(0);
System.out.println("读取之前的偏移量：" + randomAccessFile.getFilePointer() + ",当前读取到的字符" + (char) randomAccessFile.read() + "，读取之后的偏移量：" + randomAccessFile.getFilePointer());

input.txt 文件内容：

输出：

1
2
3

读取之前的偏移量：0,当前读取到的字符A，读取之后的偏移量：1
读取之前的偏移量：6,当前读取到的字符G，读取之后的偏移量：7
读取之前的偏移量：0,当前读取到的字符A，读取之后的偏移量：1

input.txt 文件内容变为 ABCDEFGHIJK 。

RandomAccessFile 的 write 方法在写入对象的时候如果对应的位置已经有数据的话，会将其覆盖掉。

1
2

RandomAccessFile randomAccessFile = new RandomAccessFile(new File("input.txt"), "rw");
randomAccessFile.write(new byte[]{'H', 'I', 'J', 'K'});

假设运行上面这段程序之前 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
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54

package sortdemo;

import java.util.Arrays;

/**
* Created by chengxiao on 2016/12/8.
*/
public class MergeSort {
  public static void main(String []args){
      int []arr = {9,8,7,6,5,4,3,2,1};
      sort(arr);
      System.out.println(Arrays.toString(arr));
  }
  public static void sort(int []arr){
      int []temp = new int[arr.length];
      //在排序前，先建好一个长度等于原数组长度的临时数组，
      //避免递归中频繁开辟空间
      sort(arr,0,arr.length-1,temp);
  }
  private static void sort(int[] arr,int left,int right,int []temp){
      if(left<right){
          int mid = (left+right)/2;
          sort(arr,left,mid,temp);
          //左边归并排序，使得左子序列有序
          sort(arr,mid+1,right,temp);
          //右边归并排序，使得右子序列有序
          merge(arr,left,mid,right,temp);
          //将两个有序子数组合并操作
      }
  }
  private static void merge(int[] arr,int left,int mid,int right,int[] temp){
      int i = left;//左序列指针
      int j = mid+1;//右序列指针
      int t = 0;//临时数组指针
      while (i<=mid && j<=right){
          if(arr[i]<=arr[j]){
              temp[t++] = arr[i++];
          }else {
              temp[t++] = arr[j++];
          }
      }
      while(i<=mid){//将左边剩余元素填充进temp中
          temp[t++] = arr[i++];
      }
      while(j<=right){//将右序列剩余元素填充进temp中
          temp[t++] = arr[j++];
      }
      t = 0;
      //将temp中的元素全部拷贝到原数组中
      while(left <= right){
          arr[left++] = temp[t++];
      }
  }
}

执行结果

1

[1, 2, 3, 4, 5, 6, 7, 8, 9]

转载

本文转载自 Java IO模型详解

前言

I/O 一直是很多小伙伴难以理解的一个知识点，这篇文章我会将我所理解的 I/O 讲给你听，希望可以对你有所帮助。

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 调用后，会经历两个步骤：

1. 内核等待 I/O 设备准备好数据
2. 内核将数据从内核空间拷贝到用户空间。

有哪些常见的 IO 模型?

UNIX 系统下， IO 模型一共有 5 种： 同步阻塞 I/O、同步非阻塞 I/O、I/O 多路复用、信号驱动 I/O 和异步 I/O。

这也是我们经常提到的 5 种 IO 模型。

Java 中 3 种常见 IO 模型

BIO (Blocking I/O)

BIO 属于同步阻塞 IO 模型 。

同步阻塞 IO 模型中，应用程序发起 read 调用后，会一直阻塞，直到内核把数据拷贝到用户空间。

在客户端连接数量不高的情况下，是没问题的。但是，当面对十万甚至百万级连接的时候，传统的 BIO 模型是无能为力的。因此，我们需要一种更高效的 I/O 处理模型来应对更高的并发量。

NIO (Non-blocking/New 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 (Asynchronous I/O)

AIO 也就是 NIO 2。Java 7 中引入了 NIO 的改进版 NIO 2,它是异步 IO 模型。

异步 IO 是基于事件和回调机制实现的，也就是应用操作之后会直接返回，不会堵塞在那里，当后台处理完成，操作系统会通知相应的线程进行后续的操作。

目前来说 AIO 的应用还不是很广泛。Netty 之前也尝试使用过 AIO，不过又放弃了。这是因为，Netty 使用了 AIO 之后，在 Linux 系统上的性能并没有多少提升。

最后，来一张图，简单总结一下 Java 中的 BIO、NIO、AIO。

参考

• 《深入拆解 Tomcat & Jetty》
• 如何完成一次 IO：https://llc687.top/126.html
• 程序员应该这样理解 IO：https://www.jianshu.com/p/fa7bdc4f3de7
• 10 分钟看懂， Java NIO 底层原理：https://www.cnblogs.com/crazymakercircle/p/10225159.html
• IO 模型知多少 | 理论篇：https://www.cnblogs.com/sheng-jie/p/how-much-you-know-about-io-models.html
• 《UNIX 网络编程 卷 1；套接字联网 API 》6.2 节 IO 模型

转载

本文转自 深入理解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

参数的含义：

• -Xms20M -Xmx20M 给堆分配了20M的内存空间
• -Xmn10M 新生代分配10M
• -XX:+PrintGCDetails 同时打印GC信息
• -XX:SurvivorRatio=8 新生代的分配比例为8:1:1
• -XX:+UseSerialGC 使用serrial收集器。注意是serrial收集器。

代码配置

​ 先从最简单的方法开始，我们运行一个没有任何代码的Main方法

1
2
3
4
5
6
7

public class MinorGcTest {

    public static void main(String[] args) {
        
    }

}

注意下面的内容是运行一个空Main方法的日志内容。

1
2
3
4
5
6
7
8
9

Heap
 def new generation   total 9216K, used 3977K [0x00000000fec00000, 0x00000000ff600000, 0x00000000ff600000)
  eden space 8192K,  48% used [0x00000000fec00000, 0x00000000fefe27f0, 0x00000000ff400000)
  from space 1024K,   0% used [0x00000000ff400000, 0x00000000ff400000, 0x00000000ff500000)
  to   space 1024K,   0% used [0x00000000ff500000, 0x00000000ff500000, 0x00000000ff600000)
 tenured generation   total 10240K, used 0K [0x00000000ff600000, 0x0000000100000000, 0x0000000100000000)
   the space 10240K,   0% used [0x00000000ff600000, 0x00000000ff600000, 0x00000000ff600200, 0x0000000100000000)
 Metaspace       used 3241K, capacity 4496K, committed 4864K, reserved 1056768K
  class space    used 349K, capacity 388K, committed 512K, reserved 1048576K

解释：
​ 首先看下第二行：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
2
3
4
5

byte[] allocation1, allocation2, allocation3, allocation4, allocation5;
allocation1 = new byte[_1MB * 2];
allocation1 = new byte[_1MB * 2];
allocation1 = new byte[_1MB * 1];
allocation3 = new byte[20*_1MB * 2];

下面是日志的结果：

1
2
3
4
5
6
7
8
9
10
11
12

[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] 
[GC (Allocation Failure) [DefNew: 2131K->0K(9216K), 0.0015020 secs][Tenured: 4266K->2217K(10240K), 0.0030024 secs] 4350K->2217K(19456K), [Metaspace: 3254K->3254K(1056768K)], 0.0045414 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
[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] 
Heap
 def new generation   total 9216K, used 404K [0x00000000fec00000, 0x00000000ff600000, 0x00000000ff600000)
  eden space 8192K,   4% used [0x00000000fec00000, 0x00000000fec65330, 0x00000000ff400000)
  from space 1024K,   0% used [0x00000000ff400000, 0x00000000ff400000, 0x00000000ff500000)
  to   space 1024K,   0% used [0x00000000ff500000, 0x00000000ff500000, 0x00000000ff600000)
 tenured generation   total 10240K, used 2198K [0x00000000ff600000, 0x0000000100000000, 0x0000000100000000)
   the space 10240K,  21% used [0x00000000ff600000, 0x00000000ff8259d8, 0x00000000ff825a00, 0x0000000100000000)
 Metaspace       used 3360K, capacity 4496K, committed 4864K, reserved 1056768K
  class space    used 362K, capacity 388K, committed 512K, reserved 1048576K

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
2

[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] 
Heap

parNew+cms测试：

不执行任何测试

参数配置：

​ 注意最后使用了parnew+cms的组合

1
2
3
4
5
6
7
8

-verbose:gc
-Xms20M
-Xmx20M
-Xmn10M
-XX:+PrintGCDetails
-XX:SurvivorRatio=8
-XX:+UseParNewGC
-XX:+UseConcMarkSweepGC

代码配置：

​ 同样是不执行任何的代码，结果和其他的收集器类似

1
2
3
4
5
6
7
8

Heap
 par new generation   total 9216K, used 3977K [0x00000000fec00000, 0x00000000ff600000, 0x00000000ff600000)
  eden space 8192K,  48% used [0x00000000fec00000, 0x00000000fefe27f0, 0x00000000ff400000)
  from space 1024K,   0% used [0x00000000ff400000, 0x00000000ff400000, 0x00000000ff500000)
  to   space 1024K,   0% used [0x00000000ff500000, 0x00000000ff500000, 0x00000000ff600000)
 concurrent mark-sweep generation total 10240K, used 0K [0x00000000ff600000, 0x0000000100000000, 0x0000000100000000)
 Metaspace       used 3255K, capacity 4496K, committed 4864K, reserved 1056768K
  class space    used 353K, capacity 388K, committed 512K, reserved 1048576K

如果去掉cms？

​ 如果我们把上面的参数去掉-XX:+UseConcMarkSweepGC，会出现下面的内容：

1
2
3
4
5
6
7
8
9
10

Heap
 par new generation   total 9216K, used 3977K [0x00000000fec00000, 0x00000000ff600000, 0x00000000ff600000)
  eden space 8192K,  48% used [0x00000000fec00000, 0x00000000fefe27f0, 0x00000000ff400000)
  from space 1024K,   0% used [0x00000000ff400000, 0x00000000ff400000, 0x00000000ff500000)
  to   space 1024K,   0% used [0x00000000ff500000, 0x00000000ff500000, 0x00000000ff600000)
 tenured generation   total 10240K, used 0K [0x00000000ff600000, 0x0000000100000000, 0x0000000100000000)
   the space 10240K,   0% used [0x00000000ff600000, 0x00000000ff600000, 0x00000000ff600200, 0x0000000100000000)
 Metaspace       used 3238K, capacity 4496K, committed 4864K, reserved 1056768K
  class space    used 349K, capacity 388K, committed 512K, reserved 1048576K
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

这里注意一下最后一句：
​ 这里说明的是不推荐使用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的年轻代

1.为什么会有年轻代

我们先来屡屡，为什么需要把堆分代？不分代不能完成他所做的事情么？其实不分代完全可以，分代的唯一理由就是优化GC性能。你先想想，如果没有分代，那我们所有的对象都在一块，GC的时候我们要找到哪些对象没用，这样就会对堆的所有区域进行扫描。而我们的很多对象都是朝生夕死的，如果分代的话，我们把新创建的对象放到某一地方，当GC的时候先把这块存“朝生夕死”对象的区域进行回收，这样就会腾出很大的空间出来。

2.年轻代中的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”区被填满之后，会将所有对象移动到年老代中。

3.一个对象的这一辈子

我是一个普通的java对象，我出生在Eden区，在Eden区我还看到和我长的很像的小兄弟，我们在Eden区中玩了挺长时间。有一天Eden区中的人实在是太多了，我就被迫去了Survivor区的“From”区，自从去了Survivor区，我就开始漂了，有时候在Survivor的“From”区，有时候在Survivor的“To”区，居无定所。直到我18岁的时候，爸爸说我成人了，该去社会上闯闯了。于是我就去了年老代那边，年老代里，人很多，并且年龄都挺大的，我在这里也认识了很多人。在年老代里，我生活了20年(每次GC加一岁)，然后被回收。

4.有关年轻代的JVM参数

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。

前言

彪好专业名词，吹牛走遍天下

debug

DAP

debugger adaptor protocol， 顾名思义，就是适配的，一端适配各种 debugger 协议，一端提供给客户端统一的协议。这是适配器模式的一个很好的应用。

声明

本文转自 Debugger 原理揭秘

前言

代码写完会运行一下看下效果，开发的时候我们更多都是通过 dubugger 来单步或断点运行。我们整天在用 debugger，可是你有想过它的实现原理么。

本文会解答以下问题：

• 代码运行的底层原理是什么
• 为什么需要 debugger
• debugger 实现原理是什么
• 如何实现 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

我们知道，图灵完备的语言可以解释任何可计算问题，所以不管是编译型还是解释型都能够描述所有可计算的业务逻辑。

我们利用不同的语言描述业务逻辑，然后运行它看效果，当代码的逻辑比较复杂的时候，难免会出错，我们希望能够一步步运行或是运行到某个点停下来，然后看一下当时的环境中的变量，执行某个脚本。完成这个功能的就是 debugger。

也许还有很多初级程序员只会用 console.log 打日志，但是日志不能完全展现当时的环境，最好的方式还是 debugger。

狼叔说过，是否会用 debugger 是 nodejs 水平的一个明显的区分。

debugger 的原理

我们知道了 debugger 是调试程序必不可少的，那么它是怎么实现的呢？

可执行文件的 debugger

其实 cpu、操作系统在设计的时候就支持了 debugger 的能力（可见 debugger 的重要性），cpu 里面有 4 个寄存器可以做硬中断，操作系统提供了系统调用来做软中断。这是编译型语言的 debugger 实现的基础。

中断

cpu 只会不断的执行下一条指令，但程序运行过程中难免要处理一些外部的消息，比如 io、网络、异常等等，所以设计了中断的机制，cpu 每执行完一条指令，就会去看下中断标记，是否需要中断了。就像 event loop 每次 loop 完都要检查下是否需要渲染一样。

INT 指令

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 的两种方式。

解释型语言的 debugger

编译型语言因为直接在操作系统之上执行，所以要利用 cpu 和操作系统的中断机制和系统调用来实现 debugger。但是解释型语言是自己实现代码的解释执行的，所以不需要那一套，但是实现思路还是一样的，就是插入一段代码来断住，支持环境数据的查看和代码的执行，当释放断点的时候就继续往下执行。

比如 javascript 中支持 debugger 语句，当解释器执行到这一条语句的时候就会断住。

解释型语言的 debugger 相对简单一些，不需要了解 cpu 的 INT 3 中断。

debugger 客户端

上面我们了解了直接执行和解释执行的代码的 debugger 分别是怎么实现的。我们知道了代码是怎么断住的，那么断住之后呢？怎么把环境数据暴露出去，怎么执行外部代码？

这就需要 debugger 客户端了。

比如 v8 引擎会把设置断点、获取环境信息、执行脚本的能力通过 socket 暴露出去，socket 传递的信息格式就是 v8 debug protocol 。

比如：

设置断点：

1
2
3
4
5
6
7
8
9

{
    "seq":117,
    "type":"request",
    "command":"setbreakpoint",
    "arguments":{
        "type":"function",
        "target":"f"
    }
}

去掉断点：

1
2
3
4
5
6
7
8
9

{
    "seq":117,
    "type":"request",
    "command":"clearbreakpoint",
    "arguments": {
        "type":"function",
        "breakpoint":1
     }
}

继续：

1
2
3
4
5

{
    "seq":117,
    "type":"request",
    "command":"continue"
}

执行代码：

1
2
3
4
5
6
7
8

{
    "seq":117,
    "type":"request",
    "command":"evaluate",
    "arguments":{
        "expression":"1+2"
    }
}

感兴趣的同学可以去 v8 debug protocol 的文档中去查看全部的协议。

基于这些协议就可以控制 v8 的 debugger 了，所有的能够实现 debugger 的都是对接了这个协议，比如 chrome devtools、vscode debugger 还有其他各种 ide 的 debugger。

nodejs 代码的调试

nodejs 可以通过添加 –inspect 的 option 来做调试（也可以是 –inspect-brk，这个会在首行就断住）。

它会起一个 debugger 的 websocket 服务端，我们可以用 vscode 来调试 nodejs 代码，也可以用 chrome devtools 来调试（见 nodejs debugger 文档）。

1
2
3

➜ node --inspect test.js
Debugger listening on ws://127.0.0.1:9229/db309268-623a-4abe-b19a-c4407ed8998d
For help see https://nodejs.org/en/docs/inspector

原理就是实现了 v8 debug protocol。

我们如果自己做调试工具、做 ide，那就要对接这个协议。

debugger adaptor protocol

上面介绍的 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 代码。