真正用于网络传输的是byte[]，不是byte[]；因为byte是基本类型、连续紧凑且零拷贝友好，而byte[]是对象数组，含额外开销且不被nio通道接受。
Java中没有“Byte数组”和“byte数组”并列选择的问题——真正用于网络传输的是 byte[]，不是 Byte[]。Byte 是包装类（对象类型），byte 是基本类型；网络 I/O 操作底层只接受原始字节序列，必须用 byte[] 或更安全的 ByteBuffer，绝不能直接传 Byte[]。
为什么不能用 Byte[] 做网络传输
Byte[] 是对象数组，每个元素都是一个 Byte 实例，包含额外的对象头、引用开销和 GC 压力。它比 byte[] 大数倍内存，且无法被 SocketChannel、FileChannel 等 NIO 通道直接接受。尝试传入会编译失败或运行时报 ClassCastException。
- byte[]：连续、紧凑、零拷贝友好，JVM 可直接映射到操作系统 socket 缓冲区
- Byte[]：离散堆对象，含空指针风险，序列化后才可能转成字节，但已非“传输载体”而是“待处理数据”
byte[] 在网络传输中的典型问题与规避方式
直接用 byte[] 虽然合法，但极易引发粘包、数据覆盖、线程不安全等问题：
- 多个线程共用同一数组，未加锁读写 → 数据错乱
- 一次
write()未完成就重置数组内容 → 丢包或发送脏数据 - 接收端未按协议解析边界 → 把两个包当做一个包处理（粘包）
- 未处理符号扩展（如把
(byte)0xFF当-1误判为负值）→ 协议字段解析错误
更推荐的实践：用 ByteBuffer 替代裸 byte[]
ByteBuffer 不是替代方案，而是对 byte[] 的安全封装，自带状态管理（position/limit/capacity），天然适配 NIO 流程：
- 写入时调用
put()→flip()→channel.write(buffer) - 读取后必须
flip()才能get()，避免 position 错位 - 高频场景用
ThreadLocal<bytebuffer></bytebuffer>+ 容量分级池复用，避免频繁分配 - 对外暴露时用
asReadOnlyBuffer()防止业务层意外修改
什么时候可以放心用 byte[]
仅限以下简单、低并发、一次性场景：
- 同步阻塞 I/O（如
InputStream.read(byte[])）且每次处理独立小包 - 协议固定、长度已知（如 20 字节 TCP 包头），且单线程解析
- 临时构造测试数据，如
byte[] ping = {0x00, 0x01, 0x02, 0x03}
只要涉及异步、复用、多线程或性能敏感，就该跳过 byte[]，直奔 ByteBuffer。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
