selectionkey 的 attachment 是绑定到键上的任意对象，用于高效传递上下文；通过 key.attach(obj) 设置，事件处理时用 key.attachment() 获取，需显式置 null 防泄漏。
在 Java NIO 的多路复用模型中，SelectionKey 的 attachment 机制是传递请求上下文（比如 ByteBuffer、Handler、Session 对象等）最直接、高效的方式——它避免了额外的 Map 查找或线程局部变量，且线程安全（因为每个 key 在事件分发时只被单个线程处理）。
Attachment 是什么？怎么设置？
SelectionKey 允许你通过 attach(Object) 方法绑定任意对象，该对象会一直与这个 key 关联，直到被显式替换或 key 取消。常见做法是在注册 Channel 时就附上初始上下文：
Java JDK 25
下载
Java JDK 25 来自 OpenJDK 官方归档，版本为 JDK 25，本条下载地址已指向官方 Windows x64 zip 安装包直链，适合调试旧项目或兼容旧版 Java 运行环境。
- 注册时直接传入 attachment：
SelectionKey key = channel.register(selector, ops, myContext); - 或注册后单独设置：
key.attach(myContext);
注意：attachment 可为 null，多次调用 attach() 会覆盖前值，不触发任何回调。
在事件处理中如何安全获取和使用 attachment
在 Selector.select() 返回后，遍历就绪的 keys，从每个 key 中取出 attachment 即可拿到上下文：
- 务必先检查是否为
null，尤其在连接刚建立（OP_ACCEPT）或异常关闭后可能未初始化 attachment； - 推荐使用泛型或强类型封装（如自定义
ConnectionContext），避免运行时类型转换错误； - 示例代码片段：
Object att = key.attachment();
if (att instanceof ConnectionContext ctx) {
// 处理读/写/连接逻辑，复用 ctx.buffer、ctx.handler 等
}
典型应用场景与注意事项
-
读写分离上下文：为每个连接维护独立的读缓冲区（
ByteBuffer.allocateDirect()）和写队列（ConcurrentLinkedQueue<bytebuffer></bytebuffer>），都放在 attachment 中； -
避免内存泄漏：当 Channel 关闭或 key 被取消（
key.cancel()）时，attachment 不会自动清理。若 attachment 持有大对象或引用了外部资源，建议在OP_READ/OP_WRITE处理末尾或key.isValid() == false时手动置空或释放； - 不要在多个线程间共享 attachment 对象：虽然 key 本身线程安全，但其 attachment 中的对象若被并发访问（如写队列被 IO 线程和业务线程同时操作），需自行加锁或使用线程安全集合。
替代方案对比（为什么优先用 attachment）
- 用
Map<selectionkey context></selectionkey>：需要同步、哈希查找开销、GC 压力更大，且 key 失效后容易忘记清理； - 用
ThreadLocal<context></context>：NIO 通常单 selector 单线程，但若使用多 selector 或 work-stealing 模式，上下文易错乱； - attachment 是零成本抽象：无额外数据结构、无同步、生命周期天然对齐 key，是 NIO 设计者预留的标准扩展点。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
