Question

我的代码是分配内存并且永远不会释放它，即使它应该（至少在我看来）。

标题如下所示：

typedef boost::asio::ssl::stream<boost::asio::ip::tcp::socket> sslSocket_t;

class Object {
    boost::asio::io_service ioService_;
    boost::asio::ip::tcp::acceptor acceptor_;
    boost::asio::ssl::context context_;

    void functionOne();
    void functionTwo(shared_ptr<sslSocket_t>& sslSocket, const boost::system::error_code& error)
}

我的来源是这样的：

void Object::functionOne() {
    for (int i = 0; i < 10; i++) {
        shared_ptr<sslSocket_t> sslSocket(new sslSocket_t(ioService_, context_));
        acceptor_.async_accept(sslSocket->lowest_layer(),
                       boost::bind(&Object::functionTwo, this, sslSocket, boost::asio::placeholders::error));
    }
    acceptor_.cancel();

    boost::asio::io_service::work work(ioService_);
    ioService_.run();
}

void functionTwo(shared_ptr<sslSocket_t>& sslSocket, const boost::system::error_code& err) {
    // Do nothing
}

因此，当我调用 Object.functionOne（）时，内存将被分配给 Object.ioService _ 对象，以便能够调用绑定的异步方法。然后在循环之后，接受器上的所有挂起的异步操作都将被取消。一旦调用 Object.ioService_.run（）（我一直在测试它），就会调用适当的处理程序。但由于某种原因，分配的内存不会被释放。那么有人可以解释一下，为什么记忆没有被解除分配并给我一个提示如何释放它？

顺便说一句：我正在研究debian并且正在查看 / proc / self / status - ＆gt; VmRSS 以及所使用的内存。

@Vinnie Falco

#include <boost/asio.hpp>
#include <boost/asio/ssl.hpp>
#include <boost/bind.hpp>

#include <iostream>
#include <memory>

typedef boost::asio::ssl::stream<boost::asio::ip::tcp::socket> sslSocket_t;

using namespace std;

struct T  {

    boost::asio::io_service ioService_;
    boost::asio::ip::tcp::acceptor acceptor_;
    boost::asio::ssl::context context_;

    void functionOne() {
        for (int i = 0; i < 10; i++) {
            shared_ptr<sslSocket_t> sslSocket(new sslSocket_t(ioService_, context_));
            acceptor_.async_accept(sslSocket->lowest_layer(),
                               boost::bind(&T::functionTwo, this, sslSocket, boost::asio::placeholders::error));
        }
        acceptor_.cancel();

        boost::asio::io_service::work work(ioService_);
        ioService_.run();
    }

    void functionTwo(shared_ptr<sslSocket_t>& sslSocket, const boost::system::error_code& err) {
        // Do nothing
    }

    T() : acceptor_(ioService_,
                    boost::asio::ip::tcp::endpoint(boost::asio::ip::tcp::v4(), 443)),
          context_(boost::asio::ssl::context::sslv23_server)  {

    }

    ~T()  {

    }
};

int main()  {

    try  {
        T t;

        t.functionOne();
    } catch (std::exception& e) {
        cout << "Exception: " << e.what() << endl;
  }
}

我的问题不是，如果和为什么调用 T 的析构函数，这就像应该的那样工作。但是关于用过的记忆的行为很奇怪。因此，如果你在for循环中增加限制，你会发现程序保留了很多内存，即使它应该在调用所有异步处理程序后释放。但是 sslSocket 对象没有被解除分配，这就是我的问题：为什么内存（特别是为sslSocket分配的内存）绑定到仿函数 functionTwo ，即使在调用异步方法 fucntionTwo 并且没有留下对 sslSocket 的引用之后，还是没有解除分配？

我最后解释我的问题的方法（4月28日编辑）

好吧，我做了一个可运行的例子，这表明了我的担忧： My Problem in an example

输出：

Before leaking call:     6984 kB
Asynchronous calls of functionTwo: 10000
Memory while ioService is still running:   460244 kB
Memory after ioService is stopped:   460244 kB

更疯狂的是，在我自己的本地实现中，我得到以下输出：

