缘起
最近在补一些基础知识,恰好涉及到了智能指针std::weak_ptr在解决std::shared_ptr时候循环引用的问题,如下:
classA{ public: std::weak_ptrb_ptr; }; classB{ public: std::weak_ptra_ptr; }; autoa=std::make_shared(); autob=std::make_shared(); a->b_ptr=b; b->a_ptr=a;
就问了下,通常的用法是将A或者B中间的某一个变量声明为std::weak_ptr,如果两者都声明为std::weak_ptr会有什么问题?
咱们先不论这个问题本身,在随后的讨论中,风神突然贴了段代码:
#include#include #include usingnamespacestd; structA{ charbuffer[1024*1024*1024];//1GB weak_ptrnext; }; intmain(){ while(true){ autoa0=make_shared(); autoa1=make_shared(); autoa2=make_shared(); a0->next=a1; a1->next=a2; a2->next=a0; //thisweak_ptrleak: newweak_ptr{a0}; this_thread::sleep_for(chrono::seconds(3)); } return0; }
说实话,当初看了这个代码第一眼,是存在内存泄漏的(new一个weak_ptr没有释放),而没有理解风神这段代码真正的含义,于是在本地把这段代码编译运行了下,我的乖乖,内存占用如图:
emm,虽然存在内存泄漏,但也不至于这么大,于是网上进行了搜索,直至我看到了下面这段话:
make_shared 只分配一次内存, 这看起来很好. 减少了内存分配的开销. 问题来了, weak_ptr 会保持控制块(强引用, 以及弱引用的信息)的生命周期, 而因此连带着保持了对象分配的内存, 只有最后一个 weak_ptr 离开作用域时, 内存才会被释放. 原本强引用减为 0 时就可以释放的内存, 现在变为了强引用, 若引用都减为 0 时才能释放, 意外的延迟了内存释放的时间. 这对于内存要求高的场景来说, 是一个需要注意的问题.
如果介意上面new那点泄漏的话,不妨修改代码如下:
#include#include #include usingnamespacestd; structA{ charbuffer[1024*1024*1024];//1GB weak_ptrnext; }; intmain(){ std::weak_ptrwptr; { autosptr=make_shared(); wptr=sptr; } this_thread::sleep_for(chrono::seconds(30)); return0; }
也就是说,对于std::shared_ptr ptr(new Obj),形如下图:
而对于std::make_shared,形如下图:
好了,理由上面已经说明白了,不再赘述了,如果你想继续分析的话,请看下文,否则~~
原因
虽然上节给出了原因,不过还是好奇心驱使,想从源码角度去了解下,于是打开了好久没看的gcc源码。
std::make_shared
首先看下它的定义:
templateinlineshared_ptr<_Tp>make_shared(_Args&&...__args){ typedeftypenamestd::remove_cv<_Tp>::type_Tp_nc; returnstd::allocate_shared<_Tp>(std::allocator<_Tp_nc>(), std::forward<_Args>(__args)...); }
这个函数函数体只有一个std::allocate_shared,接着看它的定义:
templateinlineshared_ptr<_Tp> allocate_shared(const_Alloc&__a,_Args&&...__args){ returnshared_ptr<_Tp>(_Sp_alloc_shared_tag<_Alloc>{__a}, std::forward<_Args>(__args)...); }
创建了一个shared_ptr对象,看下其对应的构造函数:
templateshared_ptr(_Sp_alloc_shared_tag<_Alloc>__tag,_Args&&...__args) :__shared_ptr<_Tp>(__tag,std::forward<_Args>(__args)...){}
接着看__shared_ptr这个类对应的构造函数:
template__shared_ptr(_Sp_alloc_shared_tag<_Alloc>__tag,_Args&&...__args) :_M_ptr(),_M_refcount(_M_ptr,__tag,std::forward<_Args>(__args)...) {_M_enable_shared_from_this_with(_M_ptr);}
其中,_M_refcount的类型为__shared_count,也就是说我们通常所说的引用计数就是由其来管理。
因为调用make_shared函数,所以这里的_M_ptr指针也就是相当于一个空指针,然后继续看下_M_refcount(请注意_M_ptr作为参数传入)定义:
template__shared_count(_Tp*&__p,_Sp_alloc_shared_tag<_Alloc>__a,_Args&&...__args){ typedef_Sp_counted_ptr_inplace<_Tp, _Alloc, _Lp>_Sp_cp_type;//L1 typename_Sp_cp_type::__allocator_type__a2(__a._M_a);//L2 auto__guard=std::__allocate_guarded(__a2); _Sp_cp_type*__mem=__guard.get();//L3 auto__pi=::new(__mem)_Sp_cp_type(__a._M_a,std::forward<_Args>(__args)...);//L4 __guard=nullptr; _M_pi=__pi; __p=__pi->_M_ptr();//L5 }
这块代码当时看了很多遍,一直不明白在没有显示分配对象内存的情况下,是如何使用placement new的,直至今天上午,灵光一闪,突然明白了,且听慢慢道来。
首先看下L1行,其声明了模板类_Sp_counted_ptr_inplace的别名为_Sp_cp_type,其定义如下:
templateclass_Sp_counted_ptr_inplacefinal:public_Sp_counted_base<_Lp> { class_Impl:_Sp_ebo_helper<0, _Alloc> { typedef_Sp_ebo_helper<0, _Alloc>_A_base; public: explicit_Impl(_Alloc__a)noexcept:_A_base(__a){} _Alloc&_M_alloc()noexcept{return_A_base::_S_get(*this);} __gnu_cxx::__aligned_buffer<_Tp>_M_storage; }; public: using__allocator_type=__alloc_rebind<_Alloc, _Sp_counted_ptr_inplace>; //Allocparameterisnotareferencesodoesn'taliasanythingin__args template _Sp_counted_ptr_inplace(_Alloc__a,_Args&&...__args) :_M_impl(__a) { //_GLIBCXX_RESOLVE_LIB_DEFECTS //2070.allocate_sharedshoulduseallocator_traits::construct allocator_traits<_Alloc>::construct(__a,_M_ptr(), std::forward<_Args>(__args)...);//mightthrow } ~_Sp_counted_ptr_inplace()noexcept{} virtualvoid _M_dispose()noexcept { allocator_traits<_Alloc>::destroy(_M_impl._M_alloc(),_M_ptr()); } //Overridebecausetheallocatorneedstoknowthedynamictype virtualvoid _M_destroy()noexcept { __allocator_type__a(_M_impl._M_alloc()); __allocated_ptr<__allocator_type>__guard_ptr{__a,this}; this->~_Sp_counted_ptr_inplace(); } private: friendclass__shared_count<_Lp>;//Tobeabletocall_M_ptr(). _Tp*_M_ptr()noexcept{return_M_impl._M_storage._M_ptr();} _Impl_M_impl; };
这个类继承于_Sp_counted_base,这个类定义不再次列出,需要注意的是其中有两个变量:
_Atomic_word_M_use_count;//#shared _Atomic_word_M_weak_count;//#weak+(#shared!=0)
第一个为强引用威廉希尔官方网站 ,也就是shared对象引用计数,另外一个为弱因为计数。
继续看这个类,里面定义了一个class _Impl,其中我们创建的对象类型就在这个类里面定义,即**__gnu_cxx::__aligned_buffer<_Tp> _M_storage;**
接着看L2,这行定义了一个对象__a2,其对象类型为using __allocator_type = __alloc_rebind<_Alloc, _Sp_counted_ptr_inplace>;,这行的意思是重新封装rebind_alloc<_Sp_counted_ptr_inplace>
继续看L3,在这一行中会创建一块内存,这块内存中按照顺序为创建对象、强引用计数、弱引用计数等(也就是说分配一大块内存,这块内存中 包含对象、强、弱引用计数所需内存等),在创建这块内存的时候,强、弱引用计数已经被初始化
最后是L3,这块调用了placement new来创建,其中调用了对象的构造函数:
template_Sp_counted_ptr_inplace(_Alloc__a,_Args&&...__args) :_M_impl(__a) { //_GLIBCXX_RESOLVE_LIB_DEFECTS //2070.allocate_sharedshoulduseallocator_traits::construct allocator_traits<_Alloc>::construct(__a,_M_ptr(), std::forward<_Args>(__args)...);//mightthrow }
至此,整个std::make_shared流量已经完整的梳理完毕,最后返回一个shared_ptr对象。
好了,下面继续看下令人迷惑的,存在大内存不分配的这行代码:
newweak_ptr{a0};
其对应的构造函数如下:
template> __weak_ptr(const__shared_ptr<_Yp, _Lp>&__r)noexcept :_M_ptr(__r._M_ptr),_M_refcount(__r._M_refcount) {}
其中_M_refcount的类型为__weak_count,而\__r._M_refcount即常说的强引用计数类型为__shared_count,其继承于接着往下看:
__weak_count(const__shared_count<_Lp>&__r)noexcept :_M_pi(__r._M_pi) { if(_M_pi!=nullptr) _M_pi->_M_weak_add_ref(); }
emm,弱引用计数加1,也就是说此时_M_weak_count为1。
接着,退出作用域,此时有std::make_shared创建的对象开始释放,因此其内部的成员变量r._M_refcount也跟着释放:
~__shared_count()noexcept { if(_M_pi!=nullptr) _M_pi->_M_release(); }
接着往下看_M_release()实现:
template<> inlinevoid _Sp_counted_base<_S_single>::_M_release()noexcept { if(--_M_use_count==0) { _M_dispose(); if(--_M_weak_count==0) _M_destroy(); } }
此时,因为shared_ptr对象的引用计数本来就为1(没有其他地方使用),所以if语句成立,执行_M_dispose()函数,在分析这个函数之前,先看下前面提到的代码:
__shared_ptr(_Sp_alloc_shared_tag<_Alloc>__tag,_Args&&...__args) :_M_ptr(),_M_refcount(_M_ptr,__tag,std::forward<_Args>(__args)...) {_M_enable_shared_from_this_with(_M_ptr);}
因为是使用std::make_shared()进行创建的,所以_M_ptr为空,此时传入_M_refcount的第一个参数也为空。接着看_M_dispose()定义:
template<> inlinevoid _Sp_counted_ptr::_M_dispose()noexcept{} template<> inlinevoid _Sp_counted_ptr ::_M_dispose()noexcept{} template<> inlinevoid _Sp_counted_ptr ::_M_dispose()noexcept{}
因为传入的指针为nullptr,因此调用了_Sp_counted_ptr的特化版本,因此_M_dispose()这个函数什么都没做。因为_M_pi->_M_weak_add_ref();这个操作,此时这个计数经过减1之后不为0,因此没有没有执行_M_destroy()操作,因此之前申请的大块内存没有被释放,下面是_M_destroy()实现:
virtualvoid _M_destroy()noexcept { __allocator_type__a(_M_impl._M_alloc()); __allocated_ptr<__allocator_type>__guard_ptr{__a,this}; this->~_Sp_counted_ptr_inplace(); }
也就是说真正调用了这个函数,内存才会被分配,示例代码中,显然不会,这就是造成内存一直不被释放的原因。
总结
下面解释下我当时阅读这块代码最难理解的部分,下面是make_shared执行过程:
下面是析构过程:
整体看下来,比较重要的一个类就是_Sp_counted_base 不仅充当引用计数功能,还充当内存管理功能。从上面的分析可以看到,_Sp_counted_base负责释放用户申请的申请的内存,即
•当 _M_use_count 递减为 0 时,调用 _M_dispose() 释放 *this 管理的资源•当 _M_weak_count 递减为 0 时,调用 _M_destroy() 释放 *this 对象
审核编辑:刘清
-
STD
+关注
关注
0文章
36浏览量
14358 -
变量
+关注
关注
0文章
613浏览量
28363 -
内存泄漏
+关注
关注
0文章
39浏览量
9215
原文标题:一次诡异的内存泄漏
文章出处:【微信号:CPP开发者,微信公众号:CPP开发者】欢迎添加关注!文章转载请注明出处。
发布评论请先 登录
相关推荐
评论