t-io 稳定性设计与资源管理

t-io 将 IO 事件处理、业务回调和连接资源管理组织在清晰的生命周期中。对于长连接服务、即时通信和持续运行的 HTTP 应用，这意味着开发者可以更专注于业务逻辑，由框架统一处理连接接入、异步读写和资源回收。

共享 IO 线程，独立处理每次操作

多个连接可以共享 IO Worker。Worker 为注册任务和就绪事件分别设置异常处理边界，单次操作或应用回调异常经过记录后，继续处理后续任务，提升共享线程的服务连续性。

这种设计适合存在大量长连接的应用：连接之间共享线程资源，每次操作又具有明确的处理范围。应用无需为每条连接安排一个长期等待网络数据的线程。

回调与操作一一对应

每次接收、读取和写入操作都关联自己的 handler 与 attachment。框架在调用完成回调前重置本次 pending 状态，使业务能够在回调中继续提交下一次操作。

能力开发收益
操作与附件对应方便追踪一次 IO 的数据、状态和完成结果
回调前重置 pending 状态可以自然地编写连续接收和连续读写流程
回调异常单独记录已提交的新操作保持独立的生命周期
关闭时完成等待中的读写上层能够收到结果并结束等待

自动管理连接资源

从接收连接到提交首次读取，AcceptCompletionHandler 负责连接初始化和初始缓冲区管理。成功提交读取后，缓冲区交给读取回调继续管理。

ReadCompletionHandler 使用 VirtualBuffer 传递读取缓冲区。正常连续读取时复用缓冲区；读取容量变化时申请新缓冲区并释放旧资源；连接结束时执行统一清理。

发送端通过 EncodedBuffer 将编码输出与回收入口一同交给发送任务。HTTP 响应和 WebSocket 帧从 VirtualBuffer 响应池分配，自定义 TCP 编码器也可以接入同一机制。异步写入完成后再回收对应缓冲区，文件响应完成后关闭文件句柄。普通响应、文件响应和 TLS 数据共享发送收尾流程，简化应用侧的资源管理。

应用自行创建的业务对象、外部连接和文件资源，由应用在自己的生命周期中管理。

分层日志，便于运维定位

日志按照注册、事件处理、回调和 Worker 循环区分位置，方便从一次操作追踪到对应处理阶段。

日志位置运维关注点
register、event、write对应注册任务或 IO 操作
accept-callback、read-callback、write-callback应用回调逻辑
accept-failed、read-failed、write-failed失败回调的处理逻辑
loop、select-closedWorker 与 Selector 生命周期，结合服务监控恢复处理

单次操作与 Worker 循环分别记录，便于配置告警级别、定位处理阶段和制定恢复策略。操作重试由业务语义决定，可在应用层结合幂等性进行安排。

适用场景

  • 即时通信与设备接入：共享 IO 线程、持续读取与连接状态管理支持长期在线通信。
  • HTTP 长连接服务：响应完成、连接复用和关闭具有统一的处理流程。
  • 文件服务：文件句柄与发送缓冲区随传输生命周期管理。
  • 自定义协议：通过 handler 和 attachment 组织连续读写及业务上下文。

继续阅读：t-io 核心优势与应用价值、HTTP 长连接与高效文件传输。

关于 HTTP、WebSocket 和 TCP 的具体分配路径，参见缓冲区复用。