BufferedIntputStream 和 BufferedOutputStream
直接上代碼：
BufferedIntputStream 讀取文本文件
BufferedOutputStream 寫數據
好了，讀也有了，寫也有了，這不就完美了麼。對吧。
其實你仔細的看一看。這，不還是一個一個的去讀取麼，你之前不是跟我說，有緩衝數組的存在麼？我怎麼沒看出來方便了呢？或者效率高了呢？
別急，先看看源碼：
看68行，是不是有一個buf的字節數組，然後你再看看53行，8192，就是這個數組的默認的大小。
再往下看：
看182行，我們不就是用的是這個構造方法的麼？對吧，直接傳入一個InputStream，這個構造方法直接調用了198行的這個構造方法，先看一下它調用的時候用的是不是那個默認的大小，對吧。最後是203行，是不是生成了一個默認大小爲8192的字節數組。至於這個數組怎麼用，就自己去看看先把，先講到這裏。
可以了，源碼也看完了，demo也寫完了。好像也就多了一個緩衝，有啥區別呢？
往下看，
現在你改一下demo中的writeFileUseBufferedOutputStream方法中的文件名，文件名起一個其他的，然後你再註釋掉 bos.close(); 這行代碼以及相關的try-catch。
運行一遍，你會發現，咦，我文件裏面怎麼沒數據呢？
對了，就是這個效果，文件裏面沒數據。
然後再來個升級版，現在文件名再換一個，bos.close(); 保持註釋，然後把要寫的String 寫多一點（要大於8192），
運行一下，你會發現，咦，怎麼數據只寫入了一些，後面的那些沒寫進去呢？
注意到沒？我讓你加多點數據，同時要大於8192個，對吧，這就對了。
現在來解釋一下上面這個現象，這其實都是緩衝造成的結果，它有個特點，就是緩衝區未滿的時候，是不會寫進去的，只有當緩衝區滿的時候，纔會寫進去。
那爲什麼第一次的時候那麼少數據也能寫進去呢？我不是讓你註釋掉bos.close(); 麼，這就對了，close的時候，不論你緩衝區的數據滿不滿，都寫進去，因爲結束了。
其實緩衝是有用的，緩衝數組是內存中的，而我們訪問的數據是在硬盤中，所以，讀數據的時候，是一次將8192大小的數據讀出來，寫進內存，然後再進行給程序去讀，反過來，寫也是一樣的，寫的時候也是先保存在緩衝數組中，然後滿的時候再自動的寫進去，直到close，close 表示結束了，所以也就要把剩餘的數據也寫進去了。
偷偷的告訴你，BufferedOutputStream有一個方法：flush(); 手動刷新，調用這個方法也可以往硬盤裏面寫入數據！
緩衝數組可以減少對硬盤的訪問，同時可以提高讀寫的效率，這裏就不對比了，要對比的話，自己可以寫一個小的demo去嘗試一下，在運行的前後加一句System.currentTimeMillis();，記錄一下起始的當前毫秒數，然後再相減，然後記得多運行幾次，去均值，取出來的均值進行對比一下，你就會發現。BufferedInputStream 和 BufferedOutputStream 讀寫文件的效率比 FileInputStream 和 FileOutputStream 的讀寫的效率高很多！
最後附上IO篇的目錄
FileInputStream和FileOutputStream的簡單使用
Java_IO_BufferedIntputStream_And_BufferedOutputStream
Java_IO_ObjectInputStream_And_ObjectOutputStream
Java_IO_SequenceInputStream文件的合併
