Boost::asio 和 boost::bind:函子内存永远不会释放
Boost::asio and boost::bind: Functor memory is never released
我的代码正在分配内存并且永远不会释放它，即使它应该（至少在我看来）。
标题如下所示：
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 -> VmRSS 来计算使用的内存。
@Vinnie法尔科
#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 分配的内存）绑定到函子函数 Two，而不是解除分配，即使在异步方法功能二被调用并且没有留下对 sslSocket 的引用之后？
我解释我的担忧的最后方法（4月28日编辑）
好吧，我做了一个可运行的例子，表明了我的担忧：我在示例中的问题
输出：
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 对象相结合的内存分配。首先，我想，声称的记忆正在无限增加。我做了最后一种方法来理解这种行为，并得出结论，内存管理很好。操作系统不会回收内存，但程序的内存分配正在收敛到极限，这对我来说很好。所以这个问题已经解决了我的问题。
示例：聚合内存消耗
最让我不安的是，我的本地实施表现出略有不同的行为。在那里，当 ioService 对象完成其作业并重置时，内存作系统回收，这满足了我的期望。
因此，总结所有观察结果：
分配的内存由C++运行时和操作系统管理。直接观察分配过程是相当困难的（如果不是不可能的话？），因为它经过优化以减少对新内存页的请求量，这意味着分配和释放的内存可能不会立即作系统重新分配。
为了向我指出这种行为的关键点，我想描述一下我的程序的用法：我正在开发一个服务器应用程序，这意味着该程序应该运行无限的时间。如果程序在某个时间声明了大量峰值内存，则完全没问题，但它需要在运行时的某个时间点释放声明的内存，而不是在运行时之后。所以对我来说，只剩下一个问题：
操作系统是否会在某个时候回收声明的（但未使用的）内存？还是我必须在运行时自己管理内存（使用 new 和 delete）？
我不确定问题是什么，但我认为你做错了什么。您能否提供一个自包含的示例来展示问题？此示例程序编译并运行，析构函数称为：
#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()
我花了一段时间，但我终于设法自己解决了。
因此，为了澄清事情，让我们确保了解我问题的根源：我正在开发一个服务器应用程序，它旨在无限期地运行。此应用程序必须能够处理大量并发传入连接。在某个时间点，负载可能会达到峰值，从而导致我的应用程序大量声明内存。然后过了一段时间，大多数传入请求都得到了处理，导致在运行时释放了许多对象。由于操作系统不需要内存（我的应用程序是服务器上唯一的大内存使用者），因此所有释放的内存都保留在我的应用程序中，并且可以在另一个时间点重用。这对我来说绝对没问题，但一些客户和管理员可能会将大量不断声明的内存误解为内存泄漏应用程序。为了避免这种情况，我想手动将一些未使用的内存交还给操作系统。在我的示例中，绑定到 ioService 的处理程序（例如接受新连接）将在运行时释放，但操作系统不会回收适当的内存。因此，要手动执行此操作，我找到了以下解决方案：
在 C/C++ 中释放 Linux 下未使用的堆内存：int malloc_trim（size_t pad）
文档可在此处找到。简化解释，此方法将未使用的内存从堆释放到操作系统，这正是我一直在寻找的。我知道在内存优化方面，手动使用此功能可能很危险，但由于我只想每隔几分钟释放一次内存，因此我可以接受这种性能问题。
感谢大家的努力和耐心！
以您的自包含示例并在 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)
您测量内存使用情况的方法并不合理。
我认为你的方法被打破了。切勿将异步操作与 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
});
}
相关文章：
- 将字符串存储在c++中的稳定内存中
- C++ 指针的内存地址和指向数组的内存地址如何相同？
- Win32编译器选项和内存分配
- 当vector是tje全局变量时，c++中vector的内存管理
- 带内存和隔离功能的SQLite
- 是否可以通过C++扩展强制多个python进程共享同一内存
- 迭代时从向量和内存中删除对象
- 在C++中打印指向不同基元数据类型的指针的内存地址
- 这个指针和内存代码打印是什么？我不知道是打印垃圾还是如何打印我需要的值
- 多个文件的内存分配错误"在抛出 'std :: bad_alloc' what ()： std ：： bad_alloc 的实例后终止调用" [C++]
- 为什么示例代码访问IUnknown中已删除的内存
- 如何在C++类内存结构中创建"spacer"？
- 从构造函数抛出异常时如何克服内存泄漏
- malloc(） 可能出现内存泄漏
- C++代码永远运行并消耗内存
- Boost::asio 和 boost::bind:函子内存永远不会释放
- Solaris 进程内存使用量会增加，但不会永远增加
- 永远不要将涉及动态内存分配的函数注释为noexcept
- 为什么这些内存值在GDB中永远不会改变
- std::list是否保证项永远不会被移动到不同的内存位置?
