Java壓縮20M文件從30秒到1秒的優(yōu)化過(guò)程是什么

本篇內(nèi)容主要講解“Java壓縮20M文件從30秒到1秒的優(yōu)化過(guò)程是什么”，感興趣的朋友不妨來(lái)看看。本文介紹的方法操作簡(jiǎn)單快捷，實(shí)用性強(qiáng)。下面就讓小編來(lái)帶大家學(xué)習(xí)“Java壓縮20M文件從30秒到1秒的優(yōu)化過(guò)程是什么”吧!

有一個(gè)需求需要將前端傳過(guò)來(lái)的10張照片，然后后端進(jìn)行處理以后壓縮成一個(gè)壓縮包通過(guò)網(wǎng)絡(luò)流傳輸出去。之前沒(méi)有接觸過(guò)用Java壓縮文件的，所以就直接上網(wǎng)找了一個(gè)例子改了一下用了，改完以后也能使用，但是隨著前端所傳圖片的大小越來(lái)越大的時(shí)候，耗費(fèi)的時(shí)間也在急劇增加，最后測(cè)了一下壓縮20M的文件竟然需要30秒的時(shí)間。壓縮文件的代碼如下。

public static void zipFileNoBuffer() {     File zipFile = new File(ZIP_FILE);     try (ZipOutputStream zipOut = new ZipOutputStream(new FileOutputStream(zipFile))) {         //開(kāi)始時(shí)間         long beginTime = System.currentTimeMillis();          for (int i = 0; i < 10; i++) {             try (InputStream input = new FileInputStream(JPG_FILE)) {                 zipOut.putNextEntry(new ZipEntry(FILE_NAME + i));                 int temp = 0;                 while ((temp = input.read()) != -1) {                     zipOut.write(temp);                 }             }         }         printInfo(beginTime);     } catch (Exception e) {         e.printStackTrace();     }

這里找了一張2M大小的圖片，并且循環(huán)十次進(jìn)行測(cè)試。打印的結(jié)果如下，時(shí)間大概是30秒。

fileSize:20M consum time:29599

第一次優(yōu)化過(guò)程-從30秒到2秒

進(jìn)行優(yōu)化首先想到的是利用緩沖區(qū) BufferInputStream。在 FileInputStream中  read()方法每次只讀取一個(gè)字節(jié)。源碼中也有說(shuō)明。

/**  * Reads a byte of data from this input stream. This method blocks  * if no input is yet available.  *  * @return     the next byte of data, or <code>-1</code> if the end of the  *             file is reached.  * @exception  IOException  if an I/O error occurs.  */ public native int read() throws IOException;

這是一個(gè)調(diào)用本地方法與原生操作系統(tǒng)進(jìn)行交互，從磁盤(pán)中讀取數(shù)據(jù)。每讀取一個(gè)字節(jié)的數(shù)據(jù)就調(diào)用一次本地方法與操作系統(tǒng)交互，是非常耗時(shí)的。例如我們現(xiàn)在有30000個(gè)字節(jié)的數(shù)據(jù)，如果使用  FileInputStream那么就需要調(diào)用30000次的本地方法來(lái)獲取這些數(shù)據(jù)，而如果使用緩沖區(qū)的話(這里假設(shè)初始的緩沖區(qū)大小足夠放下30000字節(jié)的數(shù)據(jù))那么只需要調(diào)用一次就行。因?yàn)榫彌_區(qū)在第一次調(diào)用  read()方法的時(shí)候會(huì)直接從磁盤(pán)中將數(shù)據(jù)直接讀取到內(nèi)存中。隨后再一個(gè)字節(jié)一個(gè)字節(jié)的慢慢返回。

BufferedInputStream內(nèi)部封裝了一個(gè)byte數(shù)組用于存放數(shù)據(jù)，默認(rèn)大小是8192

優(yōu)化過(guò)后的代碼如下

public static void zipFileBuffer() {     File zipFile = new File(ZIP_FILE);     try (ZipOutputStream zipOut = new ZipOutputStream(new FileOutputStream(zipFile));             BufferedOutputStream bufferedOutputStream = new BufferedOutputStream(zipOut)) {         //開(kāi)始時(shí)間         long beginTime = System.currentTimeMillis();         for (int i = 0; i < 10; i++) {             try (BufferedInputStream bufferedInputStream = new BufferedInputStream(new FileInputStream(JPG_FILE))) {                 zipOut.putNextEntry(new ZipEntry(FILE_NAME + i));                 int temp = 0;                 while ((temp = bufferedInputStream.read()) != -1) {                     bufferedOutputStream.write(temp);                 }             }         }         printInfo(beginTime);     } catch (Exception e) {         e.printStackTrace();     } }

輸出

------Buffer fileSize:20M consum time:1808

可以看到相比較于第一次使用 FileInputStream效率已經(jīng)提升了許多了

第二次優(yōu)化過(guò)程-從2秒到1秒

使用緩沖區(qū) buffer的話已經(jīng)是滿足了我的需求了，但是秉著學(xué)以致用的想法，就想著用NIO中知識(shí)進(jìn)行優(yōu)化一下。

使用Channel

為什么要用 Channel呢?因?yàn)樵贜IO中新出了 Channel和  ByteBuffer。正是因?yàn)樗鼈兊慕Y(jié)構(gòu)更加符合操作系統(tǒng)執(zhí)行I/O的方式，所以其速度相比較于傳統(tǒng)IO而言速度有了顯著的提高。Channel就像一個(gè)包含著煤礦的礦藏，而  ByteBuffer則是派送到礦藏的卡車(chē)。也就是說(shuō)我們與數(shù)據(jù)的交互都是與 ByteBuffer的交互。

在NIO中能夠產(chǎn)生 FileChannel的有三個(gè)類(lèi)。分別是 FileInputStream、 FileOutputStream、以及既能讀又能寫(xiě)的  RandomAccessFile。

源碼如下

public static void zipFileChannel() {     //開(kāi)始時(shí)間     long beginTime = System.currentTimeMillis();     File zipFile = new File(ZIP_FILE);     try (ZipOutputStream zipOut = new ZipOutputStream(new FileOutputStream(zipFile));             WritableByteChannel writableByteChannel = Channels.newChannel(zipOut)) {         for (int i = 0; i < 10; i++) {             try (FileChannel fileChannel = new FileInputStream(JPG_FILE).getChannel()) {                 zipOut.putNextEntry(new ZipEntry(i + SUFFIX_FILE));                 fileChannel.transferTo(0, FILE_SIZE, writableByteChannel);             }         }         printInfo(beginTime);     } catch (Exception e) {         e.printStackTrace();     } }

我們可以看到這里并沒(méi)有使用 ByteBuffer進(jìn)行數(shù)據(jù)傳輸，而是使用了 transferTo的方法。這個(gè)方法是將兩個(gè)通道進(jìn)行直連。

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的效率比循環(huán)一個(gè) Channel讀取出來(lái)然后再循環(huán)寫(xiě)入另一個(gè)  Channel好。操作系統(tǒng)能夠直接傳輸字節(jié)從文件系統(tǒng)緩存到目標(biāo)的 Channel中，而不需要實(shí)際的 copy階段。

copy階段就是從內(nèi)核空間轉(zhuǎn)到用戶(hù)空間的一個(gè)過(guò)程

可以看到速度相比較使用緩沖區(qū)已經(jīng)有了一些的提高。

------Channel fileSize:20M consum time:1416

內(nèi)核空間和用戶(hù)空間

那么為什么從內(nèi)核空間轉(zhuǎn)向用戶(hù)空間這段過(guò)程會(huì)慢呢?首先我們需了解的是什么是內(nèi)核空間和用戶(hù)空間。在常用的操作系統(tǒng)中為了保護(hù)系統(tǒng)中的核心資源，于是將系統(tǒng)設(shè)計(jì)為四個(gè)區(qū)域，越往里權(quán)限越大，所以Ring0被稱(chēng)之為內(nèi)核空間，用來(lái)訪問(wèn)一些關(guān)鍵性的資源。Ring3被稱(chēng)之為用戶(hù)空間。

用戶(hù)態(tài)、內(nèi)核態(tài)：線程處于內(nèi)核空間稱(chēng)之為內(nèi)核態(tài)，線程處于用戶(hù)空間屬于用戶(hù)態(tài)

那么我們?nèi)绻藭r(shí)應(yīng)用程序(應(yīng)用程序是都屬于用戶(hù)態(tài)的)需要訪問(wèn)核心資源怎么辦呢?那就需要調(diào)用內(nèi)核中所暴露出的接口用以調(diào)用，稱(chēng)之為系統(tǒng)調(diào)用。例如此時(shí)我們應(yīng)用程序需要訪問(wèn)磁盤(pán)上的文件。此時(shí)應(yīng)用程序就會(huì)調(diào)用系統(tǒng)調(diào)用的接口  open方法，然后內(nèi)核去訪問(wèn)磁盤(pán)中的文件，將文件內(nèi)容返回給應(yīng)用程序。大致的流程如下

直接緩沖區(qū)和非直接緩沖區(qū)

既然我們要讀取一個(gè)磁盤(pán)的文件，要廢這么大的周折。有沒(méi)有什么簡(jiǎn)單的方法能夠使我們的應(yīng)用直接操作磁盤(pán)文件，不需要內(nèi)核進(jìn)行中轉(zhuǎn)呢?有，那就是建立直接緩沖區(qū)了。

非直接緩沖區(qū)：非直接緩沖區(qū)就是我們上面所講內(nèi)核態(tài)作為中間人，每次都需要內(nèi)核在中間作為中轉(zhuǎn)。

直接緩沖區(qū)：直接緩沖區(qū)不需要內(nèi)核空間作為中轉(zhuǎn)copy數(shù)據(jù)，而是直接在物理內(nèi)存申請(qǐng)一塊空間，這塊空間映射到內(nèi)核地址空間和用戶(hù)地址空間，應(yīng)用程序與磁盤(pán)之間數(shù)據(jù)的存取通過(guò)這塊直接申請(qǐng)的物理內(nèi)存進(jìn)行交互。

既然直接緩沖區(qū)那么快，我們?yōu)槭裁床欢加弥苯泳彌_區(qū)呢?其實(shí)直接緩沖區(qū)有以下的缺點(diǎn)。直接緩沖區(qū)的缺點(diǎn)：

