Java - 从文件压缩聊一聊I/O一二事

淡淡的烟草味﹌ 2022-10-27 12:07 184阅读 0赞

### 文章目录 ###

*  背景
 *  问题复现
 *   *  Version1: no buffer
     *  Version 2 : with buffer
     *   *  提速原因源码分析
     *  Version 3 : nio - Channel
     *  Version 4 : nio - Channel With Buffer
     *  Version 5 : MMAP
     *  Version 6 : PIPE
 *  扩展知识
 *   *  内核空间和用户空间
     *  直接缓冲区和非直接缓冲区
     *   *  非直接缓冲区
         *  直接缓冲区
         *  比较

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3lhbmdzaGFuZ3dlaQ_size_16_color_FFFFFF_t_70]

--------------------

# 背景 #

有个文件压缩的需求，小伙伴一顿操作猛如虎 ， 小文件那是咔咔一顿骚

![在这里插入图片描述][20210203224936580.png]

可是突然一个几十兆的文件，跑了100秒还没出来。。。。

![在这里插入图片描述][20210203225021494.png]

--------------------

/** * @author 小工匠 * @version 1.0 * @description: TODO * @date 2021/2/3 16:40 * @mark: show me the code , change the world */
    public class FileCompress { 
    
    
        //要压缩的文件所在所存放位置
        public static String COMPRESS_FILE_PATH = "D:/test/1.pdf";
    
        //zip压缩包所存放的位置
        public static String ZIP_FILE = "D:/test/1.zip";
    
        //要压缩的文件
        public static File COMPRESS_FILE = null;
    
        //文件大小
        public static long FILE_SIZE = 0;
    
        //文件名
        public static String FILE_NAME = "";
    
        //文件后缀名
        public static String SUFFIX_FILE = "";
    
        static { 
    
            File file = new File(COMPRESS_FILE_PATH);
    
            COMPRESS_FILE = file;
    
            FILE_NAME = file.getName();
    
            FILE_SIZE = file.length();
    
            SUFFIX_FILE = FILE_NAME.substring(FILE_NAME.indexOf('.'));
        }
    
       public static void main(String[] args) throws RunnerException { 
    			...........
    			...........
    			...........
    	}
    }

--------------------

# 问题复现 #

为了说明问题，模拟下事发现场

![在这里插入图片描述][20210203225122691.gif_pic_center]

## Version1: no buffer ##

public static void zipFileVersion1() { 
            File zipFile = new File(ZIP_FILE);
            try (ZipOutputStream zipOut = new ZipOutputStream(new FileOutputStream(zipFile))) { 
                //开始时间
                long beginTime = System.currentTimeMillis();
    
                try (InputStream input = new FileInputStream(COMPRESS_FILE)) { 
                    zipOut.putNextEntry(new ZipEntry(FILE_NAME + 1));
                    int temp = 0;
                    while ((temp = input.read()) != -1) { 
                        zipOut.write(temp);
                    }
                }
                long cost = (System.currentTimeMillis() - beginTime);
    
                System.out.println("fileSize:" + FILE_SIZE / 1024 / 1024  + "M");
                System.out.println("zip file cost time:" + cost / 1000 + "s");
            } catch (Exception e) { 
                e.printStackTrace();
            }
        }

![在这里插入图片描述][202102032258262.png]

就压缩一个pdf ， 60来兆

![在这里插入图片描述][20210203225906864.png]

问题很明显，连缓冲也不用，面子不能给呀

## Version 2 : with buffer ##

