找出InputStream是否关闭 [英] Find out whether an InputStream is closed

查看:198
本文介绍了找出InputStream是否关闭的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

Java是否有任何可靠的方法来确定 java.io.InputStream 是否在我尝试从其读取之前关闭?

我的用例是我有一个采用 InputStream 参数并从中读取的方法.该方法在其自己的线程中运行,如果输入流关闭,我想终止该线程.

InputStream 实现了 Closeable ,它提供了 close()方法,但是显然无法查询实例是否已经关闭./p>

尝试从封闭的 InputStream 中读取将抛出 IOException ,但这可能有其他原因,并且接口协定中没有任何内容说明此条件是永久性的还是永久性的如果在某些情况下,它有可能在某个时候消失.

我的方法的调用者可以提供所需的 InputStream 的任何子类,因此不能依靠特定的子类行为.

还有其他想法吗?

解决方案

否.没有用于确定流是否已关闭的API.

应用程序应该(通常)设计的,因此没有必要明确地跟踪流的状态.流应该在ARM块中打开并可靠地关闭,并且在该块内部,应该安全地假定流是打开的.惯用ARM块时,它自然会将引用的作用域限定为流,以便在关闭流之后没有人可以访问它.

有多种方法可以在逻辑上关闭"流,并且在进行 read()调用之前,许多流实现都无法检测到这一点.例如,如果服务器关闭套接字,则客户端中套接字对象的内部状态不太可能异步反映这一情况.相反,下一次读取数据的调用将检测到关闭并更新状态.在此示例中,如果完全关闭了套接字,则 read()调用将返回EOF以向应用程序发出信号,表明已安全接收所有数据.如果连接异常终止,则该调用将引发异常,以指示某些数据可能已丢失.

可以合理地假设抛出 IOException 的流已死,并且进一步尝试读取该流将继续失败.如果在调用 read()之前 可以检测到这种情况,那么您大概还是可以用相同的方式处理它.

此方法的例外是某些流支持读取超时,如果在一段时间内未收到任何输入,但该流保持有效,则会引发异常.对于调用者来说,将这样的流传递给显式支持重试读取的方法才有意义.

Does Java have any reliable way of determining whether a java.io.InputStream is closed before I attempt to read from it?

My use case is that I have a method that takes an InputStream argument and reads from it. The method runs in its own thread, and I want to terminate the thread if the input stream is closed.

InputStream implements Closeable, which provides a close() method but apparently no way to query if the instance has already been closed.

Attempting to read from closed InputStream will throw an IOException, but that could have other causes, and there is nothing in the interface contract stating whether this condition is permanent or if, under some circumstances, there is a chance it will go away sometime.

Callers of my method can supply any subclass of InputStream they wish, so relying on specific subclass behavior is not an option.

Any other ideas?

解决方案

No. There's no API for determining whether a stream has been closed.

Applications should be (and generally are) designed so it isn't necessary to track the state of a stream explicitly. Streams should be opened and reliably closed in an ARM block, and inside the block, it should be safe to assume that the stream is open. When an an ARM block is used idiomatically, it naturally scopes the reference to a stream so that no one can access it after it's closed.

There are a number of ways that streams can be logically "closed", and many stream implementations will not detect this until a read() call is made. For example, if a server closes a socket, the internal state of the socket object in your client is unlikely to asynchronously reflect this; instead, the next call to read data will detect the closure and update the state. In this example, if the socket was closed cleanly, the read() call would return EOF to signal to the application that all data was safely received. If the connection was terminated abnormally, the call would throw an exception to indicate some data may have been lost.

It is reasonable to assume that a stream that has thrown an IOException is dead, and further attempts to read from it will continue to fail. If you could have detected this condition before making the call to read(), you'd presumably still handle it in the same way.

The exception to this approach is that some streams support a read timeout, where an exception is raised if no input is received for some time, but the stream remains valid. It would only make sense for a caller to pass such a stream to a method that explicitly supports retrying reads.

这篇关于找出InputStream是否关闭的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