java IO 类库的基本架构

I/O问题是任何编程语言都无法回避的问题，可以说I/O问题是整个人机交互的核心问题，因为I/O是机器获取和交换信息的主要渠道，在当今这个数据大爆炸时代，I/O问题尤为突出，很容易成为一个性能瓶颈。正因如此，java在I/O上也一直在做持续的优化，如从1.4版开始引入了NIO，提升I/O的性能。

java的I/O操作类在包java.io下，大概有将近80个类，这些类大概可以分成如下4组

• 基于字节操作的I/O接口：InputStream 和 OutputStream
• 基于字符操作的I/O接口：Writer 和 Reader
• 基于磁盘操作的I/O接口：File
• 基于网络操作的I/O接口：Socket

前两组主要是传输数据的数据格式，后两组主要是传输数据的方式，虽然socket类并不在java.io包下。I/O的核心问题要么是数据格式影响I/O操作，要么是传输方式影响I/O操作。I/O只是人机交互的的手段，我们除了关注功能外，还应该关注的就是如何提高它的运行效率。

基于字节的 I/O 操作接口

基于字节的I/O操作接口分别是InputStream 和OutputStream ，InputStream 的类层次结构如图所示

输入流根据数据类型和操作方式又被划分为若干子类，每个子类分别处理不同的操作类型。OutputStream 的类层次结构也类似。

这里就不详细解释每一个子类的用法了。说明两点，

一是操作数据的方式是可以组合使用的，如：

OutputStream out = new BufferedOutputStream(new ObjectOutputStream(new FileOutputStream("fileName")));

二是必须指定流最终写到什么地方，要么写到磁盘，要么写到网络中，其实从上面的层次结构中我们可以发现，写网络实际上也是写文件，只不过写网络还有一步需要处理，就是让底层操作系统再将数据传送到其他地方而不是本地磁盘。

基于字符的I/O 操作接口

不管是磁盘还是网络传输，最小的存储单元都是字节，而不是字符，所以I/O 操作的都是字节而不是字符，但是为什么有操作字符的I/O 接口呢？这是因为在我们的程序中通常操作的数据都是字符形式的，为了操作方便当然要提供一个直接写字符的I/O 接口，如此而已。我们知道从字符到字节必须经过编码转换，而这个编码又非常耗时，而且还会经常出现乱码问题，所以I/O 的编码问题经常让人头痛的问题。

如图所示是写字符的操作接口涉及的类，Writer 类提供了一个抽象方法 write(cahr cbuf[], int off, int len)。

读字符的操作接口也有类似的类结构，读字符的操作接口是 int read(cahr cbuf[] ,int off ,int len )，返回读到的n 个字节数，不管是Writer 还是 Reader 类， 它们都只定义了读取或写入的数据字符的方式，也是就怎么写或读，但是并没有规定数据要写到哪里。

字节与字符的转化接口

另外，数据持久化或网络传输都是以字节进行的，所以必须要有从字符到字节或从字节到字符的转化。从字符到字节需要转化，其中读的转化过程如图

InputStreamReader 类是从字节到字符的转化桥梁，从InputStream 到 Reader 的过程要指定编码字符集，否则将采用操作系统默认的字符集，很可能会出现乱码问题。StreamDecoder正是完成从字节到字符的解码的实现类。也就是当你用如下方式读取一个文件时：

try{
    StringBuffer str = new StringBuffer();
    char[] buf = new char[1024];
    FileReader f = new FileReader("file");
    while(f.read(buf) > 0){
         str.append(buf);
    }
}catch(Exception e){}

　FileReader 类就是按照上面的工作方式读取文件的，FileReader 继承了InputStreamReader类，实际上是读取文件流，然后通过StreamDecoder 解码成char ，只不过这里的解码字符集是默认字符集。

　　写入也是类似的过程。