public static void zipFileVersion() { 
            long beginTime = System.currentTimeMillis();
            FileOutputStream fos = null;
            ZipOutputStream zos = null;
            try { 
                byte[] buffer = new byte[1024];
    
                fos = new FileOutputStream(ZIP_FILE);
    
                zos = new ZipOutputStream(fos);
                File srcFile = COMPRESS_FILE;
                FileInputStream fis = new FileInputStream(srcFile);
                zos.putNextEntry(new ZipEntry("artisan" + SUFFIX_FILE));
                int length;
                while ((length = fis.read(buffer)) > 0) { 
                    zos.write(buffer, 0, length);
                }
                zos.closeEntry();
                fis.close();
            } catch (IOException e) { 
                System.out.println("Error : " + e);
            } finally { 
                try { 
                    zos.close();
                } catch (IOException e) { 
                    e.printStackTrace();
                }
                long cost = (System.currentTimeMillis() - beginTime);
                System.out.println("fileSize:" + FILE_SIZE / 1024 / 1024 + "M");
                System.out.println("test zip file cost time:" + cost  + "ms");
            }
        }

![在这里插入图片描述][20210204084857754.png]

public static void zipFileVersion2() {  
        	long beginTime = System.currentTimeMillis();
            File zipFile = new File(ZIP_FILE);
            try { 
                ZipOutputStream zipOut = new ZipOutputStream(new BufferedOutputStream(new FileOutputStream(zipFile)));
                BufferedOutputStream bufferedOutputStream = new BufferedOutputStream(zipOut);
                BufferedInputStream bufferedInputStream = new BufferedInputStream(new FileInputStream(COMPRESS_FILE));
                zipOut.putNextEntry(new ZipEntry("artisan"+ SUFFIX_FILE));
                int temp = 0;
                while ((temp = bufferedInputStream.read()) != -1) { 
                    bufferedOutputStream.write(temp);
                }
                zipOut.closeEntry();
                bufferedInputStream.close();
                zipOut.close();
                long cost = (System.currentTimeMillis() - beginTime);
    
                System.out.println("fileSize:" + FILE_SIZE / 1024 / 1024 + "M");
                System.out.println("zip file cost time:" + cost  + "ms");
            } catch (Exception e) { 
                e.printStackTrace();
            }
        }

![在这里插入图片描述][20210203232021590.png]

![在这里插入图片描述][20210203230412512.png]

wtf , 直接干到2.8秒，发生了什么

![在这里插入图片描述][20210203230433247.gif_pic_center]

--------------------

### 提速原因源码分析 ###

我们先看一下，version1的核心读取文件的方法

**FileInputStream\#read**

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3lhbmdzaGFuZ3dlaQ_size_16_color_FFFFFF_t_70 1]  
可以看到read0() 一个调用本地方法与原生操作系统进行交互，从磁盘中读取数据。每读取一个字节的数据就调用一次本地方法与操作系统交互，一个63M的文档，转换成直接，那得交互多少次…那耗时…

而如果使用缓冲区的话（这里假设初始的缓冲区大小足够放下63M的数据）那么只需要调用一次就行。因为缓冲区在第一次调用read()方法的时候会直接从磁盘中将数据直接读取到内存中，随后再一个字节一个字节的慢慢返回。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3lhbmdzaGFuZ3dlaQ_size_16_color_FFFFFF_t_70 2]

![在这里插入图片描述][20210203232440198.png]

可以看到 BufferedInputStream内部封装了一个byte数组用于存放数据，默认大小是8192  
![在这里插入图片描述][20210203232633490.gif_pic_center]

--------------------

## Version 3 : nio - Channel ##

满足了吗？

![在这里插入图片描述][20210203233014929.png]

上面都是传统I/O操作，不想用用nio么？

NIO中 的Channel和ByteBuffer，它们的结构更加符合操作系统执行I/O的方式，所以其速度相比较于传统IO而言速度有了显著的提高。

Channel管道比作成铁路，buffer缓冲区比作成火车(运载着货物) .

NIO就是通过Channel管道运输着存储数据的Buffer缓冲区的来实现数据的处理

--------------------

在NIO中能够产生FileChannel的有三个类 分别是

*  FileInputStream
 *  FileOutputStream
 *  既能读又能写的RandomAccessFile

