平時寫IO相關代碼機會挺少的，但卻都知道使用BufferedXXXX來讀寫效率高，沒想到里面還有這么多陷阱，這兩天突然被其中一個陷阱折騰一下：讀一個文件，然后寫到另外一個文件，前后兩個文件居然不一樣？

解決這個問題之后，總結了幾個注意點。

注意點一：Reader/Writer讀寫二進制文件是有問題的?：

上面代碼使用BufferedReader一行一行地讀取一個文件，然后使用BufferedWriter把讀取到的數據寫到另外一個文件中。如果文件是ASCCII形式的，則內容還是能夠正確讀取的。但如果文件是二進制的，則讀寫后的文件與讀寫前是有很大區別的。當然，把上面的readLine()換成read(char[])仍然不能正確讀寫二進制文件的。讀寫二進制文件請接著看下面注意點。

注意點二：read(byte[] b, int offset, int length)中的offset不是指全文件的全文，而是字節數組b的偏移量

現在已經知道使用Reader/Writer不能正確讀取二進制文件，這是因為Reader/Writer是字符流，那就改用字節流ufferedInputStream/BufferedOutputStream，網上搜索到的例子大概是這樣的：

每次讀1024字節，然后寫1024字節。這看似挺正確的，但實際寫出來的文件與原文件是不同的。這樣就懷疑可能是讀寫沒有接上，因而把代碼改成下面的形式：

這是誤以為：先讀一段，寫一段，然后改變偏移量，然后使用新的偏移量再讀一段、寫一段，直到文件讀寫完畢。但這是錯誤的，因為使用BufferedXXX后，里面已經實現了這個過程。而read(byte[] b, int offset, int length)中的offset實際指的是把讀到的數據存入到數組b時，從數組的哪個位置(即offset)開始放置數據；同理，write(byte[] b, int offset, int length)就是把b中的數據，從哪個位置(offset)開始寫到文件中。

注意點三：使用?length=read?(b, 0, 1024)讀數據時，應該使用write(b, 0, length)來寫

第二個注意點中的第一段代碼的做法雖然在網上比較常見，但是有問題的。問題在哪呢？答案是：問題在byte[] b這個數組上。由于二進制文件使用比較工具時，只知道不同、但不能知道哪些不同(是否有更先進的比較工具？)。怎樣確定它的不同呢？方法很簡單：就把二進制文件改成文本文件就能看出結果了(Reader/Writer這種字符流雖然不能正確讀寫二進制文件，但InputStream/OutputStream這些字節流能既能正確讀寫二進制文件，也能正確讀寫文本文件)。由于使用了每次讀1K(1024字節)的方式，所以會看到的結果是：寫后的文件后面多出一段，這一段的長度與原文件大小以及b數組的大小有關。為了進一步確定是什么關系，把讀的文件內容改為"1234567890123"，而把b數組的大小改為10字節，這時結果就出來了：寫后的文件內容變成"12345678901234567890"，就是讀了兩遍。多出的內容的根源在這里：b數組的大小是10字節，而要讀的內容長度是13字節，那就要讀兩次，第一次讀了前10字節，此時b數組內的元素為前10個字符；再讀第二次時，由于可讀內容只有3個字符，那b數組的內容只有前3個字符被改變了，后面7個字符仍然保持上一次讀取的內容。所以直接采用write(b)的方式，在第二次寫文件時，內容就多寫了一段不是第二次讀取到的內容。

下面是正確的讀寫(即每次讀了多少內容，寫入的是多少內容，而不是寫入整個數組)：

注意點四：flush()和close()

flush()是把寫緩沖區內的內容全部”吐“到文件上，如果沒有它，就有可能很多內容還存在于寫緩沖區內，而不是在文件中，也就是還有丟失的可能。

close()中會調用flush()。它是文件真正完成的標志，文件內容寫完成后不關閉文件流，會導致一些”古怪“的問題。這個在網絡中的流更能體現。

所以，寫文件完成后注意關閉文件讀寫流。

創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎

總結

以上是生活随笔為你收集整理的Java写文件导致io过高_161108、Java IO流读写文件的几个注意点的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。