ByteArrayOutputStream 的 reset() 仅重置计数器 count=0，不清理底层数组，后续 write() 覆写起始位置，toByteArray() 返回全长数组（含历史残留），扩容更致内存浪费；真正复用需预分配 byte[] 并传入构造器，或改用 ByteBuffer、bytebufferpool、PooledByteBufAllocator 等专用缓冲池方案。
ByteArrayOutputStream 的 reset() 不是缓冲区重用，只是计数器归零
很多人看到 reset() 就以为能“清空并复用底层数组”，实际它只把内部 count = 0，buf 数组本身完全没动。下次 write() 仍从索引 0 开始覆写，但 toByteArray() 返回的仍是原数组（长度 = 原 buf.length），前 count 字节有效，后面全是历史残留垃圾。若后续写入超过原容量，还会触发扩容——内存里同时驻留新旧两块大数组，GC 压力反而更大。
真正可控的缓冲区复用：手动管理 byte[] + ByteArrayOutputStream 构造器
如果你确定协议体大小有上限（比如最大 64KB），就该显式指定初始容量，并在每次拼装前手动重置内容，而不是依赖 reset()：
-
byte[] buffer = new byte[65536];// 预分配固定大小数组 -
ByteArrayOutputStream baos = new ByteArrayOutputStream(buffer);// 传入已有数组，避免内部 new - 拼装完调用
baos.size()获取真实长度，再用Arrays.copyOf(buffer, baos.size())提取干净字节数组 - 下一轮直接重用
buffer，Arrays.fill(buffer, (byte)0)或仅靠后续write()覆盖即可
比 ByteArrayOutputStream 更适合高频二进制拼装的替代方案
当协议拼装频率高、单次数据量稳定（如 1–128KB）、且需长期复用时，ByteArrayOutputStream 的设计范式已成瓶颈。此时应切换工具：
- Java 9+ 可用
ByteBuffer.allocateDirect()+ 自定义池，但需手动管理clear()/flip()和释放 - Go 场景直接上
bytebufferpool.Get()，Put()归还，实测分配延迟降为 0.3ns，GC 停顿减 67% - Netty 用户优先走
PooledByteBufAllocator，配合ioBuffer()获取可复用堆外缓冲区，天然支持零拷贝和自动回收
关键点在于：ByteArrayOutputStream 的“缓冲区”本质是单次写入+导出的临时载体，不是循环缓冲池。强行用它扛高频拼装，等于拿螺丝刀当锤子——能敲，但手疼，还容易崩刃。
