重复读取输入流InputStream

1.为什么InputStream不能重复读取

首先，熟悉Java的人可能都知道，Java中的Inputstream是不能重复读取的。但是有没有想过，InputStream为什么不能重复读呢？
其实要回答“为什么”这个问题很简单，就是人家接口就是这么设计的，不能重复读。所以今天要讨论的问题更像是：Java的InputStream为什么要设计为不能重复读？

关于InputStream为什么不能重复读取，网上也各有说法：
有的同学说：

“InputStream就类比成一个杯子，杯子里的水就像InputStream里的数据，你把杯子里的水拿出来了，杯子的水就没有了，InputStream也是同样的道理。”

比喻的非常好，让我们从直观上认识了InputStream为什么不能重复被读。

也有的同学从更深的代码角度去分析：

“在InputStream读取的时候，会有一个pos指针，他指示每次读取之后下一次要读取的起始位置，当读到最后一个字符的时候，pos指针不会重置。”

说的也有道理，就是说InputStream的读取是单向的。但是并不是所有的InputStream实现类都是这样的实现方式。

//BufferedInputStream代码片段：  public synchronized int read() throws IOException {  if (pos >= count) {  fill();  if (pos >= count)  return -1;  }  return getBufIfOpen()[pos++] & 0xff;  }  //FileInputStream代码片段：
public native int read() throws IOException;

我们知道：
Java 的List内部是使用数组实现的，遍历的时候也有一个pos指针。但是没有说List遍历一个第二次遍历就没有了。第二次遍历是创建新的Iterator，所以pos也回到了数组起始位置。对于某些InputStream当然可以也这么做。例如：ByteArrayInputStream ，ByteArrayInputStream就是将一个Java的byte数组保存到对象里，然后读取的时候遍历该byte数组。

public ByteArrayInputStream(byte buf[]) {  this.buf = buf;  this.pos = 0;  this.count = buf.length;
}  public synchronized int read() {  return (pos < count) ? (buf[pos++] & 0xff) : -1;
}

就ByteArrayInputStream而言，要实现重复读取是很简单的，但是为什么没有。我想是为了遵循InputStream的统一标准。
在InputStream的read方法的注释上明确说明：

/** * Reads the next byte of data from the input stream. The value byte is * returned as an <code>int</code> in the range <code>0</code> to * <code>255</code>. If no byte is available because the end of the stream * has been reached, the value <code>-1</code> is returned. This method * blocks until input data is available, the end of the stream is detected, * or an exception is thrown. * * <p> A subclass must provide an implementation of this method. * * @return     the next byte of data, or <code>-1</code> if the end of the *             stream is reached. * @exception  IOException  if an I/O error occurs. */  public abstract int read() throws IOException;

当流到达末尾后，返回-1.

其实像FileInputStream这样的文件流，要实现重复使用可能也并不是很难，利用缓存什么的应该能做到（大文件读取就悲剧了，呵呵呵）。
但是InputStream顾名思义就是一个单向的字节流，跟水流一样，要想再次使用就自己再去源头取一下。
InputStream其实不像杯子，更像是一根水管，要想喝水了，就在把水管架在水源与杯子之间，让水流到杯子里（注意：这个动作完成了之后水管里面就没有水了）。
这样看来，InputStream其实是一个数据通道，只负责数据的流通，并不负责数据的处理和存储等其他工作范畴。
前面讲过，其实有的InputStream实现类是可以实现数据的处理工作的。但是没有这么做，这就是规范和标准的重要性。

2.重复读取InputStream的方法

我们知道Java的InputStream是不能重复被读取的。
但是在有的场合中，我们需要重复利用InputStream的数据。
比如：

一个office word文件流，我需要首先读取InputStream中的前一些字节来判断word文件的实际内容（word文件可以保存html，mht的内容）。然后再根据实际内容决定我要解析InputStream的方式。
一个Html文件流，我需要首先读取InputStream中的一些字节来判断Html文件编码方式。然后再根据html文件编码方式读取Html内容
从socket收到的一个InputStream，我首先需要读取InputStream判断是什么类型的字符串。然后再将InputStream读取写到文件里。
将图片流进行反转后再操作

总之，在实际的工作当中，我们常常会需要多次读取一个InputStream的需求。
如果该InputStream是我们通过某种方式“主动”获取的，那我们可以不必重复读取一个InputStream，而是再次获取一样数据的InputStream来处理。
例如：

InputStream inputStream = new FileInputStream(path);
//利用inputStream
inputStream = new FileInputStream(path);
//再次利用inputStream

