不能靠AQS独占锁排队机制提升NIO写吞吐，反而严重拖慢性能；NIO依赖单线程+Selector高效轮询，加锁会导致写请求串行化、事件响应阻塞、Selector卡顿；应坚持非阻塞、堆外缓冲、批量写、精准OP_WRITE控制、无锁协作与上层背压策略。
不能靠AQS独占锁排队机制提升NIO写吞吐，反而会严重拖慢性能。
NIO的核心是单线程（或少量线程）驱动大量连接，依赖Selector高效轮询就绪事件。一旦在SocketChannel.write()路径中引入AQS独占锁——比如为每个连接或写操作加锁再执行write——就会破坏这一设计本质，带来三重反效果：
- 多个写请求被强制串行化，丧失“一个I/O线程管百个连接”的并发优势
- 线程阻塞在AQS队列中时，无法响应其他Channel的OP_WRITE就绪事件，导致整体写吞吐塌方
- Selector事件循环卡住，所有连接延迟飙升，尤其在高并发小包场景下尤为明显
真正提升写入吞吐的关键，是让I/O线程始终处于“可写即写、无阻塞流转”的高效状态。具体应聚焦以下方向：
确保非阻塞模式与堆外缓冲
- 调用
channel.configureBlocking(false)，杜绝write()意外阻塞 - 使用DirectByteBuffer或Netty的PooledByteBufAllocator分配堆外缓冲，避免GC压力和内存拷贝
聚合写入，减少系统调用频次
- 不逐包调用
channel.write()，而是先写入环形缓冲区（如CompositeByteBuf） - 按大小阈值（如8KB）或时间窗口（如1ms）触发批量flush，摊薄syscall开销
精准控制OP_WRITE注册时机
- 仅当
channel.isWritable() == false时才注册OP_WRITE - 一旦Selector通知该Channel就绪，立即flush缓冲区并取消OP_WRITE注册，避免空轮询消耗CPU
跨线程写安全不靠AQS，而用无锁协作
- 多个业务线程向同一连接写数据时：
- 用AtomicReference做缓冲槽位，CAS替换+自旋提交
- 或使用MpscArrayQueue暂存消息，由唯一I/O线程消费并零拷贝写出
- 若需强顺序，可用ThreadLocal缓存每个连接专属ByteBuffer，业务线程填充、I/O线程统一flush
背压处理交给上层策略，而非锁排队
- 当下游处理不过来时：
- 动态调整发送窗口（类似TCP滑动窗口），基于未确认字节数与写速率决策
- 对慢连接启用独立队列+指数退避重试，失败后走降级路径（如落盘、告警）
- 必要时用Semaphore控全局并发写请求数，但粒度应是连接池或业务类型，而非每次write
不复杂但容易忽略。
