BRPC 中 StreamInputHandler 生命周期管理的最佳实践

概述

在使用 BRPC 的流式 RPC(Stream RPC)功能时，开发者可能会遇到 StreamInputHandler 析构时机不当导致的程序崩溃问题。本文将深入分析这一问题的根源，并给出合理的解决方案。

问题现象

当使用 BRPC 的流式 RPC 时，程序可能在 Stream::Consume 方法中崩溃，具体位置是在调用 s->_options.handler->on_closed(s->id()) 时。这表明虽然 handler 指针不为空，但指向的对象可能已经被析构。

原因分析

1. 指针拷贝问题：StreamOptions 结构体中的 handler 是通过普通指针存储的，在 StreamCreate 函数中会直接拷贝整个 options 对象，包括这个指针值。

2. 生命周期管理缺失：BRPC 框架没有提供显式的机制来管理 handler 的生命周期，开发者需要自行确保 handler 在整个流式会话期间有效。

3. 异步消费机制：消息是通过 Stream::Consume 方法异步消费的，handler 可能在消息处理完成前就被析构。

解决方案

推荐方案：单例模式

将 StreamInputHandler 实现为单例是最稳妥的解决方案：

1. 确保 handler 在整个程序生命周期内都存在
2. 避免复杂的生命周期管理
3. 适用于大多数使用场景

class MyStreamHandler : public StreamInputHandler {
public:
    static MyStreamHandler* GetInstance() {
        static MyStreamHandler instance;
        return &instance;
    }
    
    // 实现各种虚函数...
};

替代方案：延长生命周期

如果必须使用非单例 handler：

1. 使用 shared_ptr 等智能指针管理 handler
2. 确保 handler 的生命周期长于所有使用它的流
3. 在明确所有流都关闭后才能析构 handler

实现建议

1. 全局管理：在应用程序层面维护一个全局的 handler 管理器
2. 引用计数：为 handler 实现引用计数机制，确保没有流使用时才析构
3. 明确所有权：在设计时明确 handler 的所有权归属，避免多对象共享

总结

BRPC 的流式 RPC 功能强大，但在 handler 生命周期管理上需要开发者特别注意。采用单例模式是最简单可靠的解决方案，能够有效避免因 handler 提前析构导致的程序崩溃问题。对于高级使用场景，开发者需要自行实现更精细的生命周期管理机制。