C++ 如何避免内存泄露 梦里梦外; 2022-03-27 08:37 250阅读 0赞 ## 转载于:[https://zhuanlan.zhihu.com/p/51898119][https_zhuanlan.zhihu.com_p_51898119] ## ## 前言 ## 近年来,讨论 C++ 的人越来越少了,一方面是由于像 Python,Go 等优秀的语言的流行,另一方面,大家也越来越明白一个道理,并不是所有的场景都必须使用 C++ 进行开发。Python 可以应付大部分对性能要求不高的场景,Go 可以应付大部分对并发要求较高的场景,而由于 C++ 的复杂性,只有在对性能极其苛刻的场景下,才会考虑使用。 那么到底多苛刻算是苛刻呢?Go 自带内存管理,也就是 GC 功能,经过多年的优化,在 Go 中每次 GC 可能会引入 500us 的 STW 延迟。 ![v2-c861a6b88df3c9c823d3b19cf121ee83_hd.png][] 也就是说,如果你的应用场景可以容忍不定期的 500us 的延迟,那么用 Go 都是没有问题的。如果你无法容忍 500us 的延迟,那么带 GC 功能的语言就基本无法使用了,只能选择自己管理内存的语言,例如 C++。那么由手动管理内存而带来的编程复杂度也就随之而来了。 作为 C++ 程序员,内存泄露始终是悬在头上的一颗炸弹。在过去几年的 C++ 开发过程中,由于我们采用了一些技术,我们的程序发生内存泄露的情况屈指可数。今天就在这里向大家做一个简单的介绍。 ## 内存是如何泄露的 ## 在 C++ 程序中,主要涉及到的内存就是『栈』和『堆』(其他部分不在本文中介绍了)。 ![v2-f3189547daa4548bc4ab6fdd13eeea6d_hd.png][] 通常来说,一个线程的栈内存是有限的,通常来说是 8M 左右(取决于运行的环境)。栈上的内存通常是由编译器来自动管理的。当在栈上分配一个新的变量时,或进入一个函数时,栈的指针会下移,相当于在栈上分配了一块内存。我们把一个变量分配在栈上,也就是利用了栈上的内存空间。当这个变量的生命周期结束时,栈的指针会上移,相同于回收了内存。 由于栈上的内存的分配和回收都是由编译器控制的,所以在栈上是不会发生内存泄露的,只会发生栈溢出(Stack Overflow),也就是分配的空间超过了规定的栈大小。 而堆上的内存是由程序直接控制的,程序可以通过 malloc/free 或 new/delete 来分配和回收内存,如果程序中通过 malloc/new 分配了一块内存,但忘记使用 free/delete 来回收内存,就发生了内存泄露。 ## 经验 \#1:尽量避免在堆上分配内存 ## 既然只有堆上会发生内存泄露,那第一原则肯定是避免在堆上面进行内存分配,尽可能的使用栈上的内存,由编译器进行分配和回收,这样当然就不会有内存泄露了。 然而,只在栈上分配内存,在有 IO 的情况下是存在一定局限性的。 举个例子,为了完成一个请求,我们通常会为这个请求构造一个 Context 对象,用于描述和这个请求有关的一些上下文。例如下面一段代码: void Foo(Reuqest* req) { RequestContext ctx(req); HandleRequest(&ctx); } 如果 HandleRequest 是一个同步函数,当这个函数返回时,请求就可以被处理完成,那么显然 ctx 是可以被分配在栈上的。 但如果 HandleRequest 是一个异步函数,例如: void HandleRequest(RequestContext* ctx, Callback cb); 那么显然,ctx 是不能被分配在栈上的,因为如果 ctx 被分配在栈上,那么当 Foo 函数推出后,ctx 对象的生命周期也就结束了。而 FooCB 中显然会使用到 ctx 对象。 void HandleRequest(RequestContext* ctx, Callback cb); void Foo(Reuqest* req) { auto ctx = new RequestContext(req); HandleRequest(ctx, FooCB); } void FooCB(RequestContext* ctx) { FinishRequest(ctx); delete ctx; } 在这种情况下,如果忘记在 FooCB 中调用 delete ctx,则就会触发内存泄露。尽管我们可以借助一些静态检查工具对代码进行检查,但往往异步程序的逻辑是极其复杂的,一个请求的生命周期中,也需要进行大量的内存分配操作,静态检查工具往往无法发现所有的内存泄露情况。 那么怎么才能避免这种情况的产生呢?引入智能指针显然是一种可行的方法,但引入 shared\_ptr 往往引入了额外的性能开销,并不十分理想。 在 SmartX,我们通常采用两种方法来应对这种情况。 ## 经验 \#2:使用 Arena ## Arena 是一种统一化管理内存生命周期的方法。所有需要在堆上分配的内存,不通过 malloc/new,而是通过 Arena 的 CreateObject 接口。同时,不需要手动的执行 free/delete,而是在 Arena 被销毁的时候,统一释放所有通过 Arena 对象申请的内存。所以,只需要确保 Arena 对象一定被销毁就可以了,而不用再关心其他对象是否有漏掉的 free/delete。这样显然降低了内存管理的复杂度。 此外,我们还可以将 Arena 的生命周期与 Request 的生命周期绑定,一个 Request 生命周期内的所有内存分配都通过 Arena 完成。这样的好处是,我们可以在构造 Arena 的时候,大概预估出处理完成这个 Request 会消耗多少内存,并提前将会使用到的内存一次性的申请完成,从而减少了在处理一个请求的过程中,分配和回收内存的次数,从而优化了性能。 我们最早看到 Arena 的思想,是在 LevelDB 的代码中。[这段代码][Link 1]相当简单,建议大家直接阅读。 ## 经验 \#3:使用 Coroutine ## Coroutine 相信大家并不陌生,那 Coroutine 的本质是什么?我认为 Coroutine 的本质,是使得一个线程中可以存在多个上下文,并可以由用户控制在多个上下文之间进行切换。而在上下文中,一个重要的组成部分,就是栈指针。使用 Coroutine,意味着我们在一个线程中,可以创造(或模拟)多个栈。 有了多个栈,意味着当我们要做一个异步处理时,不需要释放当前栈上的内存,而只需要切换到另一个栈上,就可以继续做其他的事情了,当异步处理完成时,可以再切换回到这个栈上,将这个请求处理完成。 还是以刚才的代码为示例: void Foo(Reuqest* req) { RequestContext ctx(req); HandleRequest(&ctx); } void HandleRequest(RequestCtx* ctx) { SubmitAsync(ctx); Coroutine::Self()->Yield(); CompleteRequest(ctx); } 这里的精髓在于,尽管 Coroutine::Self()->Yield() 被调用时,程序可以跳出 HandleRequest 函数去执行其他代码逻辑,但当前的栈却被保存了下来,所以 ctx 对象是安全的,并没有被释放。 这样一来,我们就可以完全抛弃在堆上申请内存,只是用栈上的内存,就可以完成请求的处理,完全不用考虑内存泄露的问题。然而这种假设过于理想,由于在栈上申请内存存在一定的限制,例如栈大小的限制,以及需要在编译是知道分配内存的大小,所以在实际场景中,我们通常会结合使用 Arena 和 Coroutine 两种技术一起使用。 有人可能会提到,想要多个栈用多个线程不就可以了?然而用多线程实现多个栈的问题在于,线程的创建和销毁的开销极大,且线程间切块,也就是在栈之间进行切换的代销需要经过操作系统,这个开销也是极大的。所以想用线程模拟多个栈的想法在实际场景中是走不通的。 关于 Coroutine 有很多开源的实现方式,大家可以在 github 上找到很多,C++20 标准也会包含 Coroutine 的支持。在 SmartX 内部,我们很早就实现了 Coroutine,并对所有异步 IO 操作进行了封装,示例可参考我们之前的一篇文章 [smartx:基于 Coroutine 的异步 RPC 框架示例(C++)][smartx_ Coroutine _ RPC _C] 这里需要强调一下,Coroutine 确实会带来一定的性能开销,通常 Coroutine 切换的开销在 20ns 以内,然而我们依然在对性能要求很苛刻的场景使用 Coroutine,一方面是因为 20ns 的性能开销是相对很小的,另一方面是因为 Coroutine 极大的降低了异步编程的复杂度,降低了内存泄露的可能性,使得编写异步程序像编写同步程序一样简单,降低了程序员心智的开销。 ![v2-00887db33a534dd51a5444c4134f56f6_hd.png][] boost 实现的 coroutine 的性能测试结果 ## 经验 \#4:善用 RAII ## 尽管在有些场景使用了 Coroutine,但还是可能会有在堆上申请内存的需要,而此时有可能 Arena 也并不适用。在这种情况下,善用 [RAII(Resource Acquisition Is Initialization)][RAII_Resource Acquisition Is Initialization]思想会帮助我们解决很多问题。 简单来说,**RAII 可以帮助我们将管理堆上的内存,简化为管理栈上的内存,从而达到利用编译器自动解决内存回收问题的效果**。此外,RAII 可以简化的还不仅仅是内存管理,还可以简化对资源的管理,例如 fd,锁,引用计数等等。 当我们需要在堆上分配内存时,我们可以同时在栈上面分配一个对象,让栈上面的对象对堆上面的对象进行封装,用时通过在栈对象的析构函数中释放堆内存的方式,将栈对象的生命周期和堆内存进行绑定。 unique\_ptr 就是一种很典型的例子。然而 unique\_ptr 管理的对象类型只能是指针,对于其他的资源,例如 fd,我们可以通过将 fd 封装成另外一个 FileHandle 对象的方式管理,也可以采用一些更通用的方式。例如,在我们内部的 C++ 基础库中实现了 Defer 类,想法类似于 Go 中 defer。 void Foo() { int fd = open(); Defer d = [=]() { close(fd); } // do something with fd } ## 经验 \#5:便于 Debug ## 在特定的情况下,我们难免还是要手动管理堆上的内存。然而当我们面临一个正在发生内存泄露线上程序时,我们应该怎么处理呢? 当然不是简单的『重启大法好』,毕竟重启后还是可能会产生泄露,而且最宝贵的现场也被破坏了。最佳的方式,还是利用现场进行 Debug,这就要求程序具有便于 Debug 的能力。 这里不得不提到一个经典而强大的工具 [gperftools][]。gperftools 是 google 开源的一个工具集,包含了 tcmalloc,heap profiler,heap checker,cpu profiler 等等。gperftools 的作者之一,就是大名鼎鼎的 [Sanjay Ghemawat][],没错,就是与 [Jeff Dean][] 齐名,并和他一起写 [MapReduce][] 的那个 Sanjay。 gperftools 的一些经典用法,我们就不在这里进行介绍了,大家可以自行查看文档。而使用 gperftools 可以在不重启程序的情况下,进行内存泄露检查,这个恐怕是很少有人了解。 实际上我们 Release 版本的 C++ 程序可执行文件在编译时全部都链接了 gperftools。在 gperftools 的 heap profiler 中,提供了 HeapProfilerStart 和 HeapProfilerStop 的接口,使得我们可以在运行时启动和停止 heap profiler。同时,我们每个程序都暴露了 RPC 接口,用于接收控制命令和调试命令。在调试命令中,我们就增加了调用 HeapProfilerStart 和 HeapProfilerStop 的命令。由于链接了 tcmalloc,所以 tcmalloc 可以获取所有内存分配和回收的信息。当 heap profiler 启动后,就会定期的将程序内存分配和回收的行为 dump 到一个临时文件中。 当程序运行一段时间后,你将得到一组 heap profile 文件 profile.0001.heap profile.0002.heap ... profile.0100.heap 每个 profile 文件中都包含了一段时间内,程序中内存分配和回收的记录。如果想要找到内存泄露的线索,可以通过使用 pprof --base=profile.0001.heap /usr/bin/xxx profile.0100.heap --text 来进行查看,也可以生成 pdf 文件,会更直观一些。 ![v2-a8eedcc8f07691a31707f5f8921acfa8_hd.png][] 这样一来,我们就可以很方便的对线上程序的内存泄露进行 Debug 了。 ## 写在最后 ## C++ 可谓是最复杂、最灵活的语言,也最容易给大家带来困扰。如果想要用好 C++,团队必须保持比较成熟的心态,团队成员必须愿意按照一定的规则来使用 C++,而不是任性的随意发挥。这样大家才能把更多精力放在业务本身,而不是编程语言的特性上。 [https_zhuanlan.zhihu.com_p_51898119]: https://zhuanlan.zhihu.com/p/51898119 [v2-c861a6b88df3c9c823d3b19cf121ee83_hd.png]: /images/20220327/8620dbf5e8404f3080c5026e8e5c54f0.png [v2-f3189547daa4548bc4ab6fdd13eeea6d_hd.png]: /images/20220327/68fcfc8f9a9441e18ca7e548b7bcd30a.png [Link 1]: http://link.zhihu.com/?target=https%3A//github.com/google/leveldb/blob/master/util/arena.h [smartx_ Coroutine _ RPC _C]: https://zhuanlan.zhihu.com/p/29284617 [v2-00887db33a534dd51a5444c4134f56f6_hd.png]: /images/20220327/182b8fa213df4569b7ea593e3a2f2ff4.png [RAII_Resource Acquisition Is Initialization]: http://link.zhihu.com/?target=https%3A//en.wikipedia.org/wiki/Resource_acquisition_is_initialization [gperftools]: http://link.zhihu.com/?target=https%3A//github.com/gperftools/gperftools [Sanjay Ghemawat]: http://link.zhihu.com/?target=https%3A//en.wikipedia.org/wiki/Sanjay_Ghemawat [Jeff Dean]: http://link.zhihu.com/?target=https%3A//en.wikipedia.org/wiki/Jeff_Dean_%28computer_scientist%29 [MapReduce]: http://link.zhihu.com/?target=https%3A//en.wikipedia.org/wiki/MapReduce [v2-a8eedcc8f07691a31707f5f8921acfa8_hd.png]: /images/20220327/af850e090e214c73b287627ceacac0d0.png
相关 如何在Java中避免内存泄露 在Java中,避免内存泄漏通常需要遵循以下几个原则: 1. **对象生命周期管理**:确保每个对象都有明确的生命周期,当不再需要时应及时释放。 2. **避免静态引用**: 约定不等于承诺〃/ 2024年09月17日 15:39/ 0 赞/ 10 阅读
相关 如何在Java中避免内存泄露 内存泄露是指程序在申请内存后,无法释放已申请的内存空间,导致系统可用内存逐渐减少。在Java中避免内存泄露,可以遵循以下几个原则: 1. 使用Java集合框架(如List、S 心已赠人/ 2024年09月16日 05:18/ 0 赞/ 9 阅读
相关 在Java中,如何避免内存泄露? 在Java中,避免内存泄露主要涉及以下几个方面: 1. **对象生命周期管理**:确保对象在不再需要时被正确地回收。例如,在循环结束后释放资源。 ```java Itera 清疚/ 2024年09月15日 10:12/ 0 赞/ 8 阅读
相关 HashMap如何避免内存泄露问题 > HashMap对于Java开发人员来说,应该是一种非常非常熟悉的数据结构了,应用场景相当广泛。 > 本文重点不在于介绍如何使用HashMap,而是关注在使用HashMa 快来打我*/ 2024年03月27日 17:14/ 0 赞/ 54 阅读
相关 4类 JavaScript 内存泄露及如何避免 > 原文:[4 Types of Memory Leaks in JavaScript and How to Get Rid Of Them][] > 笔记:[涂鸦码龙][ 向右看齐/ 2023年10月12日 03:42/ 0 赞/ 87 阅读
相关 避免Android内存泄露 Android的应用被限制为最多占用16m的内存,至少在T-Mobile G1上是这样的(当然现在已经有几百兆的内存可以用了——译者注)。它包括电话本身占用的和开发者可 我不是女神ヾ/ 2022年07月28日 01:15/ 0 赞/ 179 阅读
相关 Android 如何避免Handler引起内存泄露 错误代码 如果在Activiy中通过[内部类][Link 1](Runnable)的方式定义了一个变量runnable, \[java\] [view plain][ 淩亂°似流年/ 2022年07月28日 00:20/ 0 赞/ 177 阅读
相关 C++ 如何避免内存泄露 转载于:[https://zhuanlan.zhihu.com/p/51898119][https_zhuanlan.zhihu.com_p_51898119] 前言 梦里梦外;/ 2022年03月27日 08:37/ 0 赞/ 251 阅读
相关 ThreadLocal的内存泄露分析以及如何避免? 前言 在分析ThreadLocal导致的内存泄露前,需要普及了解一下内存泄露、强引用与弱引用以及GC回收机制,这样才能更好的分析为什么ThreadLocal会导致内存泄露 比眉伴天荒/ 2021年09月25日 13:44/ 0 赞/ 323 阅读
还没有评论,来说两句吧...