我是否應該總是將InputStream封裝爲BufferedInputStream？

當我知道給定的InputStream是否是緩存以外的東西時，總是將InputStream包裝爲BufferedInputStream是否有意義？例如：我是否應該總是將InputStream封裝爲BufferedInputStream？

InputStream is = API.getFromSomewhere() 
if(!(is instanceof BufferedInputStream)) 
    return new BufferedInputStream(is); 
return is;

來源

2010-06-03 geejay

我不會這麼做，我會把它留在最高的抽象層次上。如果你不打算使用BufferedStream的標記和重置功能，爲什麼還要打包呢？

如果消費者需要它，最好把它包裝在那裏。

來源

2010-06-03 07:44:53

這似乎意味着該商標和復位是唯一有用的東西'BufferedInputStream'增加了一個普通的'InputStream'。從API的意義上說，這可能是正確的，但正如其他人所說的那樣，「BufferedInputStream」負責爲你緩衝讀取。從「FileInputStream」中讀取字節的速度比從「BufferedInputStream」中讀取的速度慢40倍。也就是說，返回'InputStream'並保留你的方法簽名。用戶可以根據需要換行。 – jasonmp85 2010-06-03 08:06:45

我同意從性能的角度來看，最好將它包裝在99.9％的案例中。但是，它確實減輕了消費者的責任，思考如何使用InputStream。消費者的這些假設限制了可重用性。 – 2010-06-03 08:19:53

我認爲在的情況下，而不是更多的0.1％的消費者不會一次讀取一個字節，而是將自己使用某種緩衝的，在這種情況下的BufferedInputStream是無用的開銷。 – 2010-06-03 10:19:47

它也取決於你如何從InputStream讀取。如果您要一次讀取一個字符/字節（即read（）），那麼BufferedInputStream將通過以您的名義等待批量讀取來減少開銷。如果您要將它讀入一個4k或8k字節/字符數組中，那麼BuffredInputStream可能不會使您受益。

來源

2010-06-03 07:56:40

是否有意義總是包裹的InputStream爲的BufferedInputStream，當我知道定InputStream是否是其他的東西比緩衝？

號

這是有道理的，如果你很可能會進行大量小讀取（一個字節或一次幾個字節），或者如果你想使用一些更高層次的功能提供由緩衝的API提供;例如BufferedReader.readLine()方法。

但是，如果你只打算進行大的塊讀取使用read(byte[])和/或read(byte[], int, int)方法，包裹在一個BufferedInputStream的InputStream沒有幫助。

（在回答關於自己的答案@Peter蒂爾曼的評論，該塊讀取使用情況絕對代表InputStream類!!不過的用途超過0.1％，他是在這個意義上正確的，它通常是無害的當你不需要時使用緩衝的API。）

來源

2010-06-03 10:16:51

你可能並不總是需要緩衝，因此，答案是否定的，在某些情況下，它只是開銷。

還有一個原因是「不」，可能會更嚴重。當您在網絡套接字上使用時，如果您也啓用了套接字上的超時，那麼BufferedInputStream（或BufferedReader）可能會導致不可預知的故障。讀取數據包時可能會發生超時。即使您知道有一些非零字節數（請參閱java.net.SocketTimeoutException，它是java.io.InterruptedIOException的子類，因此有bytesTransferred變量可用），您將不再能夠訪問傳輸到該點的數據。

如果您想知道在讀取時如何發生套接字超時，只需考慮調用read(bytes[])方法，並且包含該消息的原始數據包最終將被拆分，但其中一個部分數據包延遲超時（或超時的剩餘部分）。如果再次執行java.io.DataInput（多個字節值的任何讀取，如readLong()或readFully()或BufferedReader.readLine()方法），則可能會更頻繁地發生這種情況。

注意java.io.DataInputStream也就是對於具有超時，因爲它不超時異常表現良好或者socket流不好的候選人。

來源

2010-06-03 11:20:19

至於BufferedInputStream和BufferedReader，這是城市神話。如果讀取超時，（i）您正在讀取，但內部緩衝區爲空，否則您不會讀取; （ii）在超時期限內沒有數據到達。 Ergo沒有數據丟失。試試吧。 – EJP 2010-06-04 00:54:22

@EJP：你讓我真的在想這件事，但我仍然認爲這可能是一個問題。當緩衝流確實需要做I/O（填充緩衝區）時，那麼你就可以得到一個超時異常並且跟蹤緩衝區中有多少字節不會被更新的內部變量。我試圖測試這個，但是，雖然我可以複製超時異常，但我似乎無法複製'bytesTransferred'非零的情況。在此之前，我無法證明這種或那種方式。 [我曾與DataInputStream和超時丟失的數據。] – 2010-06-04 11:18:57

@EJP：也許那麼讀取來自插座的字節數組從不導致由於超時，然後部分讀緩衝器'bytesTransferred'是從未非零（否則會BufferredInputStream失敗）。這也可能是在不同平臺/供應商的JVM實現可能產生不同結果的情況下 - 我剛剛使用Sun/Oracle Java在Windows 7上進行了測試。 – 2010-06-04 11:34:39

我是否應該總是將InputStream封裝爲BufferedInputStream？

回答

相關問題