提升::ASIO 受体避免内存泄漏

boost::asio acceptor avoid memory leak

本文关键字：内存 泄漏 ASIO 提升      更新时间：2023-10-16

使用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));
}

工作正常，但存在一个问题：请求对象是使用纯新创建的，因此它可以内存"泄漏"。不是真正的泄漏，它仅在程序停止时泄漏，但我想让瓦尔格林德开心。

当然有一个选项：我可以用shared_ptr替换它，并将其传递给每个事件处理程序。这将工作到程序停止，当 asioio_service停止时，所有对象将被销毁，请求将被释放。但是这样我必须始终有一个活动的 asio 事件用于请求，否则它将被销毁！我认为它是崩溃的直接方式，所以我也不喜欢这种变体。

UPD 第三种变体：Listener保留活动连接的shared_ptr列表。看起来很棒，除非找到更好的方法，否则我更喜欢使用它。缺点是：由于此模式允许在空闲连接上执行"垃圾收集"，因此不安全：从侦听器中删除连接指针将立即破坏它，当某些连接的处理程序在其他线程中处于活动状态时，这可能导致段错误。在这种情况下，使用互斥锁无法解决此问题，我们必须锁定几乎所有内容。

有没有办法让接受者使用连接管理某种美丽而安全的方式？我将很高兴听到任何建议。

使用此库时避免内存泄漏的典型方法是使用shared_ptr，io_service文档特别提到了这一点

言论

上述销毁顺序允许程序简化 他们的资源管理通过使用shared_ptr<>.其中对象的 生存期与连接的生存期(或其他连接)相关联 异步操作序列)，对象的shared_ptr 将 绑定到所有关联异步操作的处理程序中 有了它。其工作原理如下：

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

对于你的方案，请将Listener::handle_accept() 方法更改为采用boost::shared_ptr<Request>参数。您的第二个问题

从侦听器中删除连接指针将立即销毁它， 当某些连接的处理程序处于活动状态时，什么会导致段错误 在其他线程中。在这种情况下，使用互斥锁无法解决此问题，我们必须 几乎锁定任何东西。

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

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

然后，在调度处理程序时，在绑定到Listener的成员函数时使用shared_from_this()而不是this。

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

不确定这是否与您的问题直接相关，但我在使用Boost Asio库时也遇到了类似的内存泄漏，尤其是您提到的同一acceptor对象。事实证明我没有正确关闭服务;某些连接将保持打开状态，并且其相应的对象不会从内存中释放。打电话给以下摆脱了瓦尔格林德报告的泄漏：

acceptor.close();

希望这对某人有用！

相关文章：