Workflow框架中客户端断开连接时的资源清理问题解析

背景介绍

在基于Workflow框架开发服务端推送功能时，开发者经常会遇到一个典型问题：当客户端主动断开连接时，服务端尚未执行完成的任务（如定时任务、条件任务等）可能会持续占用系统资源，导致资源泄漏。本文将深入分析这一问题的成因，并提供几种可行的解决方案。

问题本质

Workflow框架中的任务执行机制基于series（任务序列）的概念。当一个客户端连接建立后，服务端通常会创建一个series来处理该连接的所有相关任务。问题出现在以下场景：

1. 服务端在process函数中创建了WFConditional任务等待特定信号
2. 客户端在条件任务等待期间主动断开连接
3. 由于条件任务尚未收到信号，series的callback不会被立即触发
4. 服务端资源（如消息订阅等）无法及时释放

技术细节分析

任务取消机制的特性

Workflow框架中的series cancel操作具有以下特点：

• 只能取消尚未开始执行的任务
• 对于已经dispatch但正在等待的条件任务(WFConditional)，cancel操作无法立即终止
• series的callback无论是否cancel都会被调用，但必须等待所有任务完成

连接生命周期管理

Workflow中连接的生命周期与任务执行是解耦的：

• 连接可以设置context和deleter回调
• 连接关闭时会触发deleter
• 但连接状态变化不会自动影响正在执行的任务

解决方案

方案一：连接关闭时主动触发信号

在连接关闭的deleter中，除了cancel series外，还需要手动触发条件任务的信号：

auto deleter = [](void* context) {
    log_info("connection closed");
    if (context) {
        SeriesWork* series = (SeriesWork*)context;
        series->cancel();
        // 手动触发条件任务的信号
        WFMyConditional::signal("topic_name"); 
    }
};

方案二：使用命名组件

对于定时器、计数器等组件，建议使用命名版本：

• 命名组件可以全局访问和控制
• 连接关闭时可以精确找到并取消相关组件
• 避免了匿名组件难以追踪的问题

方案三：双重检查机制

结合连接状态检查和任务取消：

1. 在process中设置连接context和deleter
2. 在server task的callback中清除连接context
3. 在条件任务的callback中检查连接状态

void process(WFHttpTask* server_task) {
    SeriesWork* series = series_of(server_task);
    server_task->get_connection()->set_context(series, [](void* ctx) {
        if (ctx) ((SeriesWork*)ctx)->cancel();
    });
    
    WFConditional* cond = WFConditional::create(...);
    cond->start([server_task](WFConditional* cond) {
        if (!server_task->get_connection()) {
            // 连接已断开，不再处理
            return;
        }
        // 正常处理逻辑
    });
}

最佳实践建议

1. 资源清理时机：对于关键资源，建议在连接关闭时立即清理，而不是等待任务自然结束

2. 状态一致性：确保在任何任务callback中都检查连接状态，避免向已关闭连接发送数据

3. 组件选择：对于长周期任务，优先考虑使用命名定时器、命名条件任务等可全局管理的组件

4. 心跳机制：即使使用上述方案，仍建议实现心跳机制作为兜底方案，确保极端情况下资源最终能被释放

总结

Workflow框架提供了灵活的任务编排能力，但也要求开发者对任务生命周期有清晰的认识。特别是在处理长连接和异步任务时，需要特别注意资源清理的时机。通过合理使用连接上下文、任务取消机制和命名组件，可以构建出既高效又可靠的服务器程序。