BufferedOutputStream仅提供基础缓冲（默认8KB），不具备限流和智能攒批能力，需在外层封装大小/时间双触发flush、RateLimiter限速或替换为AsyncAppender等高级方案。
BufferedOutputStream 本身不提供限流和攒批写入的控制能力，它只是对底层 OutputStream 做了简单缓冲（默认 8KB），写入时仍由调用方决定何时 flush。要在 IO 密集型任务中实现限流和攒批，需在其外层封装逻辑，而非依赖 BufferedOutputStream 自身。
用固定缓冲区 + 时间/大小双触发 flush
单纯靠 Buffer 大小触发 flush 容易导致延迟过高；只靠定时又可能小数据频繁刷盘。推荐“大小或时间任一满足即刷”的策略：
- 维护一个 byte[] 缓冲区（如 64KB），手动 accumulate 数据
- 每次 write 前检查：当前已积攒字节数 ≥ 阈值（如 32KB）或距上次 flush 已超阈值时间（如 100ms）
- 满足任一条件就调用 flush，并重置计时器和计数器
- 注意：flush 前要确保线程安全，多线程写入需加锁或使用 ThreadLocal 缓冲区
结合 Semaphore 或 RateLimiter 实现写入速率限流
BufferedOutputStream 不感知吞吐，限流必须前置。可在写入前拦截并控速：
- 用 RateLimiter（Guava）按字节或请求限速：每秒最多写入 1MB →
limiter.acquire(bytesToWrite) - 或用 Semaphore 控制并发写操作数（适合多线程共用同一输出流场景）
- 关键点：限流粒度要与业务匹配——按字节限更准，但需预估长度；按次限更简单，适合定长消息
- 避免在 flush 内部做限流，否则会阻塞缓冲区释放，引发背压堆积
替换为支持异步/批量语义的替代方案
若业务强依赖攒批与限流，原生 BufferedOutputStream 显得笨重。可考虑：
立即学习“Java免费学习笔记（深入）”；
- Apache Commons IO 的 CountingOutputStream + 自定义 wrapper，方便统计与触发
- Netty 的 FileRegion 或 ChunkedWriteHandler，天然支持分块、限速、零拷贝写入
- 自研 BatchOutputStream：内部持 List
+ 定时调度器（ScheduledExecutorService），支持按条数、总大小、超时三条件 flush - 日志类场景直接用 Logback / Log4j2 的 AsyncAppender + RingBuffer，它们已内置批处理与背压机制
注意 flush 时机与异常处理的协同
攒批后 flush 是关键动作，但容易被忽略细节：
- 务必在 finally 块或 try-with-resources 中显式 flush + close，防止缓冲区残留
- flush 可能抛 IOException（如磁盘满、连接断），需捕获并决定是重试、降级还是告警
- 不要依赖 finalize 或 GC 触发 flush —— 缓冲数据会丢失
- 若底层是 SocketOutputStream，flush 不保证数据到达对方，仅保证进入 OS socket buffer；需应用层 ACK 机制保障送达