InputStream inputStream = httpconn.getInputStream();
//利用inputStream
inputStream = httpconn.getInputStream();
//再次利用inputStream

但是，对于“被动”利用InputStream的接口，在接口内部需要重复利用InputStream，对于InputStream的来源，可能是文件，可能是网络，也可能是内存里的一个String，对于InputStream的方式接口内部不得而知，因此更谈不上在接口内部重复获取了。
例如有这样一个接口：

//将InputStream转换成一个文本字符串
public String convert(InputStream inputStream);

在接口内部我们可能需要首先读取InputStream前n个字节来判断InputStream流的数据流型，然后转化InputStream为一个字符串。

最简单的方式就是缓存，首先将InputStream缓存到内存，然后重复使用内存里的数据。
例如：

package com.gs.cvoud.attachment.converter;  import java.io.ByteArrayInputStream;
import java.io.ByteArrayOutputStream;
import java.io.IOException;
import java.io.InputStream;  import com.gs.cvoud.util.ObjectUtils;  /** * 缓存InputStream，以便InputStream的重复利用 * @author boyce * @version 2014-2-24 */
public class InputStreamCacher {  private static final org.slf4j.Logger logger = org.slf4j.LoggerFactory.getLogger(InputStreamCacher.class);  /** * 将InputStream中的字节保存到ByteArrayOutputStream中。 */  private ByteArrayOutputStream byteArrayOutputStream = null;  public InputStreamCacher(InputStream inputStream) {  if (ObjectUtils.isNull(inputStream))  return;  byteArrayOutputStream = new ByteArrayOutputStream();  byte[] buffer = new byte[1024];    int len;    try {  while ((len = inputStream.read(buffer)) > -1 ) {    byteArrayOutputStream.write(buffer, 0, len);    }  byteArrayOutputStream.flush();  } catch (IOException e) {  logger.error(e.getMessage(), e);  }    }  public InputStream getInputStream() {  if (ObjectUtils.isNull(byteArrayOutputStream))  return null;  return new ByteArrayInputStream(byteArrayOutputStream.toByteArray());  }
}

接口内部使用情景：

InputStreamCacher  cacher = new InputStreamCacher(inputStream);
InputStream stream = cacher.getInputStream();
//读取stream
stream = cacher.getInputStream();

上述的方式是将InputStream缓存到一个ByteArrayOutputStream中，当然缓存的数据类型和方式都是任意的，这只是一种解决思路。
这种方式有一个最大的缺点，就是内存压力。
外部传给接口的InputStream有可能很大。每调用一次接口就将InputStream缓存到内存中，内存要承受的压力是可想而知的。

编程永远都是在时间和空间之间找到一个平衡点，前面说的“主动获取方式”的重复获取也有它的缺点，就是需要重新读取文件，获取重新建立网络连接等，这就是需要消耗更多的时间。

万事万物都是这样，天下没有完美的事，有舍才有得，选择什么就意味着放弃什么，开了一扇窗可能就要关一扇门。所以不管是生活还是编程，我们都需要在舍与得，选择的与放弃的，窗和门之间做出相对合理的抉择，或者说不得不做的抉择。

闲话扯远了，其实重复利用InputStream还有另一种方式：

3.通过mark和reset方法重复利用InputStream

之前，我们已经简单的知道可以通过缓存InputStream来重复利用一个InputStream，但是这种方式的缺点也是明显的，就是要缓存一整个InputStream内存压力可能是比较大的。如果第一次读取InputStream是用来判断文件流类型，文件编码等用的，往往不需要所有的InputStream的数据，或许只需要前n个字节，这样一来，缓存一整个InputStream实际上也是一种浪费。

其实InputStream本身提供了三个接口：
第一个，InputStream是否支持mark，默认不支持。

public boolean markSupported() {  return false;
}

第二个，mark接口。该接口在InputStream中默认实现不做任何事情。

public synchronized void mark(int readlimit) {}

第三个，reset接口。该接口在InputStream中实现，调用就会抛异常。

public synchronized void reset() throws IOException {  throw new IOException("mark/reset not supported");
}

从三个接口定义中可以看出，首先InputStream默认是不支持mark的，子类需要支持mark必须重写这三个方法。
第一个接口很简单，就是标明该InputStream是否支持mark。
mark接口的官方文档解释：
“在此输入流中标记当前的位置。对 reset 方法的后续调用会在最后标记的位置重新定位此流，以便后续读取重新读取相同的字节。
readlimit 参数告知此输入流在标记位置失效之前允许读取许多字节。

mark 的常规协定是：如果方法 markSupported返回 true，则输入流总会在调用 mark 之后记住所有读取的字节，并且无论何时调用方法 reset ，都会准备再次提供那些相同的字节。但是，如果在调用 reset 之前可以从流中读取多于 readlimit 的字节，则根本不需要该流记住任何数据。”

reset接口的官方文档解释：

将此流重新定位到对此输入流最后调用 mark 方法时的位置。
reset 的常规协定是：

如果方法 markSupported 返回 true，则：
如果创建流以来未调用方法 mark，或最后调用 mark 以来从该流读取的字节数大于最后调用 mark 时的参数，则可能抛出 IOException。
如果未抛出这样的 IOException，则将该流重新设置为这种状态：最近调用 mark 以来（或如果未调用 mark，则从文件开始以来）读取的所有字节将重新提供给 read 方法的后续调用方，后接可能是调用 reset 时的下一输入数据的所有字节。
如果方法 markSupported 返回 false，则：
对 reset 的调用可能抛出 IOException。
如果未抛出 IOException，则将该流重新设置为一种固定状态，该状态取决于输入流的特定类型和其创建方式的固定状态。提供给 read 方法的后续调用方的字节取决于特定类型的输入流。

简而言之就是：
调用mark方法会记下当前调用mark方法的时刻，InputStream被读到的位置。
调用reset方法就会回到该位置。
举个简单的例子：

String content = "BoyceZhang!";
InputStream inputStream = new ByteArrayInputStream(content.getBytes());  // 判断该输入流是否支持mark操作
if (!inputStream.markSupported()) {  System.out.println("mark/reset not supported!");
}
int ch;
boolean marked = false;
while ((ch = inputStream.read()) != -1) {  //读取一个字符输出一个字符    System.out.print((char)ch);    //读到 'e'的时候标记一下  if (((char)ch == 'e')& !marked) {    inputStream.mark(content.length());  //先不要理会mark的参数  marked = true;    }    //读到'!'的时候重新回到标记位置开始读  if ((char)ch == '!' && marked) {    inputStream.reset();    marked = false;  }
}  //程序最终输出：BoyceZhang!Zhang!

看了这个例子之后对mark和reset接口有了很直观的认识。
但是mark接口的参数readlimit究竟是干嘛的呢？
我们知道InputStream是不支持mark的。要想支持mark子类必须重写这三个方法，我想说的是不同的实现子类，mark的参数readlimit作用不尽相同。
常用的FileInputStream不支持mark。

对于BufferedInputStream，readlimit表示：InputStream调用mark方法的时刻起，在读取readlimit个字节之前，标记的该位置是有效的。如果读取的字节数大于readlimit，可能标记的位置会失效。

在BufferedInputStream的read方法源码中有这么一段：

} else if (buffer.length >= marklimit) {  markpos = -1;   /* buffer got too big, invalidate mark */  pos = 0;        /* drop buffer contents */  } else {            /* grow buffer */

为什么是可能会失效呢？
因为BufferedInputStream读取不是一个字节一个字节读取的，是一个字节数组一个字节数组读取的。
例如，readlimit=35，第一次比较的时候buffer.length=0（没开始读）<readlimit
然后buffer数组一次读取48个字节。这时的read方法只会简单的挨个返回buffer数组中的字节，不会做这次比较。直到读到buffer数组最后一个字节（第48个）后，才重新再次比较。这时如果我们读到buffer中第47个字节就reset。mark仍然是有效的。虽然47>35。

对于InputStream的另外一个实现类：ByteArrayInputStream，我们发现readlimit参数根本就没有用，调用mark方法的时候写多少都无所谓。

public void mark(int readAheadLimit) {  mark = pos;
}  public synchronized void reset() {  pos = mark;
}

因为对于ByteArrayInputStream来说，都是通过字节数组创建的，内部本身就保存了整个字节数组，mark只是标记一下数组下标位置，根本不用担心mark会创建太大的buffer字节数组缓存。

其他的InputStream子类没有去总结。原理都是一样的。

所以由于mark和reset方法配合可以记录并回到我们标记的流的位置重新读流，很大一部分就可以解决我们的某些重复读的需要。
这种方式的优点很明显：不用缓存整个InputStream数据。对于ByteArrayInputStream甚至没有任何的内存开销。
当然这种方式也有缺点：就是需要通过干扰InputStream的读取细节，也相对比较复杂。

原文：原文地址