数组变量是高性能IO的关键基础设施，因其内存连续、可直接寻址、免拷贝传递，支撑零分配、零拷贝的IO操作。
数组变量在高性能IO中不是“辅助工具”，而是关键基础设施。它让数据在内存中保持连续、可直接寻址、免拷贝传递，是绕过系统调用和缓冲区复制的底层支点。
为什么char[]和byte[]是高性能IO的起点
Java中CharArrayReader和ByteArrayInputStream之所以快，根本原因在于它们不创建新副本，而是直接把已有数组当作数据源。比如一个10MB的JSON字符串已存为char[]，用CharArrayReader包装后，下游XML解析器读取时，每次read()都是对原数组下标访问——零对象分配、零内存拷贝、无编码转换开销。
- 字节流场景：
byte[]配合ByteArrayInputStream或ByteBuffer.wrap()，适用于协议解析、网络包预处理 - 字符流场景：
char[]配合CharArrayReader或CharArrayWriter，适用于模板渲染、动态文本组装 - 避免String中间态：String内部虽也是char[]，但不可变；频繁拼接会触发多次数组复制，而直接操作char[]可复用缓冲区
如何在代码中安全复用数组缓冲区
复用不是简单地传同一个数组引用，而是要控制读写边界与生命周期。例如CharArrayWriter内部维护可扩容的char[]，write()只追加、reset()重置指针、toCharArray()返回当前有效段的副本——既保证线程局部安全，又避免重复分配。
- 写入端：用
CharArrayWriter累积内容，比StringBuilder.toString()少一次char[]→String→char[]的转换 - 读取端：用
CharArrayReader消费，比StringReader省去String构造及内部数组拷贝 - 跨线程注意：数组本身无锁，若需共享，应配合
final声明+明确的读写阶段分离，或使用ThreadLocal隔离缓冲区
实际工程中的典型模式
高并发网关或日志聚合服务常采用“数组缓冲池”策略：预分配一批固定大小的byte[]，用完归还，避免GC压力。例如Netty的PooledByteBufAllocator本质就是这一思想的延伸——只不过Java标准库没提供池化char[]，需自行封装。
- 响应体组装：多个微服务返回的JSON片段，统一写入同一
CharArrayWriter，最后toString()一次性输出 - 配置热加载：YAML/Properties文本加载进
char[]，通过CharArrayReader喂给解析器，变更时仅替换数组引用，不中断读取 - 单元测试模拟：用
new ByteArrayInputStream(mockData)替代文件IO，测试速度提升一个数量级
数组变量本身不带IO能力，但它让IO从“搬运工”变成“指路人”。真正快的不是读写动作，而是跳过冗余环节的能力。
