使用懒加载 + 零拷贝后，程序的秒开率提升至99.99%

1、线上显示 = 就读取一个文件，为什么会慢呢？
打开代码一看，居然是通过FileReader读取的，我了个乖乖~

这有什么问题吗？都是从百度拷贝过来的，百度还会有错吗？而且也测试了，没问题啊。
嗯，对，是没问题，是可以实现需求，可是，为什么用这个？不知道。更别说效率问题了~
优化4：通过缓冲流读取文件

1、通过字符输入流FileReader读取
FileReader连readLine()方法都没有，我也是醉了~

private static int readFileByReader(String filePath) {
    int result = 0;
    try (Reader reader = new FileReader(filePath)) {
        int value;
        while ((value = reader.read()) != -1) {
            result += value;
        }
    } catch (Exception e) {
        System.out.println("readFileByReader异常：" + e);
    }
    return result;

2、通过缓冲流BufferedReader读取

rivate static String readFileByBuffer(String filePath) {
    StringBuilder builder = new StringBuilder();
    try (BufferedReader reader = new BufferedReader(new FileReader(filePath))) {
        String data = null;
        while ((data = reader.readLine())!= null){
            builder.append(data);
        }
    }catch (Exception e) {
        System.out.println("readFileByReader异常：" + e);
    }
    return builder+"";
}

通过循环模拟了150000个文件进行测试，FileReader耗时8136毫秒，BufferedReader耗时6718毫秒，差不多相差1秒半的时间，差距还是相当大的，俗话说得好，水滴石穿。
同样是read方法，只不过是包了一层，有啥不同呢？
BufferedReader 是一个缓冲字符输入流，可以对 FileRead 进行包装，提供了一个缓存数组，将数据按照一定规则读取到缓存区中，输入流每次读取文件数据时都需要将数据进行字符编码，而 BufferedReader 的出现，降低了输入流访问数据源的次数，将一定大小的数据一次读取到缓存区并进行字符编码，从而提高 IO 的效率。
如果没有缓冲，每次调用 read() 或 readLine() 都可能导致从文件中读取字节，转换为字符，然后返回，这可能非常低效。
核心方法fill()：
字符缓冲输入流，底层有一个8192个元素的缓冲字符数组，当缓冲区的内容读完时，将使用 fill() 方法从硬盘中读取数据填充缓冲数组；
字符缓冲输出流，底层有一个8192个元素的缓冲字符数组，使用flush方法将缓冲数组中的内容写入到硬盘当中；
使用缓冲数组之后，程序在运行的大部分时间内都是内存和内存直接的数据交互过程。内存直接的操作效率是比较高的。并且降低了CPU通过内存操作硬盘的次数；
关闭字符缓冲流，都会首先释放对应的缓冲数组空间，并且关闭创建对应的字符输入流和字符输出流。
既然缓冲这么好用，为啥jdk将缓冲字符数组设置的这么小，才8192个字节？

这是一个比较折中的方案，如果缓冲区太大的话，就会增加单次读写的时间，同样内存的大小也是有限制的，不可能都让你来干这个一件事。
很多小伙伴也肯定用过它的read(char[] cbuf)，它内部维护了一个char数组，每次写/读数据时，操作的是数组，这样可以减少IO次数。
（3）buffer四大属性
mark：标记
position：位置，下一个要被读或写的元素的索引， 每次读写缓冲区数据时都会改变改值， 为下次读写作准备
limit：表示缓冲区的当前终点，不能对缓冲区 超过极限的位置进行读写操作。且极限 是可以修改的
capacity：容量，即可以容纳的最大数据量；在缓 冲区创建时被设定并且不能改变。
4、缓冲流：4 次上下文切换 + 4 次拷贝
传统 IO 执行的话需要 4 次上下文切换（用户态 -> 内核态 -> 用户态 -> 内核态 -> 用户态）和 4 次拷贝。

磁盘文件 DMA 拷贝到内核缓冲区
内核缓冲区 CPU 拷贝到用户缓冲区
用户缓冲区 CPU 拷贝到 Socket 缓冲区
Socket 缓冲区 DMA 拷贝到协议引擎。

NIO之FileChannel**
NIO中比较常用的是FileChannel，主要用来对本地文件进行 IO 操作。
1、FileChannel 常见的方法有
read，从通道读取数据并放到缓冲区中；
write，把缓冲区的数据写到通道中；
transferFrom，从目标通道 中复制数据到当前通道；
transferTo，把数据从当 前通道复制给目标通道。
2、关于Buffer 和 Channel的注意事项和细节
ByteBuffer 支持类型化的put 和 get, put 放入的是什么数据类型，get就应该使用 相应的数据类型来取出，否则可能有 BufferUnderflowException 异常；
可以将一个普通Buffer 转成只读Buffer；
NIO 还提供了 MappedByteBuffer， 可以让文件直接在内存（堆外的内存）中进 行修改， 而如何同步到文件由NIO 来完成；
NIO 还支持 通过多个 Buffer (即 Buffer 数组) 完成读写操作，即 Scattering 和 Gathering。
3、Selector(选择器)
Java 的 NIO，用非阻塞的 IO 方式。可以用一个线程，处理多个的客户端连 接，就会使用到Selector(选择器)；
Selector 能够检测多个注册的通道上是否有事件发生，如果有事件发生，便获取事件然 后针对每个事件进行相应的处理。这样就可以只用一个单线程去管理多个 通道，也就是管理多个连接和请求。
只有在 连接/通道 真正有读写事件发生时，才会进行读写，就大大地减少了系统开销，并且不必为每个连接都创建一个线程，不用去维护多个线程。
避免了多线程之间的上下文切换导致的开销
4、selector的相关方法
open();//得到一个选择器对象
select(long timeout);//监控所有注册的通道，当其 中有 IO 操作可以进行时，将 对应的 SelectionKey 加入到内部集合中并返回，参数用来 设置超时时间
selectedKeys();//从内部集合中得 到所有的 SelectionKey.
内存映射技术mmap
1、文件映射
传统的文件I/O操作可能会变得很慢，这时候mmap就闪亮登场了。mmap（Memory-mapped files）是一种在内存中创建映射文件的机制，它可以使我们像访问内存一样访问文件，从而避免频繁的文件I/O操作。
使用mmap的方式是在内存中创建一个虚拟地址，然后将文件映射到这个虚拟地址上，这个映射的过程是由操作系统完成的。
实现映射后，进程就可以采用指针的方式读写操作这一段内存，系统会自动回写到对应的文件磁盘上，这样就完成了对文件的读取操作，而不用调用 read、write 等系统函数。
内核空间对这段区域的修改也会直接反映用户空间，从而可以实现不同进程间的文件共享

2、Java中使用mmap
在 Java 中，mmap 技术主要使用了 Java NIO （New IO）库中的 FileChannel 类，它提供了一种将文件映射到内存的方法，称为 MappedByteBuffer。MappedByteBuffer 是 ByteBuffer 的一个子类，它扩展了 ByteBuffer 的功能，可以直接将文件映射到内存中。
根据文件地址创建了一层缓存当作索引，放在虚拟内存中，使用时会根据的地址，直接找到磁盘中文件的位置，把数据分段load到系统内存(pagecache)中。

内存映射技术mmap：4 次上下文切换 + 3 次拷贝
mmap 是一种内存映射技术，mmap 相比于传统的 缓冲流 来说，其实就是少了 1 次 CPU 拷贝，变成了数据共享。
虽然减少了一次拷贝，但是上下文切换的次数还是没变。
因为存在一次CPU拷贝，因此mmap并不是严格意义上的零拷贝。
RocketMQ 中就是使用的 mmap 来提升磁盘文件的读写性能。