Memory leaking call:     8352 kB
Asynchronous calls of functionTwo: 10000
Memory while ioService is still running:   471932 kB
Memory after ioService is stopped:     8436 kB

因此可以清楚地看到：即使在调用所有异步操作之后，内存也不会被释放。

摘要和理解（？）行为（上次修改）

由于你们中的一些人可能会误解，我不认为我的代码中存在某种泄漏。我在我的代码示例 Leak 中命名了这个结构，这可能让你很困惑，但我的问题不在于我的例子中是否发生内存泄漏。它是与 ioService 对象结合使用的内存分配。首先我想，声称的记忆无限增加。我做了最后一种方法来理解这种行为并得出结论，内存管理很好。操作系统不回收内存，但程序的内存分配正在收敛到一个限制，这对我来说没问题。所以这个问题不合时宜。

Example: Converging memory consumption

最令我不安的是我的本地实施表现出略微不同的行为。当 ioService 对象完成其作业并重置时，操作系统回收了内存，这满足了我的期望。

总结所有观察结果：

分配的内存由C ++ Runtime和OS管理。直接观察分配过程是非常困难的（如果不是甚至不可能？），因为它已经过优化以减少对新内存页面的请求量，这意味着分配的和释放的内存可能不会被无需重新分配通过操作系统。

为了向我指出这个行为的关键点，我想描述我的程序的用法：我正在开发一个服务器应用程序，这意味着程序应该运行无限的时间。如果程序在某个时候声称有很多峰值内存，那么它总体上很好，但它需要在运行时的某个时刻释放声明的内存，而不是在运行时之后。所以对我来说，只剩下一个问题了：

OS会在某个时间回收声明的（但未使用的）内存吗？或者我是否必须在运行时自行管理内存（使用 new 和 delete ）？

Answer 1

我不确定问题是什么，但我认为你做错了什么。你能提供一个展示问题的独立示例吗？此示例程序编译并运行，并且析构函数被调用：

#include <boost/asio.hpp>
#include <functional>
#include <iostream>
#include <memory>

struct T
{
    T()
    {
        std::cerr << "T::T()\n";
    }

    ~T()
    {
        std::cerr << "T::~T()\n";
    }
};

void f(std::shared_ptr<T>&)
{
}

int main()
{
    using namespace boost::asio;
    io_service ios;
    ios.post(std::bind(&f, std::make_shared<T>()));
    ios.run();
}

您可以在此处查看输出：http://melpon.org/wandbox/permlink/0fkIAnoMXDOeedx7

输出：

T::T()
T::~T()

Answer 2

采用自包含的示例并在valgrind下运行它会显示没有泄露

==14098== 
==14098== HEAP SUMMARY:
==14098==     in use at exit: 73,696 bytes in 7 blocks
==14098==   total heap usage: 163,524 allocs, 163,517 frees, 733,133,505 bytes allocated
==14098== 
==14098== LEAK SUMMARY:
==14098==    definitely lost: 0 bytes in 0 blocks
==14098==    indirectly lost: 0 bytes in 0 blocks
==14098==      possibly lost: 0 bytes in 0 blocks
==14098==    still reachable: 73,696 bytes in 7 blocks
==14098==         suppressed: 0 bytes in 0 blocks
==14098== Rerun with --leak-check=full to see details of leaked memory

如果你提供valgrind --show-leak-kinds=all --leak-check=full ./test，你会发现“泄露”（遗留的反应）是从libssl / libcrypto分配的常用静态内容。即使您只进行1次迭代，它们也会被分配。 10000次迭代没有变化。

