Java性能調(diào)優(yōu)指南—-java.io.BufferedInputStream和java.util.zip.GZIPInputStream
|
1 | final InputStream is = new BufferedInputStream( new FileInputStream( file ) ); |
是否使用緩沖的簡略規(guī)則如下：當(dāng)你的數(shù)據(jù)塊足夠大的時候(100K+)，你不需要使用緩沖，你可以處理任何長度的塊(不需要保證在緩沖前緩沖區(qū)中至少有N bytes可用字節(jié))。在所有的其他情況下，你都需要緩沖輸入數(shù)據(jù)。最簡單的不需要緩沖的例子就是手動復(fù)制文件的過程。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 | public static void copyFile( final File from, final File to ) throws IOException { final InputStream is = new FileInputStream( from ); try { final OutputStream os = new FileOutputStream( to ); try { final byte[] buf = new byte[ 8192 ]; int read = 0; while ( ( read = is.read( buf ) ) != -1 ) { os.write( buf, 0, read ); } } finally { os.close(); } } finally { is.close(); }} |
注1:衡量文件復(fù)制的性能是非常困難的，因?yàn)檫@很大程度上收到操作系統(tǒng)寫入緩存的影響。在我的機(jī)器上復(fù)制一個4.5G的文件到相同的硬盤所花費(fèi)的時間在68至107s之間變化。
注2:文件復(fù)制經(jīng)常通過Java NIO實(shí)現(xiàn)，使用FileChannel.transferTo或者transferFrom 的方法。使用這些方法不需要再在內(nèi)核和用戶態(tài)之間頻繁的轉(zhuǎn)換(在用戶的java程序中將讀入數(shù)據(jù)轉(zhuǎn)換為字節(jié)緩存，再通過內(nèi)核調(diào)用將它復(fù)制回輸出文件中)。相反它們在內(nèi)核模式中傳輸盡可能多的數(shù)據(jù)(直達(dá)231-1字節(jié))，盡可能做到不返回用戶的代碼中。因此，Java NIO會使用較少的CPU周期，并騰出留給其他程序。然而，只有高負(fù)荷的環(huán)境下才能看到這當(dāng)中的差異(在我的機(jī)器中，NIO模式的CPU總占用率為4%，而舊的流模式CPU總占用率則為8-9%)。以下是一個可能的Java NIO實(shí)現(xiàn):
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 | private static void copyFileNio( final File from, final File to ) throws IOException { final RandomAccessFile inFile = new RandomAccessFile( from, "r" ); try { final RandomAccessFile outFile = new RandomAccessFile( to, "rw" ); try { final FileChannel inChannel = inFile.getChannel(); final FileChannel outChannel = outFile.getChannel(); long pos = 0; long toCopy = inFile.length(); while ( toCopy > 0 ) { final long bytes = inChannel.transferTo( pos, toCopy, outChannel ); pos += bytes; toCopy -= bytes; } } finally { outFile.close(); } } finally { inFile.close(); }} |
BufferedInputStream中默認(rèn)的緩沖大小是8192個字節(jié)。緩沖大小實(shí)際上是從輸入設(shè)備中準(zhǔn)備讀取的塊的平均大小。這就是為什么它經(jīng)常值得精確地提高至64K(65536)， 萬一有非常大的輸入文件 — 那些在512K和2M的文件，為了更深一層地減少磁盤讀入的數(shù)量。許多專家也建議將此值設(shè)置為4096的整數(shù)倍 — 一個普通磁盤扇區(qū)的大小。所以，不要將緩沖區(qū)的大小設(shè)置為，像125000這樣的大小，取而代之的應(yīng)該是像131072（128K）這樣的大小。
java.util.zip.GZIPInputStream 是一個能夠很好處理gzip文件輸入的輸入流。它經(jīng)常被用來做這樣的事情：
1 | final InputStream is = new GZIPInputStream( new BufferedInputStream( new FileInputStream( file ) ) ); |
這樣的初始化已經(jīng)足夠好了，不過BufferedInputStream在此處是多余的，因?yàn)?em>GZIPInputStream已經(jīng)擁有了自己的內(nèi)建緩沖區(qū)，它里面有一個字節(jié)緩沖區(qū)(實(shí)際上，它是InflaterInputStream的成員)，被用做此從底層流中讀取壓縮的數(shù)據(jù)，并且將其傳遞給一個inflater。這個緩沖區(qū)默認(rèn)的大小是512字節(jié)，所以它必須被設(shè)置成一個更高的數(shù)值。一個更理想地使用GZIPInputStream的方式如下:
1 | final InputStream is = new GZIPInputStream( new FileInputStream( file ), 65536 ); |
BufferedInputStream.available 方法有一個可能的性能問題，取決于你真正想要接收到的東西。它的標(biāo)準(zhǔn)實(shí)現(xiàn)將返回BufferedInputStream自身的內(nèi)部緩沖區(qū)可用字節(jié)數(shù)和底層輸入流調(diào)用avalibale()結(jié)果的總和。所以，它將盡可能地返回一個精確的數(shù)值。但是在很多案例中，用戶想知道的僅僅是緩沖區(qū)中是否還有空間可用( available() > 0). 在這種情況下，即使BufferedInputStream的緩沖區(qū)中只有一個字節(jié)余留，我們都不需要去查詢底層的輸入流。這顯得非常重要，如果我們有一個FileInputStream包含在BufferedInputStream中–這樣的優(yōu)化會節(jié)省我們在FileInputStream.available()中的磁盤訪問時間。
幸運(yùn)的是，我們可以簡單地解決這樣的問題。BufferedInputStream不是一個final類，所以我們可以繼承并且重載available方法。我們可以看看JDK的源代碼著手準(zhǔn)備。從這里我們還可以發(fā)現(xiàn)Java 6中的實(shí)現(xiàn)有一個bug — 如果BufferedInputStream可用的字節(jié)數(shù)和底層流available()調(diào)用結(jié)果的總和大于Integer.MaxVALUE，這樣就會因?yàn)橐绯龆祷匾粋€負(fù)數(shù)結(jié)果，不過這在Java 7中已經(jīng)得到了解決。
以下是我們改進(jìn)的實(shí)現(xiàn)，它將返回BufferedInputStream的內(nèi)置緩沖區(qū)中可用的字節(jié)數(shù)，又或者是，如果它里面沒有剩余的字節(jié)數(shù)，底層流中的available()方法會被調(diào)用，并且返回調(diào)用后的結(jié)果。在大多數(shù)情況下，這種實(shí)現(xiàn)會極少調(diào)用到底層流中的available()方法，因?yàn)楫?dāng)BufferedInputStream緩沖區(qū)被讀取到最后，這個類會讀取從底層流中讀取更多的數(shù)據(jù)，所以，我們只會在輸入文件的末尾中調(diào)用底層流的available()方法。
1 2 3 4 5 6 7 8 9 10 11 12 13 | public class FasterBufferedInputStream extends BufferedInputStream{ public FasterBufferedInputStream(InputStream in, int size) { super(in, size); } //如果有東西可用，該方法將返回一個正數(shù)，否則它會返回0。 public int available() throws IOException { if (in == null) throw new IOException( "Stream closed" ); final int n = count - pos; return n > 0 ? n : in.available(); }} |
為了測試這個實(shí)現(xiàn)，我嘗試使用標(biāo)準(zhǔn)版的和改進(jìn)版的BufferedInputStream去讀取4.5G的文件，它們都有64K的緩沖區(qū)大小，并且每讀取512或者1024字節(jié)的時候就調(diào)用一次available()方法。干凈的測試需要操作系統(tǒng)在每一次測試之后重啟以清除磁盤緩存。于是我決定在熱身階段讀取文件，當(dāng)文件已經(jīng)在磁盤緩存時就用兩種方法測試性能。測試顯示，標(biāo)準(zhǔn)類的運(yùn)行時間與available()調(diào)用的數(shù)量呈線性關(guān)系。而改進(jìn)的方法運(yùn)行時間看起來卻與調(diào)用的次數(shù)無關(guān)。
| standard, once per 512 bytes | improved, once per 512 bytes | standard, once per 1024 bytes | improved, once per 1024 bytes | |
| Java 6 | 17.062 sec | 2.11 sec | 9.592 sec | 2.047 sec |
| Java 7 | 17.337 sec | 2.125 sec | 9.748 sec | 2.044 sec |
這里是測試的源代碼:
1 2 3 4 5 6 7 8 9 10 11 | private static void testRead( final InputStream is ) throws IOException { final long start = System.currentTimeMillis(); final byte[] buf = new byte[ 512 ]; //or 1024 bytes while ( true ) { if ( is.available() == 0 ) break; is.read( buf ); } final long time = System.currentTimeMillis() - start; System.out.println( "Impl: " + is.getClass().getCanonicalName() + " time = " + time / 1000.0 + " sec");} |
1 2 3 4 | 使用以下的聲明變量調(diào)用以上方法:final InputStream is1 = new BufferedInputStream( new FileInputStream( file ), 65536 );andfinal InputStream is2 = new FasterBufferedInputStream( new FileInputStream( file ), 65536 ); |
|
|
來自： 老匹夫 > 《performance》
