今天在修改前端页面的时候，发现程序中有一个页面的加载速度很慢，差不多需要5秒，这其实是难以接受的，我也不知道为什么上线这么长时间了，没人提过这个事儿。
我记得有一个词儿，叫秒开率。
秒开率是指能够在1秒内完成页面的加载。
查询的时候，会访问后台数据库，查询前20条数据，按道理来说，这应该很快才对。
追踪代码，看看啥问题，最后发现问题有三：
大字段批量查询、批量文件落地、读取大文件并进行网络传输，不慢才怪，这一顿骚操作，5秒能加载完毕，已经烧高香了。
经过调查发现，这个PDF模板只有在点击运费模板按钮时才会使用。
打开代码一看，居然是通过FileReader读取的，我了个乖乖~
这有什么问题吗？都是从百度拷贝过来的，百度还会有错吗？而且也测试了，没问题啊。
嗯，对，是没问题，是可以实现需求，可是，为什么用这个？不知道。更别说效率问题了~
优化4：通过缓冲流读取文件。
Java I/O (Input/Output) 是对传统 I/O 操作的封装，它是以流的形式来操作数据的。
在上一篇 《增加索引 + 异步 + 不落地后，从 12h 优化到 15 min》中，提到了4种优化方式，数据库优化、复用优化、并行优化、算法优化。
其中Buffered缓冲流就属于复用优化的一种，这个页面的查询完全可以通过复用优化优化一下。
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;}private 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() 都可能导致从文件中读取字节，转换为字符，然后返回，这可能非常低效。
就像取快递一样，在取快递的时候，肯定是想一次性的取完，避免再来一趟。
对 FileRead 进行包装变成了BufferedReader缓冲字符输入流，其实，Java IO流就是最典型的装饰器模式，装饰器模式通过组合替代继承的方式在不改变原始类的情况下添加增强功能，主要解决继承关系过于复杂的问题，之前整理过一篇装饰器模式，这里就不论述了。
public int read(char cbuf[], int off, int len) throws IOException { return in.read(cbuf, off, len);}private void fill() throws IOException { int dst; if (markedChar <= UNMARKED) { /* No mark */ dst = 0; } else { /* Marked */ int delta = nextChar - markedChar; if (delta >= readAheadLimit) { /* Gone past read-ahead limit: Invalidate mark */ markedChar = INVALIDATED; readAheadLimit = 0; dst = 0; } else { if (readAheadLimit <= cb.length) { /* Shuffle in the current buffer */ System.arraycopy(cb, markedChar, cb, 0, delta); markedChar = 0; dst = delta; } else { /* Reallocate buffer to accommodate read-ahead limit */ char ncb[] = new char[readAheadLimit]; System.arraycopy(cb, markedChar, ncb, 0, delta); cb = ncb; markedChar = 0; dst = delta; } nextChar = nChars = delta; } } int n; do { n = in.read(cb, dst, cb.length - dst); } while (n == 0); if (n > 0) { nChars = dst + n; nextChar = dst; }}核心方法fill()：
既然缓冲这么好用，为啥jdk将缓冲字符数组设置的这么小，才8192个字节？
这是一个比较折中的方案，如果缓冲区太大的话，就会增加单次读写的时间，同样内存的大小也是有限制的，不可能都让你来干这个一件事。
很多小伙伴也肯定用过它的read(char[] cbuf)，它内部维护了一个char数组，每次写/读数据时，操作的是数组，这样可以减少IO次数。
传统 IO 执行的话需要 4 次上下文切换（用户态 -> 内核态 -> 用户态 -> 内核态 -> 用户态）和 4 次拷贝。
NIO中比较常用的是FileChannel，主要用来对本地文件进行 IO 操作。
传统的文件I/O操作可能会变得很慢，这时候mmap就闪亮登场了。
mmap（Memory-mapped files）是一种在内存中创建映射文件的机制，它可以使我们像访问内存一样访问文件，从而避免频繁的文件I/O操作。
使用mmap的方式是在内存中创建一个虚拟地址，然后将文件映射到这个虚拟地址上，这个映射的过程是由操作系统完成的。
实现映射后，进程就可以采用指针的方式读写操作这一段内存，系统会自动回写到对应的文件磁盘上，这样就完成了对文件的读取操作，而不用调用 read、write 等系统函数。
内核空间对这段区域的修改也会直接反映用户空间，从而可以实现不同进程间的文件共享。
在 Java 中，mmap 技术主要使用了 Java NIO （New IO）库中的 FileChannel 类，它提供了一种将文件映射到内存的方法，称为 MappedByteBuffer。MappedByteBuffer 是 ByteBuffer 的一个子类，它扩展了 ByteBuffer 的功能，可以直接将文件映射到内存中。
根据文件地址创建了一层缓存当作索引，放在虚拟内存中，使用时会根据的地址，直接找到磁盘中文件的位置，把数据分段load到系统内存(pagecache)中。
public static String readFileByMmap(String filePath) { File file = new File(filePath); String ret = ""; StringBuilder builder = new StringBuilder(); try (FileChannel channel = new RandomAccessFile(file, "r").getChannel()) { long size = channel.size(); // 创建一个与文件大小相同的字节数组 ByteBuffer buffer = ByteBuffer.allocate((int) size); // 将通道上的所有数据都读入到buffer中 while (channel.read(buffer) != -1) {} // 切换为只读模式 buffer.flip(); // 从buffer中获取数据并处理 byte[] data = new byte[buffer.remaining()]; buffer.get(data); ret = new String(data); } catch (IOException e) { System.out.println("readFileByMmap异常：" + e); } return ret;}mmap 是一种内存映射技术，mmap 相比于传统的 缓冲流 来说，其实就是少了 1 次 CPU 拷贝，变成了数据共享。
虽然减少了一次拷贝，但是上下文切换的次数还是没变。
因为存在一次CPU拷贝，因此mmap并不是严格意义上的零拷贝。
RocketMQ 中就是使用的 mmap 来提升磁盘文件的读写性能。
零拷贝将上下文切换和拷贝的次数压缩到了极致。
在内核的支持下，零拷贝少了一个步骤，那就是内核缓存向用户空间的拷贝，这样既节省了内存，也节省了 CPU 的调度时间，让效率更高。
直接将用户缓冲区干掉，而且没有CPU拷贝，故得名零拷贝。
本文链接：http://www.28at.com/showinfo-26-60995-0.html使用懒加载 + 零拷贝后，程序的秒开率提升至99.99%
声明：本网页内容旨在传播知识，若有侵权等问题请及时与本网联系，我们将在第一时间删除处理。邮件：2376512515@qq.com
Copyright © 2016-2023 天津谷骐科技有限公司 版权所有 sitemap.xml
违法及侵权请联系：2376512515@qq.com 津ICP备18001702号
津公网安备 12010102000574号
