readablebytechannel和writablebytechannel是java nio对读写能力的正交抽象，分别约定从源读字节到bytebuffer和从bytebuffer写字节到目标，不耦合底层设备；拆分接口可避免运行时异常、支持泛型工具，并精准表达设备语义差异。
ReadableByteChannel 和 WritableByteChannel 是 Java NIO 对“数据读取”和“数据写入”能力的最小化、正交化抽象。它们不关心底层是网卡收包、磁盘读文件，还是管道传数据，只约定：只要能从某处把字节搬进 ByteBuffer，就实现 ReadableByteChannel；只要能把 ByteBuffer 里的字节送出去，就实现 WritableByteChannel。这种分离设计，让不同物理设备的 I/O 行为得以被统一建模，又保留各自语义边界。
为什么不是单个接口统一读写？
强制合并读写会掩盖设备本质差异。例如：
- 网卡的 SocketChannel 天然支持双向通信，适合同时实现两个接口；
- FileInputStream.getChannel() 返回的 FileChannel 声明上实现了 ByteChannel（即同时实现读写），但实际调用 write() 会抛 NonWritableChannelException —— 因为打开方式是只读的；
- Pipe.SourceChannel 只能读，Pipe.SinkChannel 只能写，二者严格单向，连 ByteChannel 都不实现。
接口拆分后，API 使用者能靠编译期类型判断行为边界，避免运行时异常，也便于构建泛型工具（如通用 copy 工具可只依赖 Readable + Writable，不强求同一实例）。
对磁盘设备的适配关键点
FileChannel 是最典型的 SeekableByteChannel 实现，它在 ReadableByteChannel / WritableByteChannel 基础上额外提供 position()、truncate()、size() 等方法。这些能力直指磁盘特性：
- 随机访问：通过 position(long) 跳转到任意偏移读写，这是网卡通道不具备的；
- 文件大小感知：size() 返回当前文件长度，用于边界校验或预分配；
- 零拷贝优化：transferTo/transferFrom 可绕过 JVM 堆内存，在内核态直接完成磁盘 ↔ 网络的数据搬运。
而普通 ReadableByteChannel 接口本身不承诺支持 seek，所以 FileInputStream.getChannel() 返回的通道虽能 read，却无法跳转位置 —— 这正是接口契约的体现：能力按需声明，不越界承诺。
对网卡设备的适配关键点
SocketChannel 和 DatagramChannel 属于 SelectableChannel 子类，核心特点是可注册到 Selector 并切换非阻塞模式。它们实现 ReadableByteChannel 和 WritableByteChannel，但行为受网络状态约束：
- 非阻塞模式下 read() 可能返回 0（无数据可读），而非阻塞等待；
- write() 在 TCP 缓冲区满时可能只写出部分字节，需检查返回值并重试；
- ScatteringByteChannel / GatheringByteChannel 支持“一次写多个 buffer”或“一次读到多个 buffer”，契合网络协议头+体分离、多段拼包等场景。
这些能力不是靠接口名体现，而是由具体实现保障 —— 接口只定义“能做什么”，实现决定“怎么做、何时成功、失败时抛什么异常”。
统一抽象带来的工程价值
这种分层抽象让上层代码可以解耦物理设备细节：
- 一个通用的 ByteBuffer 流式处理器，只需接收 ReadableByteChannel，就能处理文件、socket、pipe 甚至内存映射通道；
- 零拷贝传输工具 transferTo(src, position, count, writableChannel) 的参数类型是 ReadableByteChannel 和 WritableByteChannel，因此既可用于文件→socket，也可用于 socket→file，无需为每种组合写专用逻辑；
- 第三方库（如 Netty）可基于这些接口封装更高级的 Channel 抽象，而不破坏 JDK 原生兼容性。
本质上，NIO 的接口设计不是为了“掩盖差异”，而是为了“暴露恰好的差异”——把设备共性提为接口，把个性留在实现里，兼顾灵活性与类型安全。
