boost :: asio acceptor避免内存泄漏

时间:2012-10-01 18:15:03

标签: c++ networking boost boost-asio

使用boost :: asio我使用async_accept接受连接。这很好,但有一个问题,我需要一个如何处理它的建议。使用典型的async_accept:

  Listener::Listener(int port)
        : acceptor(io, ip::tcp::endpoint(ip::tcp::v4(), port))
        , socket(io) {
          start_accept();
  }

  void Listener::start_accept() {
      Request *r = new Request(io);
      acceptor.async_accept(r->socket(), 
        boost::bind(&Listener::handle_accept, this, r, placeholders::error));
  }

工作正常但存在问题:请求对象是使用普通的创建的,因此它可以记忆“泄漏”。不是真的泄漏,它只在程序停止时泄漏,但我想让 valgrind 高兴。

当然有一个选项:我可以用 shared_ptr 替换它,并将其传递给每个事件处理程序。这将一直有效,直到程序停止,当asio io_service 停止时,所有对象都将被销毁,请求将被释放。但是这样我总是必须为请求设置一个活跃的asio事件,否则它将被销毁!我认为它是崩溃的直接方式所以我也不喜欢这种变体。

UPD第三种变体:Listener包含shared_ptr到活动连接的列表。看起来很棒,我更喜欢使用它,除非找到更好的方法。缺点是:由于此模式允许在空闲连接上执行“垃圾收集”,因此不安全:从侦听器中删除连接指针将立即销毁它,当某些连接的处理程序在其他线程中处于活动状态时,会导致段错误。在这种情况下,使用互斥锁无法修复此cus,我们必须锁定几乎任何东西。

有没有办法让 acceptor 使用连接管理一些美观和安全的方式?我很乐意听到任何建议。

3 个答案:

答案 0 :(得分:2)

使用此库时避免内存泄漏的典型方法是使用shared_ptrio_service documentation专门提及此

  

说明

     

上述破坏序列允许程序简化   使用shared_ptr<>进行资源管理。对象的位置   生命周期与连接的生命周期(或其他一些因素)有关   异步操作序列),对象的shared_pt r   绑定到所有相关的异步操作的处理程序   用它。其工作原理如下:

     

当单个连接结束时,所有关联的异步操作   完成。相应的处理程序对象将被销毁   对对象的shared_ptr引用被销毁。关闭了   整个程序,调用io_service函数stop()来终止   尽快拨打任何run()电话。 io_service析构函数已定义   上面会破坏所有处理程序,导致所有shared_ptr引用   要销毁的连接对象。

针对您的方案,更改Listener::handle_accept()方法以获取boost::shared_ptr<Request>参数。你的第二个问题

  

从Listener中删除连接指针会立即将其破坏,   当一些连接的处理程序处于活动状态时,什么可能导致段错误   在其他线程中。在这种情况下,我们必须使用互斥锁来解决这个问题   几乎锁定任何东西。

通过继承类中的boost::enable_shared_from_this模板来缓解

class Listener : public boost::enable_shared_from_this<Listener>
{
   ...
};

然后在分派处理程序时,在绑定到shared_from_this()的成员函数时使用this而不是Listener

答案 1 :(得分:0)

如果有人感兴趣,我找到了另一种方式。 Listener保存shared_ptr到活动连接的列表。终止/终止的连接是通过io_service::post进行的,Listener::FinishConnection调用asio::strand。通常我总是使用strand包装Request的方法 - 它在DDOS和/或线程安全方面更安全。因此,使用FinishConnectionpost调用strand可以防止其他线程中的段错误

答案 2 :(得分:0)

不确定这是否与您的问题直接相关,但我也使用 Boost Asio 库,特别是您提到的同一个acceptor对象,也有类似的内存泄漏。原来我没有正确关闭服务;某些连接将保持打开状态,并且不会从内存中释放相应的对象。调用以下内容可以消除 Valgrind 报告的泄漏:

acceptor.close();

希望这对某人有用!