1、不安全

2、消耗更多，因?yàn)樗皇窃贘VM中直接開(kāi)辟空間。這部分內(nèi)存的回收只能依賴(lài)于垃圾回收機(jī)制，垃圾什么時(shí)候回收不受我們控制。

3、數(shù)據(jù)寫(xiě)入物理內(nèi)存緩沖區(qū)中，程序就喪失了對(duì)這些數(shù)據(jù)的管理，即什么時(shí)候這些數(shù)據(jù)被最終寫(xiě)入從磁盤(pán)只能由操作系統(tǒng)來(lái)決定，應(yīng)用程序無(wú)法再干涉。

綜上所述，所以我們使用 transferTo方法就是直接開(kāi)辟了一段直接緩沖區(qū)。所以性能相比而言提高了許多

使用內(nèi)存映射文件

NIO中新出的另一個(gè)特性就是內(nèi)存映射文件，內(nèi)存映射文件為什么速度快呢?其實(shí)原因和上面所講的一樣，也是在內(nèi)存中開(kāi)辟了一段直接緩沖區(qū)。與數(shù)據(jù)直接作交互。源碼如下

//Version 4 使用Map映射文件 public static void zipFileMap() {     //開(kāi)始時(shí)間     long beginTime = System.currentTimeMillis();     File zipFile = new File(ZIP_FILE);     try (ZipOutputStream zipOut = new ZipOutputStream(new FileOutputStream(zipFile));             WritableByteChannel writableByteChannel = Channels.newChannel(zipOut)) {         for (int i = 0; i < 10; i++) {              zipOut.putNextEntry(new ZipEntry(i + SUFFIX_FILE));              //內(nèi)存中的映射文件             MappedByteBuffer mappedByteBuffer = new RandomAccessFile(JPG_FILE_PATH, "r").getChannel()                     .map(FileChannel.MapMode.READ_ONLY, 0, FILE_SIZE);              writableByteChannel.write(mappedByteBuffer);         }         printInfo(beginTime);     } catch (Exception e) {         e.printStackTrace();     } }

