[導(dǎo)讀]目錄第一次優(yōu)化過程-從30秒到2秒第二次優(yōu)化過程-從2秒到1秒使用Channel 使用內(nèi)存映射文件使用Pipe 總結(jié) 參考文章有一個(gè)需求需要將前端傳過來的10張照片，然后后端進(jìn)行處理以后壓縮成一個(gè)壓縮包通過網(wǎng)絡(luò)流傳輸出去。之前沒有接觸過用Java壓縮文件的，所

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

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

總結(jié)
參考文章

有一個(gè)需求需要將前端傳過來的10張照片，然后后端進(jìn)行處理以后壓縮成一個(gè)壓縮包通過網(wǎng)絡(luò)流傳輸出去。

之前沒有接觸過用Java壓縮文件的，所以就直接上網(wǎng)找了一個(gè)例子改了一下用了，改完以后也能使用

但是隨著前端所傳圖片的大小越來越大的時(shí)候，耗費(fèi)的時(shí)間也在急劇增加，最后測了一下壓縮20M的文件竟然需要30秒的時(shí)間。

壓縮文件的代碼如下。

			
				public static void zipFileNoBuffer() {
    File zipFile = new File(ZIP_FILE); try (ZipOutputStream zipOut = new ZipOutputStream(new FileOutputStream(zipFile))) { //開始時(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)行測試。打印的結(jié)果如下，時(shí)間大概是30秒。

fileSize:20M consum time:29599

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

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

				
					/**
 * 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-1if 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)行交互，從磁盤中讀取數(shù)據(jù)。每讀取一個(gè)字節(jié)的數(shù)據(jù)就調(diào)用一次本地方法與操作系統(tǒng)交互，是非常耗時(shí)的。

例如我們現(xiàn)在有30000個(gè)字節(jié)的數(shù)據(jù)，如果使用FileInputStream那么就需要調(diào)用30000次的本地方法來獲取這些數(shù)據(jù)，而如果使用緩沖區(qū)的話（這里假設(shè)初始的緩沖區(qū)大小足夠放下30000字節(jié)的數(shù)據(jù)）那么只需要調(diào)用一次就行。

因?yàn)榫彌_區(qū)在第一次調(diào)用read()方法的時(shí)候會直接從磁盤中將數(shù)據(jù)直接讀取到內(nèi)存中。隨后再一個(gè)字節(jié)一個(gè)字節(jié)的慢慢返回。

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

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

					
						public static void zipFileBuffer() {
    File zipFile = new File(ZIP_FILE); try (ZipOutputStream zipOut = new ZipOutputStream(new FileOutputStream(zipFile));
            BufferedOutputStream bufferedOutputStream = new BufferedOutputStream(zipOut)) { //開始時(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)化過程-從2秒到1秒

使用緩沖區(qū)buffer的話已經(jīng)是滿足了我的需求了，但是秉著學(xué)以致用的想法，就想著用NIO中知識進(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則是派送到礦藏的卡車。也就是說我們與數(shù)據(jù)的交互都是與ByteBuffer的交互。

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

源碼如下

									
										public static void zipFileChannel() { //開始時(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();
    }
}

我們可以看到這里并沒有使用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讀取出來然后再循環(huán)寫入另一個(gè)Channel好。操作系統(tǒng)能夠直接傳輸字節(jié)從文件系統(tǒng)緩存到目標(biāo)的Channel中，而不需要實(shí)際的copy階段。