最近在探秘kafka为什么如此快？其背后的秘诀又是什么？
怀着好奇之心，开始像剥洋葱 一样逐层内嵌。一步步揭晓kafka能够吊打mq的真因。了解之后不得不说kafka：yyds。
了解到顺序存盘的运用
探测到稀疏索引的引进
知晓其零拷贝技术的威力
嗅觉到mmp（内存映射文件）的神来之笔
......
mmp如此神奇，那么运用于文件压缩，是否同样可以实现飞速压缩呢？
又怀着好奇之心，决定用实际行动证明这个结论（否则我们的知识只能纸上谈兵）
编码是我们的本能功能，好奇之心是我们永远的利器。不能丢
曾几何时，有位BA告诉我他的经历：DEV转为BA后，代码就生疏了，后来他强迫自己每个迭代都领一个小需求鞭策自己。
曾几何时，有位前辈告诉我：即使你以后成长为架构师甚至更高职位，也不能丢失编码这件神器。否则你会发现会很尴尬——会被人称为“需求翻译机”
......
这不是心灵鸡汤，这是来自灵魂的谏言，我深刻了解到：编码真的是学到老活到老的工作。
看到很多优秀的同事离职远去，通过交流感触更加深厚
所以，大家一定记得：学会一个知识要努力应用一遍。这样才能记得牢固；在学习中要不求甚解，完全知道这个知识也要知道为什么这么做
......
场景分析 场景1：小文件单文件压缩 1、原始文件介绍：63.7M、 csv文件 、单个文件2、对比技术介绍：网上流传、使用缓冲区、使用管道、使用mmp3、对比结果展示： 方式1：网上流传（流传在坊间的神话，其实是带刺的玫瑰）小王刚入职不久，有一天突然接到需求，要压缩文件，之前没写过，怎么办？这个时候会在网上搜到这个方法
执行结果（效率很吓人）
zipMethod=withoutBuffer
costTime=327000ms
代码如下：
方式2：使用缓冲区小王很开心，提交代码，翻转了需求状态，可验收。
小花是团队资深技术达人，走查代码发现一脸懵逼：网上搜的？这个会很慢，你再研究研究
小王又换了一种思路，借助缓冲区BufferedOutputStream
执行结果（快了很多）
zipMethod=withBuffer
costTime=5170ms
代码如下：
方式3：使用通道小王怀着忐忑的心情，又一次召集大家走查代码。
小花：速度要求没那么高，这样做已经差不多了，代码可以提交了
其实最近研究kafka，接触过nio，知晓：nio有种技术叫通道：Channel
执行结果（好快）
zipMethod=withChannel
costTime=1642ms
代码如下：
方式4：使用mmp研究kafka过程中，不止知晓nio有种技术叫通道：Channel，还有种技术叫mmp
执行结果（好快）
zipMethod=withMmp
costTime=1554ms
代码如下：
场景2：大文件单文件压缩 1、原始文件介绍：585M、 csv文件 、单个文件2、对比技术介绍：使用缓冲区、使用管道、使用mmp3、对比结果展示： 使用缓冲区使用通道使用mmpcostTime=46034mscostTime=11885mscostTime=10810ms 场景3：大文件多文件压缩 1、原始文件介绍：585M、 csv文件 、5个文件2、对比技术介绍：使用缓冲区、使用管道、使用mmp3、对比结果展示： 使用缓冲区使用通道使用mmpcostTime=173122mscostTime=53982mscostTime=50543ms 分析结论1、对比见下表
压缩场景网上流传使用缓冲区使用通道使用mmp场景1：小文件单文件压缩（60M）327000ms5170ms1642ms1554ms场景2：大文件单文件压缩（585M）--46034ms11885ms10810ms场景3：大文件多文件压缩（5个585M）--173122ms53982ms50543ms场景4：100K文件单文件压缩--28ms26ms24ms场景5：5K文件单文件压缩 18ms20ms23ms场景5：1K文件单文件压缩 15ms21ms24ms结论：
1）网上流传的方法不可取，效率最差2）使用缓冲区虽然性能还凑合，但和两种nio技术（通道和mmp）相比，还是差了很多，尤其是在中型文件（500M左右）的单文件压缩和多文件压缩中，对比更加明显3）通道技术和mmp技术对比相差不大，小型文件基本没影响，大型文件差距也在几秒之间4）文件大于10K时，推荐使用通道技术或者mmp技术进行文件压缩5）文件小于10K时，推荐使用缓冲区技术（比两种nio技术表现了更好的性能）6）如果有些团队在使用api，可以看看其源码是否使用了nio技术。如果不是，建议修改为文中方式另外，操作文件操作时，都可以尝试使用nio技术，测试下其效率，理论上应该都是很可观的
背后机密 1、网上流传方法FileInputStream的read方法如下：
这是调用本地方法与原生操作系统进行交互，从磁盘中读取数据。每读取一个字节数据就调用一次这个方法（一次交互很耗时）。
这个方法还是每次读取一个字节，假如文件很大，这个开销是巨大的
2、使用缓冲区BufferedInputSream read方法如下：
这样虽然也是一次读一个字节，但不是每次都从底层读取数据，而是一次调用底层系统读取了最多buf.length个字节到buf数组中，然后从 buf中一次读一个字节，减少了频繁调用底层接口的开销。
3、使用通道在复制大文件时，FileChannel复制文件的速度比BufferedInputStream/BufferedOutputStream复制文件的速度快了近三分之一，体现出FileChannel的速度优势。NIO的Channel的结构更加符合操作系统执行I/O的方式，所以其速度相比较于传统的IO而言速度有了显著的提高。
操作系统能够直接传输字节从文件系统缓存到目标的Channel中，而不需要实际的copy阶段（copy: 从内核空间转到用户空间的一个过程）
4、使用mmp内存映射文件，是把位于硬盘中的文件看做是程序地址空间中一块区域对应的物理存储器，文件的数据就是这块区域内存中对应的数据，读写文件中的数据，直接对这块区域的地址操作，就可以，减少了内存复制的环节。所以说，内存映射文件比起文件I/O操作，效率要高，而且文件越大，体现出来的差距越大。
到此这篇关于一文探索Java文件读写更高效方式的文章就介绍到这了,更多相关 Java文件读写内容请搜索七叶笔记以前的文章或继续浏览下面的相关文章希望大家以后多多支持七叶笔记！
