关于java字节流的read()方法返回值为int的思考

　　我们都知道java中io操作分为字节流和字符流，对于字节流，顾名思义是按字节的方式读取数据，所以我们常用字节流来读取二进制流（如图片，音乐 等文件）。问题是为什么字节流中定义的read()方法返回值为int类型呢？既然它一次读出一个字节数据为什么不返回byte类型呢？（不知道有没有人 和我有同样的困惑，不过既然有了问题咱就得解决。）

于是我翻阅了java的源码，下面先把源码贴出来（以BufferedInputStream/BufferedOutputStream为例）：

//BufferedInputStream中的read()方法的实现

public synchronized int read() throws IOException {
　　if (pos >= count) {
　　　　fill();
　　if (pos >= count)
　　　　return -1;
　　}
　　　　return getBufIfOpen()[pos++] & 0xff;//这边getBufIfOpen()返回的是byte[],而& 0xff是为了保证由char类型向上拓展成int的时候，不进行符号拓展，而是0拓展。  
}

从源码中我们得到的信息是直到getBufIfOpen()方法返回，我们得到的都是byte类型，可是为什么方法的最终返回值是int？

首先我先简单解释下符号扩展，这是指由byte向上转化成更宽的类型时，是扩展的符号位。这对于正数补0，负数补1，例如，定义byte b = -1;在计算机内部它是用八位1111 1111表示的，当扩展成32位整型的时候，一般情况下是1111 1111 1111 1111 1111 1111 1111 1111，即符号扩展，而对于无符号扩展，也称为0扩展，其结果是0000 0000 0000 0000 0000 0000 1111 1111（实际上这样一来值已经变成255了）。过于向上转型和强制向下转型的进一步讨论，我在以后再说。这里要说的是我们能从java源码中得到的第二 个信息，即上面的注释部分，read()方法的最后一行把读到的字节0扩展成了int，也就是说如果我们直接读出来这个值可能就是不对了。这里我又疑惑 了，为什么BufferedOutputStream中的writer()方法能正确读出字节呢？所以我再去查下对应的源码：

public synchronized void write(int b) throws IOException {

if (count >= buf.length) {

flushBuffer();

}

buf[count++] = (byte)b;

}

这里它果断的又将int强制转成了byte（截取后八位）。于是总结下现在得到的信息是，java字节流把byte转成int读出来再转回byte存起来。何必呢？

经过一番思考，我初步有了答案：在用输入流读取一个byte数据时，有时会出现连续8个1的情况，这个值在计算机内部表示-1，正 好符合了流结束标记。所以为了避免流操作数据提前结束，将读到的字节进行int类型的扩展。保留该字节数据的同时，前面都补0，避免出现-1的情况。而真 正读到文件最后结束是通过这句实现的：

[java] view plaincopy

if (pos >= count)  return -1;

[java] view plaincopy

if (pos >= count)  return -1;

所以我们使用的-1这个结束标志是通过这句返回的，而不是输入流读到了一个-1。

这样一来就解决了我们前面的疑惑，也证实了确实有这样实现的必要。对于字符流的读写也可以用类似的方法分析，这里不再赘述。