打印如下

---------Map fileSize:20M consum time:1305

可以看到速度和使用Channel的速度差不多的。

使用Pipe

Java NIO  管道是2個(gè)線程之間的單向數(shù)據(jù)連接。Pipe有一個(gè)source通道和一個(gè)sink通道。其中source通道用于讀取數(shù)據(jù)，sink通道用于寫(xiě)入數(shù)據(jù)?？梢钥吹皆创a中的介紹，大概意思就是寫(xiě)入線程會(huì)阻塞至有讀線程從通道中讀取數(shù)據(jù)。如果沒(méi)有數(shù)據(jù)可讀，讀線程也會(huì)阻塞至寫(xiě)線程寫(xiě)入數(shù)據(jù)。直至通道關(guān)閉。

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

我想要的效果是這樣的。源碼如下

//Version 5 使用Pip public static void zipFilePip() {      long beginTime = System.currentTimeMillis();     try(WritableByteChannel out = Channels.newChannel(new FileOutputStream(ZIP_FILE))) {         Pipe pipe = Pipe.open();         //異步任務(wù)         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);  }  //異步任務(wù) public static void runTask(Pipe pipe) {      try(ZipOutputStream zos = new ZipOutputStream(Channels.newOutputStream(pipe.sink()));             WritableByteChannel out = Channels.newChannel(zos)) {         System.out.println("Begin");         for (int i = 0; i < 10; i++) {             zos.putNextEntry(new ZipEntry(i+SUFFIX_FILE));              FileChannel jpgChannel = new FileInputStream(new File(JPG_FILE_PATH)).getChannel();              jpgChannel.transferTo(0, FILE_SIZE, out);              jpgChannel.close();         }     }catch (Exception e){         e.printStackTrace();     } }

到此，相信大家對(duì)“Java壓縮20M文件從30秒到1秒的優(yōu)化過(guò)程是什么”有了更深的了解，不妨來(lái)實(shí)際操作一番吧！這里是億速云網(wǎng)站，更多相關(guān)內(nèi)容可以進(jìn)入相關(guān)頻道進(jìn)行查詢(xún)，關(guān)注我們，繼續(xù)學(xué)習(xí)！