public static void zipFileVersion3() {  
            long beginTime = System.currentTimeMillis();
            File zipFile = new File(ZIP_FILE);
            try (ZipOutputStream zipOut = new ZipOutputStream(new FileOutputStream(zipFile));
                 WritableByteChannel writableByteChannel = Channels.newChannel(zipOut)) { 
                try (FileChannel fileChannel = new FileInputStream(COMPRESS_FILE).getChannel()) { 
                    zipOut.putNextEntry(new ZipEntry("artisan" + SUFFIX_FILE));
                    fileChannel.transferTo(0, FILE_SIZE, writableByteChannel);
                }
    
                long cost = (System.currentTimeMillis() - beginTime);
    
                System.out.println("fileSize:" + FILE_SIZE / 1024 / 1024 + "M");
                System.out.println("zip file cost time:" + cost  + "ms");
            } catch (Exception e) { 
                e.printStackTrace();
            }
        }

![在这里插入图片描述][20210203233415973.png]

可以看到这里并没有使用ByteBuffer进行数据传输，而是使用了transferTo的方法。这个方法是将两个通道进行直连。

来看一下官方的说明

This method is potentially much more efficient than a simple loop
    * that reads from this channel and writes to the target channel.  Many
    * operating systems can transfer bytes directly from the filesystem cache
    * to the target channel without actually copying them.

大概意思就是使用transferTo的效率比循环一个Channel读取出来然后再循环写入另一个Channel好。操作系统能够直接传输字节从文件系统缓存到目标的Channel中，而不需要实际的copy阶段。

那什么是copy阶段呢？ 【从内核空间转到用户空间的一个过程】

--------------------

## Version 4 : nio - Channel With Buffer ##

public static void zipFileChannelBuffer() {  
            long beginTime = System.currentTimeMillis();
            File zipFile = new File(ZIP_FILE);
            try (ZipOutputStream zipOut = new ZipOutputStream(new BufferedOutputStream(new FileOutputStream(zipFile)));
                 WritableByteChannel writableByteChannel = Channels.newChannel(zipOut)) { 
                try (FileChannel fileChannel = new FileInputStream(COMPRESS_FILE).getChannel()) { 
                    zipOut.putNextEntry(new ZipEntry("artisan" + SUFFIX_FILE));
                    fileChannel.transferTo(0, FILE_SIZE, writableByteChannel);
                }
                printInfo(beginTime);
            } catch (Exception e) { 
                e.printStackTrace();
            }
        }

![在这里插入图片描述][20210203234815862.png]

--------------------

## Version 5 : MMAP ##

NIO中新出的另一个特性就是内存映射文件，内存映射文件为什么速度快呢？其实是在内存中开辟了一段直接缓冲区,与数据直接作交互。

public static void zipFileMMAP() { 
            //开始时间
            long beginTime = System.currentTimeMillis();
            File zipFile = new File(ZIP_FILE);
            try (ZipOutputStream zipOut = new ZipOutputStream(new FileOutputStream(zipFile));
                 WritableByteChannel writableByteChannel = Channels.newChannel(zipOut)) { 
                zipOut.putNextEntry(new ZipEntry("artisan" + SUFFIX_FILE));
    
                //内存中的映射文件
                MappedByteBuffer mappedByteBuffer = new RandomAccessFile(COMPRESS_FILE_PATH, "r").getChannel()
                        .map(FileChannel.MapMode.READ_ONLY, 0, FILE_SIZE);
    
                writableByteChannel.write(mappedByteBuffer);
                long cost = (System.currentTimeMillis() - beginTime);
    
                System.out.println("fileSize:" + FILE_SIZE / 1024 / 1024 + "M");
                System.out.println("mmap file cost time:" + cost  + "ms");
            } catch (Exception e) { 
                e.printStackTrace();
            }
        }

![在这里插入图片描述][20210205000238122.png]

--------------------

## Version 6 : PIPE ##

Java NIO 管道是2个线程之间的单向数据连接。Pipe有一个source通道和一个sink通道。其中source通道用于读取数据，sink通道用于写入数据。

Whether or not a thread writing bytes to a pipe will block until another
     thread reads those bytes

