Java---字节流与字符流

1.分类

A:字符流，字节流()

首先考虑一个问题，为什么会出现字符流和字节流，但为什么没有比特流呢？

字节流：对于计算机的IO而言，最小物理级别的单位是位（bit），最小的计量单位和最小的信息单位是字节，也就是说操作与存储设备交互的最小单位是字节，因此没有必要设计小于字节的api。

字符流：计算机中大多数文件都是字节数不固定，比如一个图片可能是100字节，也可能是101字节，这种文件就只能用字节流处理，因为最小字节数差是1。但是有一点不能忽略，计算机中有大量的文本文件，而且文本文件的最小字节数差是根据当前文件编码而定的，很明显看到文本文件最小计量单位并不是字节，而是字符编码对应的字节数，比如ASCII占一个字节，utf-8占四个字节，因此字符流的设计是非常有必要的。

B:节点流，处理流()

节点流即数据流的源头和目的地流；处理流相当于在节点流的源目之间横插一杠，可以用来处理已经存在的数据流。

C:输出流，输入流()

数据流是有方向的，这点很容易理解。

2.流缓冲区

在网上看到一些说法是：字节流没有缓冲区，字符流有缓冲区，并且通过代码进行了验证，验证的依据是，字节流可以实时获取到，而字符流不能实时获取。 我个人对于这个并不认同。

我对于流的缓冲理解是：不管是字节流还是字符流，本质上都有缓冲区，只不过计算机的最小IO交互单位是字节，因此一次最少读取一个字节的数据（存在预读，因此并不只是一个字节那么简单），那么内存中就必须提供大于一个字节的空间（字节的倍数），所以底层设计的时候IO交互最小单位也是字节，包括底层api也是字节级别， 因此字节流都是实时处理，表面上看，字节流好像没有什么缓冲区。而字符流则不同，字符流主要用于处理文本文件，假设字符编码为utf-8，也就是说最小单位是4字节，那么理论上，我们需要提供4字节倍数的内存空间，另一个角度来看，字符流读取的时候需要一次读取4个字节才能得到一个完整的自负，所以他设定的最小空间是4字节，这也就是为什么有些人说字符流有缓冲区。

3：为什么需要缓冲区？

先想象一个场景：搬砖（从A地搬到B地）；两地相差200米，砖块数量固定；假设把一个砖头捡起来拿到手里需要1分钟，从A地到B地需要10分钟，手里的砖砌上墙需要5分钟。

    一种方式：一次拿一个砖块，从A到B，直到搬完；那么一块砖从A到B直到砌上墙需要1+10+10(返程)+5=26分钟，200块砖头需要26x200=5200分钟。

    另一种方式：一次拿200块砖，从A到B；那么200块砖拿到手上需要200分钟，从A到B需要10分钟，砌上墙需要200x5=1000分钟，总共需要200+10++10+1000=1220分钟。

5200和1220这差距不是一点点大。

        假设在A地有一个人从地上把砖捡起来放到你手里，第一种方式，你拿走一块砖，那个人需要等待25分钟再给你第二块砖，这25分钟，假设此人为了高效去干其他事，时间到了又跑过来给你递砖，那么他离开和到来在路上需要花时间，可能需要5分钟，那么为了给你递这200块砖，他总共需要1200分钟；。第二种方式，此人不间断的一分钟给你一个砖，给你递这200块砖只需要200分钟。第一种1200分钟，第二种200分钟。这效率自己琢磨。缓冲区还用我再解释吗？

        缓冲的高效利用的关键点在于缓冲周期间隔中对数据的操作，就算是一次读取一个字节并且理解处理一个字节，这个可以极端的认为也是缓冲，只不过相对较小，操作系统具有预读功能，如果间隔中间处理时间过长很可能使得预读被下一次读取之前释放，这就造成同一块数据在一个业务逻辑中被多次读取和释放。因此我们可以想到一个方式，那就是控制缓冲区的大小，让缓冲区一次读取多个字节，一次性送给应用程序。

        网上之所以说字节流没有缓冲区，我的理解是字节流流的缓冲区只有8bit，而磁盘的读取是以字节的方式，也就是说每读取一个字节，字节流的缓冲区就会填满，此时就会自动刷新，而字符流的缓冲区相对较大，因此在字节读取的机制上，读取一个字节并不能使缓冲区填满，也就不能及时刷新数据，最终导致的结果就是在没有填满或者没有主动刷新的情况下程序中是不能看到数据的输出效果。