BufferedOutputStream.write(byte[], off, len) 不会绕过内部缓冲区，而是强制先写入缓冲区再批量刷新；唯一真正绕过的方式是不用该类而直接使用底层流，但会牺牲性能。

不能绕过内部缓冲区优化。 `BufferedOutputStream.write(byte[], off, len)` 的设计目的就是利用内部缓冲区提升性能，它**不会跳过缓冲区直接写入底层流**。所谓“绕过缓冲区”，在标准 JDK 实现中并不存在合法、安全且符合 API 合约的方式。 以下是关键事实和实用建议：

缓冲行为是默认且强制的

调用 write(byte[], off, len) 时，`BufferedOutputStream` 会尝试将数据先复制到其内部字节数组（缓冲区）中。只有当缓冲区满、调用 flush() 或 close() 时，才会批量写入底层 OutputStream。这是缓冲的核心逻辑，不是可选开关。

Java Maven Code Review

审查Java Maven项目（ZIP压缩包或GitLab仓库URL），检查代码规范、命名、模块边界、可维护性问题以及重复代码。

下载

想“绕过”？实际只有两种等效做法

• 不用 BufferedOutputStream：直接使用底层流（如 FileOutputStream），此时每次 write() 都触发系统调用，无缓冲 —— 但性能通常更差，尤其小块写入。
• 手动控制 flush + 小缓冲区：构造时传入极小的缓冲区（如 new BufferedOutputStream(out, 1)），但这只是让缓冲“几乎无效”，仍走缓冲流程，且可能因频繁 flush 反而更慢。

注意常见误解

有人认为设置缓冲区大小为 0 或负数能禁用缓冲 —— 这会导致 IllegalArgumentException；也有人试图反射修改内部 buffer 字段 —— 这属于破坏封装、不可移植、且 JDK 可能在未来版本中失效，不推荐。

真正需要“直写”时的合理选择

如果业务明确要求避免任何用户态缓冲（例如实时日志、低延迟通信），应：

• 评估是否真需牺牲吞吐换响应性；
• 优先考虑调整缓冲区大小（如 8KB~64KB）与 flush 策略（如按行、按事件、定时）取得平衡；
• 必要时用 FileChannel + ByteBuffer 或 NIO2 的异步写入，它们提供更精细的控制，但仍是基于操作系统缓冲机制。