大概意思就是写入线程会阻塞至有读线程从通道中读取数据。如果没有数据可读，读线程也会阻塞至写线程写入数据。直至通道关闭。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3lhbmdzaGFuZ3dlaQ_size_16_color_FFFFFF_t_70 3]

public static void zipFilePip() { 
    
            long beginTime = System.currentTimeMillis();
            try(WritableByteChannel out = Channels.newChannel(new FileOutputStream(ZIP_FILE))) { 
                Pipe pipe = Pipe.open();
                //异步任务
                CompletableFuture.runAsync(()->runTask(pipe));
    
                //获取读通道
                ReadableByteChannel readableByteChannel = pipe.source();
                ByteBuffer buffer = ByteBuffer.allocate(((int) FILE_SIZE)*10);
                while (readableByteChannel.read(buffer)>= 0) { 
                    buffer.flip();
                    out.write(buffer);
                    buffer.clear();
                }
            }catch (Exception e){ 
                e.printStackTrace();
            }
            printInfo(beginTime);
    
        }
    
        //异步任务
        public static void runTask(Pipe pipe) { 
    
            try(ZipOutputStream zos = new ZipOutputStream(Channels.newOutputStream(pipe.sink()));
                WritableByteChannel out = Channels.newChannel(zos)) { 
                System.out.println("Begin");
                    zos.putNextEntry(new ZipEntry("artisan"+SUFFIX_FILE));
    
                    FileChannel jpgChannel = new FileInputStream(new File(COMPRESS_FILE_PATH)).getChannel();
    
                    jpgChannel.transferTo(0, FILE_SIZE, out);
    
                    jpgChannel.close();
            }catch (Exception e){ 
                e.printStackTrace();
            }
        }

--------------------

# 扩展知识 #

## 内核空间和用户空间 ##

在常用的操作系统中为了保护系统中的核心资源，于是将系统设计为四个区域，越往里权限越大，所以Ring0被称之为内核空间，用来访问一些关键性的资源。Ring3被称之为用户空间。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3lhbmdzaGFuZ3dlaQ_size_16_color_FFFFFF_t_70 4]

用户态、内核态：线程处于内核空间称之为内核态，线程处于用户空间属于用户态。

首先需要明确的一点是： 应用程序是都属于用户态 。 那么如果应用程序需要访问核心资源怎么办呢？

那就需要调用内核中所暴露出的接口用以调用，称之为系统调用。比如需要访问磁盘上的文件。此时应用程序就会调用系统调用的接口open方法，然后内核去访问磁盘中的文件，将文件内容返回给应用程序。

大致的流程如下

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3lhbmdzaGFuZ3dlaQ_size_16_color_FFFFFF_t_70 5]

--------------------

## 直接缓冲区和非直接缓冲区 ##

### 非直接缓冲区 ###

NIO通过Channel连接磁盘文件与应用程序，通过ByteBuffer缓冲区存取数据进行双向的数据传输。

物理磁盘的存取是操作系统进行管理的，与物理磁盘的数据操作需要经过内核地址空间 ,而应用程序是通过JVM分配的缓冲空间。 一个属于内核空间，一个属于应用空间，而数据需要在内核空间和用户空间进行数据的来回拷贝。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3lhbmdzaGFuZ3dlaQ_size_16_color_FFFFFF_t_70 6]

那有什么办法避免用户态和内核态的切换吗。 少切换 是不是可以提高效率呢？

![在这里插入图片描述][2021020423532288.jpg_pic_center]

有的 ，直接缓冲区

### 直接缓冲区 ###

直接缓冲区则不再通过内核地址空间和用户地址空间的缓存数据的复制传递，而是在物理内存中申请了一块空间，这块空间映射到内核地址空间和用户地址空间，应用程序与磁盘之间的数据存取之间通过这块直接申请的物理内存进行。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3lhbmdzaGFuZ3dlaQ_size_16_color_FFFFFF_t_70 7]

--------------------

### 比较 ###

