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篇的目录
java_IO 总览
FileInputStream和FileOutputStream的简单使用
Java_IO_BufferedIntputStream_And_BufferedOutputStream
Java_IO_ObjectInputStream_And_ObjectOutputStream
Java_IO_字节流_Reader_and_Writer
Java_IO_SequenceInputStream文件的合并
