当我使用Channels.newChannel（is）从InputStream创建一个通道时，Java标准库返回一个ReadableByteChannelImpl，它是：
private static class ReadableByteChannelImpl
extends AbstractInterruptibleChannel // Not really interruptible
implements ReadableByteChannel
{
InputStream in;
private static final int TRANSFER_SIZE = 8192;
private byte buf[] = new byte[0];
private boolean open = true;
private Object readLock = new Object();
ReadableByteChannelImpl(InputStream in) {
this.in = in;
}
public int read(ByteBuffer dst) throws IOException {
int len = dst.remaining();
int totalRead = 0;
int bytesRead = 0;
synchronized (readLock) {
while (totalRead < len) {
int bytesToRead = Math.min((len - totalRead),
TRANSFER_SIZE);
if (buf.length < bytesToRead)
buf = new byte[bytesToRead];
if ((totalRead > 0) && !(in.available() > 0))
break; // block at most once
try {
begin();
bytesRead = in.read(buf, 0, bytesToRead);
} finally {
end(bytesRead > 0);
}
if (bytesRead < 0)
break;
else
totalRead += bytesRead;
dst.put(buf, 0, bytesRead);
}
if ((bytesRead < 0) && (totalRead == 0))
return -1;
return totalRead;
}
}
protected void implCloseChannel() throws IOException {
in.close();
open = false;
}
}
如您所见，它在第一次调用read（ByteBuffer dst）时会阻塞，再也不会阻塞。看到：
if ((totalRead > 0) && !(in.available() > 0))
break; // block at most once
这种奇怪行为的背后原因是什么？
另外，在没有实际使此通道真正可中断的情况下扩展AbstractInterruptibleChannel的动机是什么？
最佳答案
如果已经读取了至少一个字节并且基础流宣布没有字节是available，它将不会阻塞。请注意，即使某些字节可用，InputStream#available()仍可以返回零，但是它不能保证在不阻塞的情况下读取更多的字节。因此，此ReadableByteChannel会努力读取至少一个字节-假设提供的ByteBuffer具有至少一个字节的空间-并且这样做之后，将不会尝试再次读取基础流，除非该流承诺会有更多字节可用而不会阻塞。
至于为什么ReadableByteChannelImpl扩展AbstractInterruptibleChannel的原因，我怀疑这是为了确保包装后的InputStream在调用Channel#close()后会正确关闭，而InterruptibleChannel#close()会进一步完善其合同。扩展AbstractInterruptibleChannel允许ReadableByteChannelImpl借用其线程安全的打开-关闭状态防护。
如您所说，这是一种错误的广告，并不是真正的可中断性，但是它可以被一个单独的线程封闭，因此这样做是幂等的。