那既然直接缓冲区的性能更高、效率更快，为什么还要存在两种缓冲区呢？因为直接缓冲区也存在着一些缺点：

（1）不安全

（2）消耗更多，因为它不是在JVM中直接开辟空间。这部分内存的回收只能依赖于垃圾回收机制，垃圾什么时候回收不受我们控制。

（3）数据写入物理内存缓冲区中，程序就丧失了对这些数据的管理，即什么时候这些数据被最终写入从磁盘只能由操作系统来决定，应用程序无法再干涉。

所以刚才使用transferTo方法就是直接开辟了一段直接缓冲区。所以性能相比而言提高了许多

![在这里插入图片描述][20210203235539792.gif_pic_center]

--------------------

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3lhbmdzaGFuZ3dlaQ_size_16_color_FFFFFF_t_70]: /images/20221024/a80c630b191f4bfa89f7f92c8e030f75.png
[20210203224936580.png]: /images/20221024/50d3e1ac834a4ea682fb47acfda856f3.png
[20210203225021494.png]: /images/20221024/aff084f58ea147de8cba5d2c82aab7a5.png
[20210203225122691.gif_pic_center]: /images/20221024/e2a7e1f9bbe540f7bfda0a64f9dce01c.png
[202102032258262.png]: /images/20221024/37894e37fba4440c97874a8104181b40.png
[20210203225906864.png]: /images/20221024/77e3dd129d4a4e028bc2304416fe8d47.png
[20210204084857754.png]: /images/20221024/f6866ee1e59941e68f3f2a960f5e5d04.png
[20210203232021590.png]: /images/20221024/9f2de58b1be9443fa55b64c5f38b578e.png
[20210203230412512.png]: /images/20221024/1497ebf4132144e8a6e1ccde2048cfd3.png
[20210203230433247.gif_pic_center]: /images/20221024/82ef54c0598a4deda7e34df50c245e71.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3lhbmdzaGFuZ3dlaQ_size_16_color_FFFFFF_t_70 1]: /images/20221024/72f3cb6888fb43a2867169d7c5e1f61b.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3lhbmdzaGFuZ3dlaQ_size_16_color_FFFFFF_t_70 2]: /images/20221024/0527b7d6fc314771a09d90b86950f0dd.png
[20210203232440198.png]: /images/20221024/445c01e76ea9422186dfa73ec3e47cac.png
[20210203232633490.gif_pic_center]: /images/20221024/74f7d74e835744b8b21bd2991f245234.png
[20210203233014929.png]: /images/20221024/4b7e0d9d45754c879081eecab32fc89a.png
[20210203233415973.png]: /images/20221024/91d66c782db14846ac71b42626bd9695.png
[20210203234815862.png]: /images/20221024/3d9f51bf3e7146838b64bb2688c0d4e6.png
[20210205000238122.png]: /images/20221024/cd213d108c7a41b4997cd9409d9dce9d.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3lhbmdzaGFuZ3dlaQ_size_16_color_FFFFFF_t_70 3]: /images/20221024/da399a8c8def449c9cddbb8b711d50b3.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3lhbmdzaGFuZ3dlaQ_size_16_color_FFFFFF_t_70 4]: /images/20221024/10e393ffffd046d98426aaab2af55116.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3lhbmdzaGFuZ3dlaQ_size_16_color_FFFFFF_t_70 5]: /images/20221024/5bddfb1f76d948629288aeaab0c23b5e.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3lhbmdzaGFuZ3dlaQ_size_16_color_FFFFFF_t_70 6]: /images/20221024/f70f9d9c40f4477b95e75e9dd00cb2a8.png
[2021020423532288.jpg_pic_center]: /images/20221024/510fccbc28904313a5a9521015f6da26.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3lhbmdzaGFuZ3dlaQ_size_16_color_FFFFFF_t_70 7]: /images/20221024/8c60dfb76d0d43b0a2a926e2eb163bfb.png
[20210203235539792.gif_pic_center]: /images/20221024/2b8b825c3a584b6f9b10160886f1ee08.png