java nio 通过堆外内存减少stw影响：directbuffer数据存于native memory，不参与jvm分代回收，仅轻量堆内对象需gc；但需防范堆外内存泄漏与碎片化。
Java NIO 本身不直接“规避”Stop-The-World（STW），但它通过使用堆外内存（Direct Buffer），把部分关键数据的生命周期从 JVM 堆中移出，从而减少 GC 压力和 STW 的影响范围——尤其是避免这些数据参与新生代/老年代的常规回收流程。
堆外内存不归JVM垃圾回收器直接管理
调用 ByteBuffer.allocateDirect(size) 创建的 DirectBuffer，其底层内存由操作系统分配（通常通过 unsafe.allocateMemory），不在 Java 堆内。JVM 只在堆中保留一个轻量级的 DirectBuffer 对象（含地址、容量等元信息），真正的数据块在 native memory 中。
- 这个堆内对象很小，GC 扫描和回收它开销极低；
- 真正的数据块不会被可达性分析追踪，也不受分代回收策略影响；
- 只有当 DirectBuffer 对象被 GC 回收后，JVM 才会通过 Cleaner 或 PhantomReference 异步触发 unsafe.freeMemory() 释放堆外内存——这个释放过程不阻塞应用线程，也不属于 STW 阶段。
减少堆内存压力，间接降低 STW 频率与时长
大量使用 DirectBuffer（如 Netty 的 PooledByteBufAllocator）可显著减少高频、大体积缓冲区在堆中反复创建/销毁带来的压力：
Java JDK 25
下载
Java JDK 25 来自 OpenJDK 官方归档，版本为 JDK 25，本条下载地址已指向官方 Windows x64 zip 安装包直链，适合调试旧项目或兼容旧版 Java 运行环境。
- 网络 I/O 场景中，每次读写都用 HeapBuffer，容易快速填满 Eden 区，触发频繁 Minor GC；
- 换成 DirectBuffer 后，缓冲区数据不再占用堆空间，Eden 区存活对象更少，Minor GC 次数下降；
- 长期存活的大缓冲区若放在堆里，最终可能晋升到老年代，增加 Full GC 风险；堆外存放则完全绕过这一路径。
注意：堆外内存不是“零成本”，需主动管理
虽然堆外内存不参与 STW，但它带来新问题，必须谨慎处理：
- DirectBuffer 对象本身仍需 GC；若未及时释放（如忘记调用 buffer.clear() 或长期持有引用），会导致 native memory 泄漏，引发 OutOfMemoryError: Direct buffer memory；
- JVM 默认堆外内存上限为 64MB（由 -XX:MaxDirectMemorySize 控制），超限会强制触发 Full GC 尝试回收 Cleaner 引用的 DirectBuffer——这反而可能引入意外 STW；
- 堆外内存无法被 JVM 自动压缩或整理，碎片化后可能导致分配失败，尤其在长期运行服务中。
实际建议：结合池化与监控使用
单纯靠 allocateDirect 并不能自动优化 STW，真正有效的是配合内存池和可观测手段：
- 优先使用成熟的缓冲区池（如 Netty 的 PooledByteBufAllocator），复用 DirectBuffer，避免频繁分配/释放；
- 通过 JMX 或 JVM 参数（-XX:+PrintGCDetails -XX:+PrintGCTimeStamps）观察 GC 日志，确认堆内对象数量与 STW 时间是否同步下降；
- 监控 java.nio.BufferPool.direct 的已用/总大小（可通过 ManagementFactory.getPlatformMBeanServer() 获取），及时发现泄漏苗头。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