==14214== Memcheck, a memory error detector
==14214== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==14214== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==14214== Command: ./test 10000
==14214== 
Before leaking call:    50056 kB
Asynchronous calls of functionTwo: 10000
Memory while ioService is still running:   265592 kB
Memory after ioService is stopped:   265592 kB
==14214== 
==14214== HEAP SUMMARY:
==14214==     in use at exit: 73,696 bytes in 7 blocks
==14214==   total heap usage: 163,524 allocs, 163,517 frees, 733,133,505 bytes allocated
==14214== 
==14214== 24 bytes in 1 blocks are still reachable in loss record 1 of 7
==14214==    at 0x4C2BBCF: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==14214==    by 0x5307E77: CRYPTO_malloc (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==14214==    by 0x53BF315: lh_insert (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==14214==    by 0x53C1863: ??? (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==14214==    by 0x53C245D: ERR_get_state (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==14214==    by 0x53C25EE: ERR_clear_error (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==14214==    by 0x40C9CA: context (context.ipp:70)
==14214==    by 0x40C9CA: Leak::Leak() (test.cpp:77)
==14214==    by 0x403E13: main (test.cpp:86)
==14214== 
==14214== 32 bytes in 1 blocks are still reachable in loss record 2 of 7
==14214==    at 0x4C2BBCF: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==14214==    by 0x5307E77: CRYPTO_malloc (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==14214==    by 0x53BE7AE: sk_new (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==14214==    by 0x507FD69: ??? (in /lib/x86_64-linux-gnu/libssl.so.1.0.0)
==14214==    by 0x5081E68: SSL_COMP_get_compression_methods (in /lib/x86_64-linux-gnu/libssl.so.1.0.0)
==14214==    by 0x5087532: SSL_library_init (in /lib/x86_64-linux-gnu/libssl.so.1.0.0)
==14214==    by 0x40B9A8: do_init (openssl_init.ipp:39)
==14214==    by 0x40B9A8: boost::asio::ssl::detail::openssl_init_base::instance() (openssl_init.ipp:131)
==14214==    by 0x403C3C: openssl_init (openssl_init.hpp:60)
==14214==    by 0x403C3C: __static_initialization_and_destruction_0 (openssl_init.hpp:90)
==14214==    by 0x403C3C: _GLOBAL__sub_I_count (test.cpp:96)
==14214==    by 0x40FE1C: __libc_csu_init (in /home/sehe/Projects/stackoverflow/test)
==14214==    by 0x5EC09CE: (below main) (libc-start.c:245)
==14214== 
==14214== 32 bytes in 1 blocks are still reachable in loss record 3 of 7
==14214==    at 0x4C2BBCF: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==14214==    by 0x5307E77: CRYPTO_malloc (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==14214==    by 0x53BE7CC: sk_new (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==14214==    by 0x507FD69: ??? (in /lib/x86_64-linux-gnu/libssl.so.1.0.0)
==14214==    by 0x5081E68: SSL_COMP_get_compression_methods (in /lib/x86_64-linux-gnu/libssl.so.1.0.0)
==14214==    by 0x5087532: SSL_library_init (in /lib/x86_64-linux-gnu/libssl.so.1.0.0)
==14214==    by 0x40B9A8: do_init (openssl_init.ipp:39)
==14214==    by 0x40B9A8: boost::asio::ssl::detail::openssl_init_base::instance() (openssl_init.ipp:131)
==14214==    by 0x403C3C: openssl_init (openssl_init.hpp:60)
==14214==    by 0x403C3C: __static_initialization_and_destruction_0 (openssl_init.hpp:90)
==14214==    by 0x403C3C: _GLOBAL__sub_I_count (test.cpp:96)
==14214==    by 0x40FE1C: __libc_csu_init (in /home/sehe/Projects/stackoverflow/test)
==14214==    by 0x5EC09CE: (below main) (libc-start.c:245)
==14214== 
==14214== 128 bytes in 1 blocks are still reachable in loss record 4 of 7
==14214==    at 0x4C2BBCF: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==14214==    by 0x5307E77: CRYPTO_malloc (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==14214==    by 0x53BEFE1: lh_new (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==14214==    by 0x53C1512: ??? (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==14214==    by 0x53C182F: ??? (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==14214==    by 0x53C245D: ERR_get_state (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==14214==    by 0x53C25EE: ERR_clear_error (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==14214==    by 0x40C9CA: context (context.ipp:70)
==14214==    by 0x40C9CA: Leak::Leak() (test.cpp:77)
==14214==    by 0x403E13: main (test.cpp:86)
==14214== 
==14214== 176 bytes in 1 blocks are still reachable in loss record 5 of 7
==14214==    at 0x4C2BBCF: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==14214==    by 0x5307E77: CRYPTO_malloc (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==14214==    by 0x53BEFBF: lh_new (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==14214==    by 0x53C1512: ??? (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==14214==    by 0x53C182F: ??? (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==14214==    by 0x53C245D: ERR_get_state (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==14214==    by 0x53C25EE: ERR_clear_error (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==14214==    by 0x40C9CA: context (context.ipp:70)
==14214==    by 0x40C9CA: Leak::Leak() (test.cpp:77)
==14214==    by 0x403E13: main (test.cpp:86)
==14214== 
==14214== 600 bytes in 1 blocks are still reachable in loss record 6 of 7
==14214==    at 0x4C2BBCF: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==14214==    by 0x5307E77: CRYPTO_malloc (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==14214==    by 0x53C23F5: ERR_get_state (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==14214==    by 0x53C25EE: ERR_clear_error (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==14214==    by 0x40C9CA: context (context.ipp:70)
==14214==    by 0x40C9CA: Leak::Leak() (test.cpp:77)
==14214==    by 0x403E13: main (test.cpp:86)
==14214== 
==14214== 72,704 bytes in 1 blocks are still reachable in loss record 7 of 7
==14214==    at 0x4C2BBCF: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==14214==    by 0x57731FF: ??? (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21)
==14214==    by 0x4010609: call_init.part.0 (dl-init.c:72)
==14214==    by 0x401071A: call_init (dl-init.c:30)
==14214==    by 0x401071A: _dl_init (dl-init.c:120)
==14214==    by 0x4000D09: ??? (in /lib/x86_64-linux-gnu/ld-2.21.so)
==14214==    by 0x1: ???
==14214==    by 0xFFEFFFF76: ???
==14214==    by 0xFFEFFFF7D: ???
==14214== 
==14214== LEAK SUMMARY:
==14214==    definitely lost: 0 bytes in 0 blocks
==14214==    indirectly lost: 0 bytes in 0 blocks
==14214==      possibly lost: 0 bytes in 0 blocks
==14214==    still reachable: 73,696 bytes in 7 blocks
==14214==         suppressed: 0 bytes in 0 blocks
==14214== 
==14214== For counts of detected and suppressed errors, rerun with: -v
==14214== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

衡量内存使用情况的方法并不合理。

Answer 3

我花了一段时间，但我终于成功地自己解决了这个问题。

因此，要清除事情，请确保我的问题的根源已被理解： 我正在开发一个服务器应用程序，它意味着无限期运行。此应用程序必须能够处理大量并发的连接。在某个时间点，可能存在负载峰值，导致我的应用程序声称存储器很多。然后过了一段时间，大部分的命令都被处理掉了，导致很多对象在运行时被释放。由于操作系统不需要内存（我的应用程序是服务器上唯一的大型内存使用者），所有释放的内存都保留在我的应用程序中，并且可以在其他时间点重用。这对我来说绝对没问题，但是一些客户和管理员可能会错误地将大量不断声明的内存误解为内存泄漏应用程序。为了避免这种情况，我想手动将一些未使用的内存交回操作系统。在我的示例中， ioService 的绑定处理程序（例如，接受新连接）将在运行时释放，但OS不会回收适当的内存。所以要手动完成，我找到了以下解决方案：

在C / C ++下在Linux下释放未使用的堆内存：int malloc_trim（size_t pad）

可以找到文档here。简化说明，此方法将未使用的内存从堆释放到操作系统，这正是我一直在寻找的。我知道在内存优化方面，手动使用这个功能可能很危险，但由于我只想每隔几分钟释放一次内存，这个性能问题对我来说是可以接受的。

感谢大家的努力和耐心！

Answer 4

我认为你的方法已被打破。你永远不应该与asio交错异步操作。如果你做各种未定义的废话将会发生。您通常实现异步接受的方式如下：

void do_accept() {
  shared_ptr<sslSocket_t> socket(new sslSocket_t(ioService_, context_));
  // Queue an async accept operation
  acceptor_.async_accept(socket->lowest_layer(), [this, socket](auto ec) {
    if (!ec) {
      // Handle the socket
    }
    // If not shutting down
    this->do_accept(); // next accept
  });
}

Boost :: asio和boost :: bind：Functor内存永远不会被释放

4 个答案: