InputStream复用,mark和reset

简介:

InputStream复用,mark和reset

markSupported

InputStream是否支持mark,默认不支持。

public boolean markSupported() {  
   return false;  
}  

InputStream默认是不支持mark的,子类需要支持mark必须重写这三个方法。

在此输入流中标记当前的位置。对 reset 方法的后续调用会在最后标记的位置重新定位此流,以便后续读取重新读取相同的字节。

readlimit 参数告知此输入流在标记位置失效之前允许读取许多字节。

mark

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

public synchronized void mark(int readlimit) {}

reset

reset接口。该接口在InputStream中实现,调用就会抛异常。

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

将此流重新定位到对此输入流最后调用 mark 方法时的位置。

reset 的常规协定是:

如果方法 markSupported 返回 true,则:如果创建流以来未调用方法 mark,或最后调用 mark 以来从该流读取的字节数大于最后调用 mark 时的参数,则可能抛出 IOException。如果未抛出这样的 IOException,则将该流重新设置为这种状态:最近调用 mark 以来(或如果未调用 mark,则从文件开始以来)读取的所有字节将重新提供给 read 方法的后续调用方,后接可能是调用 reset 时的下一输入数据的所有字节。

如果方法 markSupported 返回 false,则:对 reset 的调用可能抛出 IOException。如果未抛出IOException,则将该流重新设置为一种固定状态,该状态取决于输入流的特定类型和其创建方式的固定状态。提供给 read 方法的后续调用方的字节取决于特定类型的输入流。

简而言之就是:*调用mark方法会记下当前调用mark方法的时刻,InputStream被读到的位置。

调用reset方法就会回到该位置。*

Code

String content = "yydcdut!";  
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);    
    //读到 'c'的时候标记一下  
     if (((char)ch == 'c')& !marked) {    
        inputStream.mark(content.length());  //先不要理会mark的参数  
         marked = true;    
     }    

     //读到'!'的时候重新回到标记位置开始读  
      if ((char)ch == '!' && marked) {    
          inputStream.reset();    
          marked = false;  
      }    
}  
//程序最终输出:yydcdut!dut!  

我们知道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 {    

为什么是可能会失效呢?

因为BufferedInputStream读取不是一个字节一个字节读取的,是一个字节数组一个字节数组读取的。

例如,readlimit=35,第一次比较的时候buffer.length=0(没开始读)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的读取细节,也相对比较复杂。

我是天王盖地虎的分割线




本文转自我爱物联网博客园博客,原文链接:http://www.cnblogs.com/yydcdut/p/5042405.html,如需转载请自行联系原作者

相关文章
|
3月前
Sources close to the matter 的含义和使用场合介绍
Sources close to the matter 的含义和使用场合介绍
22 0
|
7月前
mark 和 reset
mark 和 reset
40 0
|
3月前
|
存储 缓存 安全
Buffer循环机制
Buffer循环机制
26 0
|
4月前
|
存储 Java
10.对象头、Mark Word、monitor、synchronized怎么关联起来?
10.对象头、Mark Word、monitor、synchronized怎么关联起来?
44 0
10.对象头、Mark Word、monitor、synchronized怎么关联起来?
|
NoSQL Java API
lettuce客户端底层bug(-READONLY You can‘t write against a read only replica.)
lettuce客户端底层、READONLY You can't write against a read only replica.
1327 0
lettuce客户端底层bug(-READONLY You can‘t write against a read only replica.)
|
Java C++
Java中对象为null和调用对象清除方法clear()的不同
Java中对象为null和调用对象清除方法clear()的不同
468 0
Kyro - Output 类中没有 clear() 方法
Kyro - Output 类中没有 clear() 方法
67 0
像素缓冲区对象(PBO)的异步Read-Back 源码解析
像素缓冲区对象(PBO)的异步Read-Back 源码解析
186 0
像素缓冲区对象(PBO)的异步Read-Back 源码解析
mode:类型非常多 r:只读 从头部开始读 io.UnsupportedOperation: not writable w:写入 每次都是从头部开始写 原有的内容
mode:类型非常多 r:只读 从头部开始读 io.UnsupportedOperation: not writable w:写入 每次都是从头部开始写 原有的内容
|
SQL NoSQL Oracle
[20180305]手工模拟buffer busy wait.txt
[20180305]手工模拟buffer busy wait.txt --//一般出现buffer busy wait原因,主要是对热块,大量dml操作. --//一种提法:oracle读不会阻塞写,写不会阻塞读,实际上写一定程度会阻塞读,只不过时间很短罢了.
1106 0