JDK 文档说,如果当前阻塞在 InterruptibleChannel 的 io 操作中的线程被中断,则 channel 将关闭并抛出 ClosedByInterruptException。但是,我在使用 FileChannel 时得到了不同的行为:
public class Main implements Runnable {
public static void main(String[] args) throws Exception {
Thread thread = new Thread(new Main());
thread.start();
Thread.sleep(500);
thread.interrupt();
thread.join();
}
public void run() {
try {
readFile();
} catch (IOException ex) {
ex.printStackTrace();
}
}
private void readFile() throws IOException {
FileInputStream in = new FileInputStream("large_file");
FileChannel channel = in.getChannel();
ByteBuffer buffer = ByteBuffer.allocate(0x10000);
for (;;) {
buffer.clear();
// Thread.currentThread().interrupt();
int r = channel.read(buffer);
if (Thread.currentThread().isInterrupted()) {
System.out.println("thread interrupted");
if (!channel.isOpen())
System.out.println("channel closed");
}
if (r < 0)
break;
}
}
这里,当线程被中断时,即使 channel 已关闭,read() 调用也会正常返回。不会抛出异常。此代码打印“线程中断”和“ channel 关闭”,然后在下一次调用 read() 时抛出 ClosedChannelException。
我想知道这种行为是否被允许。据我了解文档,read() 应该正常返回并且不关闭 channel 或关闭 channel 并抛出 ClosedByInterruptException。正常返回关闭 channel 好像不太对。我的应用程序的问题是,当执行 io 的 FutureTask 被取消时,我在其他地方遇到了意外且看似无关的 ClosedChannelException。
注意:当线程在进入 read() 时已经被中断时,将按预期抛出 ClosedByInterruptException。
我在使用 64 位服务器虚拟机(JDK 1.6.0 u21、Windows 7)时看到过这种行为。谁能证实这一点?
最佳答案
我记得在某处读过,但我不能在这里引用源代码,FileChannel
有点可中断。一旦读/写操作从 JVM 传递到 OS,JVM 就不能做太多,所以该操作将花费它所花费的时间。建议以可管理大小的 block 进行读/写,以便 JVM 可以在将作业处理到操作系统之前检查线程中断状态。
我认为您的示例完美地展示了这种行为。
编辑
我认为您描述的 FileChannel
行为违反了“最不意外”的原则,但从某个角度来看,它按预期工作,即使您订阅了那个角度,随心所欲。
因为 FileChannel
是“有点”可中断的,并且读/写操作确实是阻塞的,所以阻塞操作会成功并返回代表磁盘上文件状态的有效数据。如果是小文件,您甚至可以取回文件的全部内容。因为您有有效数据,所以“FileChannel”类的设计者认为您可能想要在开始解除中断之前使用它。
我认为这种行为应该真的,真的有据可查,为此您可以提交错误。但是,请不要屏住呼吸。
我认为判断线程是否在同一个循环迭代中被中断的唯一方法是做你正在做的事情并明确检查线程中断标志。
关于java - 未抛出 ClosedByInterruptException,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/3541411/