readablebytechannel 是 java nio 中定义读字节能力的接口，非具体类，核心方法为 read(bytebuffer) 和 close()；它不处理字符编码或行边界，返回值表示实际读取字节数，可能为 0（非阻塞无数据）、-1（eof）或正数，需每次检查并配合 buffer.flip()/clear() 使用。
ReadableByteChannel 是什么，不是什么
它不是一个具体类，而是 Java NIO 中定义读字节能力的接口。你不会 new 它，也不会直接实现它——JDK 已经用 FileChannel、SocketChannel、AsynchronousSocketChannel 等具体类型实现了它。它的核心契约只有两个方法：read(ByteBuffer) 和 close()。别把它和 InputStream 混着用，也别指望它自动处理字符编码或行边界。
read(ByteBuffer) 调用后为什么没读满、甚至返回 0？
这是最常被误解的一点：返回值是“本次实际读到的字节数”，不是“缓冲区容量”。它可能小于 buffer.remaining()，也可能为 0（尤其在非阻塞模式下），甚至为 -1（表示 EOF）。关键看通道是否就绪、底层是否有数据可读、缓冲区是否还有空间。
常见错误现象：
- 循环调用
read(buffer)却不检查返回值，导致逻辑卡住或重复读取旧数据 - 假设非阻塞
SocketChannel一定立即返回 >0，结果读到 0 后没做任何处理，后续连接就丢了 - 没清空/翻转
buffer就反复传给read()，缓冲区已满却还在等新数据写入
正确做法：
立即学习“Java免费学习笔记（深入）”；
- 每次
read()后必须检查返回值 - 返回 >0：调用
buffer.flip()后消费数据，再buffer.clear()或compact() - 返回 0：非阻塞通道的正常行为，说明暂时无数据，应让出 CPU 或继续轮询/注册 OP_READ
- 返回 -1：关闭通道，不要再调用
read()
FileChannel 和 SocketChannel 的 read 行为差异
FileChannel 是面向文件的，阻塞、可靠、支持任意位置读；SocketChannel 是面向网络的，受 TCP 流控、对端发送节奏、系统接收缓冲区影响大。两者都实现 ReadableByteChannel，但语义不同。
使用场景与注意事项：
-
FileChannel.read()在文件末尾会稳定返回 -1；而SocketChannel.read()在对端 close() 后才返回 -1，中途断连可能抛IOException -
FileChannel支持position(long)随机读，SocketChannel不支持 - 用
SocketChannel时，务必配合configureBlocking(false)+Selector，否则read()可能无限阻塞 -
FileChannel默认阻塞，但可以安全地在普通线程中调用；SocketChannel非阻塞模式下必须用事件驱动模型
为什么不能直接把 ReadableByteChannel 当作 InputStream 用？
虽然 Channels.newInputStream(ReadableByteChannel) 能包装出 InputStream，但代价明显：每次 read(byte[]) 都会新建临时 ByteBuffer，且无法控制缓冲区大小或复用。更严重的是，它把非阻塞通道强行套进阻塞 IO 模型里，容易掩盖就绪状态判断逻辑。
典型踩坑点：
- 在 NIO 服务端里用
newInputStream(socketChannel)包一层，再丢给传统ObjectInputStream，结果反序列化卡死，因为底层通道其实还没读完所有字节 - 以为包装后就能用
available()判断数据量，但ReadableByteChannel没有“可用字节数”概念，available()总是返回 0 - 忽略包装流的关闭责任——关了
InputStream不等于关了底层channel，资源泄漏风险高
真要桥接，优先考虑手动 copy：channel.read(buffer) → buffer.flip() → buffer.get(dstArray)，可控、零分配、无隐藏状态。
非阻塞通道的复杂性不在接口本身，而在你怎么响应它的“不确定返回值”和“无状态就绪信号”。漏掉一次 if (n == 0) 分支，或者忘了 buffer.flip()，后面整条链路的数据就会错位或停滞。
