enable_shared_from_this用法分析

時間 2019-12-01

標籤 enable shared 用法分析简体版

原文原文鏈接

1、背景

在爲何須要異步編程文章末尾提到，"爲了使socket和緩衝區（read或write）在整個異步操做的生命週期一直保持活動，咱們須要採起特殊的保護措施。你的鏈接類須要繼承自enabled_shared_from_this，而後在內部保存它須要的緩衝區，並且每次異步調用都要傳遞一個智能指針給this操做"。本文就詳細介紹爲何使用enabled_shared_from_this就能保證對象的生命週期，以及enabled_shared_from_this內部的具體實現分析。html

2、爲何須要保證對象生命週期

首先想象下同步編程，好比socket創建connect後，read或者write數據，由於是同步阻塞的，數據傳輸完後，socket對象就已經完成了這次任務，此時就算對象銷燬，也並不會引發異常。可是異步編程就不同了，當一個線程調用一個異步函數（例如：該函數仍是socket寫文件任務），該函數會當即返回，儘管規定的任務尚未完成，這樣線程就會執行異步函數的下一條語句，而不會被掛起。只有當"寫文件任務"完成後，由新的線程發送完成消息來執行結果同步，可是當新的線程完成"寫文件任務"後，再發送過來，此時異步函數調用方對象是否還存在，這就是個須要解決的問題，這也就是爲何須要保證對象的生命週期。ios

更加直白一點的例子，假設你須要作下面的操做：git

io_service service;
ip::tcp::socket sock(service);
char buff[512];
...
read(sock, buffer(buff));

在這個例子中，sock和buff的存在時間都必須比read()調用的時間要長。也就是說，在調用read()返回以前，它們都必須有效。你傳給一個方法的全部參數在方法內部都必須有效。當咱們採用異步方式時，事情會變得比較複雜。github

io_service service;
ip::tcp::socket sock(service);
char buff[512];
void on_read(const boost::system::error_code &, size_t) {}
...
async_read(sock, buffer(buff), on_read);

在這個例子中，sock和buff的存在時間都必須比async_read()操做自己時間要長，可是read操做持續的時間咱們是不知道的，由於它是異步的。當socket知足條件，有數據可讀時，此時操做系統會把數據發送到緩衝區，觸發async_read的回調函數on_read執行，on_read執行來經過socket讀取數據到buffer，因此必須socket和buffer的生命週期要能獲得保證。那究竟用什麼方法呢？編程

3、實踐中使用方法

異步編程時，咱們在傳入回調函數的時候，一般會想要其帶上當前類對象的上下文，或者回調自己就是類成員函數，那這個工做天然非this指針莫屬了，像這樣：安全

void sock_sender::post_request_no_lock()
{
    Request &req = requests_.front();
    boost::asio::async_write(
        *sock_ptr_, 
        boost::asio::buffer(req.buf_ptr->get_content()),
        boost::bind(&sock_sender::self_handler, this, _1, _2));
}

然而回調執行的時候並必定對象還存在。爲了確保對象的生命週期大於回調，咱們可使類繼承自enable_shared_from_this，而後回調的時候使用bind傳入shared_from_this()返回的智能指針。因爲bind保存的是參數的副本，bind構造的函數對象會一直持有一個當前類對象的智能指針而使其引用計數不爲0，這就確保了對象的生命週期大於回調中構造的函數對象的生命週期，像這樣：異步

class sock_sender : public boost::enable_shared_from_this<sock_sender>
{
    //...
};
void sock_sender::post_request_no_lock()
{
    Request &req = requests_.front();
    boost::asio::async_write(
        *sock_ptr_,
        boost::asio::buffer(req.buf_ptr->get_content()),
        boost::bind(&sock_sender::self_handler, shared_from_this(), _1, _2));
}

「實際上邊已經提到了，延長資源的生命週期防止使用它時已經被釋放。這種問題絕大部分出如今異步調用的時候。由於異步函數的執行時間點沒法肯定。異步函數可能會使用異步調用以前的變量（好比類對象），這樣就必須保證該變量在異步執行期間有效。如何作到這一點呢？只須要傳遞一個指向自身的shared_ptr（必須使用shared_from_this()）給異步函數。由於這個拷貝過程使得對資源的引用計數加一。
socket

4、關於enable_shared_from_this的原理分析

首先要說明的一個問題是：如何安全地將this指針返回給調用者。通常來講，咱們不能直接將this指針返回。
想象這樣的狀況，該函數將this指針返回到外部某個變量保存，而後這個對象自身已經析構了，但外部變量並不知道，此時若是外部變量使用這個指針，就會使得程序崩潰。async

使用智能指針shared_ptr看起來是個不錯的解決方法。但問題是如何去使用它呢？咱們來看以下代碼：tcp

#include <iostream>
#include <boost/shared_ptr.hpp>
class Test
{
public:
    //析構函數
    ~Test() { std::cout << "Test Destructor." << std::endl; }
    //獲取指向當前對象的指針
    boost::shared_ptr<Test> GetObject()
    {
        boost::shared_ptr<Test> pTest(this);
        return pTest;
    }
};
int main(int argc, char *argv[])
{
    {
        boost::shared_ptr<Test> p( new Test( ));
        std::cout << "q.use_count(): " << q.use_count() << std::endl; 
        boost::shared_ptr<Test> q = p->GetObject();
    }
    return 0;
}

運行後，程序輸出：

　　Test Destructor.
　　q.use_count(): 1
　　Test Destructor.

能夠看到，對象只構造了一次，但卻析構了兩次。而且在增長一個指向的時候，shared_ptr的計數並無增長。也就是說，這個時候，p和q都認爲本身是Test指針的惟一擁有者，這兩個shared_ptr在計數爲0的時候，都會調用一次Test對象的析構函數，因此會出問題。

那麼爲何會這樣呢？給一個shared_ptr 傳遞一個this指針難道不能引發shared_ptr 的計數嗎？

答案是：對的，shared_ptr 根本認不得你傳進來的指針變量是否是以前已經傳過。

看這樣的代碼：

int main()
{
    Test* test = new Test();
    shared_ptr<Test> p(test);
    shared_ptr<Test> q(test);
    std::cout << "p.use_count(): " << p.use_count() << std::endl;
    std::cout << "q.use_count(): " << q.use_count() << std::endl;
    return 0;
}

運行後，程序輸出：

p.use_count(): 1
q.use_count(): 1
Test Destructor.
Test Destructor.

也證實了剛剛的論述：shared_ptr 根本認不得你傳進來的指針變量是否是以前已經傳過。

事實上，類對象是由外部函數經過某種機制分配的，並且一經分配當即交給 shared_ptr管理，並且之後凡是須要共享使用類對象的地方，必須使用這個 shared_ptr看成右值來構造產生或者拷貝產生（shared_ptr類中定義了賦值運算符函數和拷貝構造函數）另外一個shared_ptr ，從而達到共享使用的目的。

解釋了上述現象後，如今的問題就變爲了：如何在類對象（Test）內部中得到一個指向當前對象的shared_ptr 對象？（以前證實，在類的內部直接返回this指針，或者返回return shared_ptr pTest(this);）不行，由於shared_ptr根本認不得你傳過來的指針變量是否是以前已經傳過，你本意傳個shared_ptr pTest(this)是想這個對象use_count=2，就算this對象生命週期結束，可是也不delete，由於你異步回來還要用對象裏面的東西。)
若是咱們可以作到這一點，直接將這個shared_ptr對象返回，就不會形成新建的shared_ptr的問題了。

下面來看看enable_shared_from_this類的威力。
enable_shared_from_this 是一個以其派生類爲模板類型參數的基類模板，繼承它，派生類的this指針就能變成一個 shared_ptr。
有以下代碼：

#include <iostream>
#include <memory>

class Test : public std::enable_shared_from_this<Test>        //改進1
{
public:
    //析構函數
    ~Test() { std::cout << "Test Destructor." << std::endl; }
    //獲取指向當前對象的指針
    std::shared_ptr<Test> GetObject()
    {
        return shared_from_this();      //改進2
    }
};
int main(int argc, char *argv[])
{
    {
        std::shared_ptr<Test> p( new Test( ));
        std::shared_ptr<Test> q = p->GetObject();
        std::cout << "p.use_count(): " << p.use_count() << std::endl;
        std::cout << "q.use_count(): " << q.use_count() << std::endl;
    }
    return 0;
}

運行後，程序輸出：

p.use_count(): 2
    q.use_count(): 2
    Test Destructor.

能夠看到，問題解決了！只有一次new對象，那麼釋放的時候也就一次，不會出現兩次而引發程序崩潰。可是要說明的是，這裏舉的例子是兩個shared_ptr p和q都離開做用域時，Test對象才調用了析構函數，真正釋放對象。可是咱們在異步函數裏面其目的是:

struct connection : boost::enable_shared_from_this<connection> {
    typedef boost::shared_ptr<connection> ptr;
    void start(ip::tcp::endpoint ep) {
        sock_.async_connect(ep, boost::bind(&connection::on_connect, shared_from_this(), _1));
    }
};

int main(int argc, char* argv[]) {
    ip::tcp::endpoint ep( ip::address::from_string("127.0.0.1"), 8001);
    connection::ptr(new connection)->start(ep);
}

一、這裏的connection::ptr(new connection)->start(ep);可否用普通new的指針，而沒有被shared_ptr託管的指針？答案是不能，緣由見後面說明2。
二、這段server端的代碼，每當有不一樣client連過來，就會觸發on_connect回調函數執行。在全部異步調用中，咱們傳遞一個boost::bind仿函數看成參數。這個仿函數內部包含了一個智能指針，指向connection實例。只要有一個異步操做等待時，Boost.Asio就會保存boost::bind仿函數的拷貝，這個拷貝保存了指向鏈接實例的一個智能指針，從而保證connection實例保持活動。問題解決！

接着來看看enable_shared_from_this 是如何工做的，如下是它的源碼：

template<class T> class enable_shared_from_this
{
protected:

    BOOST_CONSTEXPR enable_shared_from_this() BOOST_SP_NOEXCEPT
    {
    }

    BOOST_CONSTEXPR enable_shared_from_this(enable_shared_from_this const &) BOOST_SP_NOEXCEPT
    {
    }

    enable_shared_from_this & operator=(enable_shared_from_this const &) BOOST_SP_NOEXCEPT
    {
        return *this;
    }

    ~enable_shared_from_this() BOOST_SP_NOEXCEPT // ~weak_ptr<T> newer throws, so this call also must not throw
    {
    }

public:

    shared_ptr<T> shared_from_this()
    {
        shared_ptr<T> p( weak_this_ );
        BOOST_ASSERT( p.get() == this );
        return p;
    }

    shared_ptr<T const> shared_from_this() const
    {
        shared_ptr<T const> p( weak_this_ );
        BOOST_ASSERT( p.get() == this );
        return p;
    }

    weak_ptr<T> weak_from_this() BOOST_SP_NOEXCEPT
    {
        return weak_this_;
    }

    weak_ptr<T const> weak_from_this() const BOOST_SP_NOEXCEPT
    {
        return weak_this_;
    }

public: // actually private, but avoids compiler template friendship issues

    // Note: invoked automatically by shared_ptr; do not call
    template<class X, class Y> void _internal_accept_owner( shared_ptr<X> const * ppx, Y * py ) const BOOST_SP_NOEXCEPT
    {
        if( weak_this_.expired() )
        {
            weak_this_ = shared_ptr<T>( *ppx, py );
        }
    }

private:

    mutable weak_ptr<T> weak_this_;
};

} // namespace boost

#endif  // #ifndef BOOST_SMART_PTR_ENABLE_SHARED_FROM_THIS_HPP_INCLUDED

其中shared_from_this()函數的實現爲：

shared_ptr<T> shared_from_this()
    {
        shared_ptr<T> p( weak_this_ );
        BOOST_ASSERT( p.get() == this );
        return p;
    }

能夠看見，這個函數使用了weak_ptr對象(weak_this)來構造一個shared_ptr對象，而後將shared_ptr對象返回。注意這個weak_ptr是實例對象的一個成員變量，因此對於一個對象來講，它一直是同一個，每次調用shared_from_this()時，就會根據weak_ptr來構造一個臨時shared_ptr對象。

也許看到這裏會產生疑問，這裏的shared_ptr也是一個臨時對象，和前面有什麼區別？還有，爲何enable_shared_from_this 不直接保存一個 shared_ptr 成員？

對於第一個問題，這裏的每個shared_ptr都是根據weak_ptr來構造的，而每次構造shared_ptr的時候，使用的參數是同樣的，因此這裏根據相同的weak_ptr來構造多個臨時shared_ptr等價於用一個shared_ptr來作拷貝。（PS：在shared_ptr類中，是有使用weak_ptr對象來構造shared_ptr對象的構造函數的：

template<class Y>
explicit shared_ptr( weak_ptr<Y> const & r ): pn( r.pn )

對於第二個問題，假設我在類裏儲存了一個指向自身的shared_ptr，那麼這個 shared_ptr的計數最少都會是1，也就是說，這個對象將永遠不能析構，因此這種作法是不可取的。

在enable_shared_from_this類中，沒有看到給成員變量weak_this_初始化賦值的地方，那到底是如何保證weak_this_擁有着Test類對象的指針呢？

首先咱們生成類T時，會依次調用enable_shared_from_this類的構造函數（定義爲protected），以及類Test的構造函數。在調用enable_shared_from_this的構造函數時，會初始化定義在enable_shared_from_this中的私有成員變量weak_this_（調用其默認構造函數），這時的weak_this_是無效的（或者說不指向任何對象）。

接着，當外部程序把指向類Test對象的指針做爲初始化參數來初始化一個shared_ptr（boost::shared_ptr p( new Test( ));）。

如今來看看 shared_ptr是如何初始化的，shared_ptr 定義了以下構造函數：

template<class Y>
    explicit shared_ptr( Y * p ): px( p ), pn( p ) 
    {
        boost::detail::sp_enable_shared_from_this( this, p, p );
    }

裏面調用了 boost::detail::sp_enable_shared_from_this ：

template< class X, class Y, class T >
 inline void sp_enable_shared_from_this( boost::shared_ptr<X> const * ppx,
 Y const * py, boost::enable_shared_from_this< T > const * pe )
{
    if( pe != 0 )
    {
        pe->_internal_accept_owner( ppx, const_cast< Y* >( py ) );
    }
}

裏面又調用了enable_shared_from_this 的 _internal_accept_owner ：

template<class X, class Y> void _internal_accept_owner( shared_ptr<X> const * ppx, Y * py ) const
    {
        if( weak_this_.expired() )
        {
            weak_this_ = shared_ptr<T>( *ppx, py );
        }
    }

而在這裏，對enable_shared_from_this 類的成員weak_this_進行拷貝賦值，使得weak_this_做爲類對象 shared_ptr 的一個觀察者。
這時，當類對象自己須要自身的shared_ptr時，就能夠從這個weak_ptr來生成一個了：

shared_ptr<T> shared_from_this()
    {
        shared_ptr<T> p( weak_this_ );
        BOOST_ASSERT( p.get() == this );
        return p;
    }

從上面的說明來看，須要當心的是shared_from_this()僅在shared_ptr 的構造函數被調用以後才能使用，緣由是enable_shared_from_this::weak_this_並不在構造函數中設置，而是在shared_ptr 的構造函數中設置。

說明1：

因此，以下代碼是錯誤的：

class D:public boost::enable_shared_from_this<D>
{
public:
    D()
    {
        boost::shared_ptr<D> p=shared_from_this();
    }
};

緣由是在D的構造函數中雖然能夠保證enable_shared_from_this 的構造函數被調用，但weak_this_是無效的（還還沒被接管）。

說明2：

以下代碼也是錯誤的：

class D:public boost::enable_shared_from_this<D>
{
public:
    void func()
    {
        boost::shared_ptr<D> p=shared_from_this();
    }
};
void main()
{
    D d;
    d.func();
}

緣由同上。
總結爲：不要試圖對一個沒有被shared_ptr接管的類對象調用shared_from_this()，否則會產生未定義行爲的錯誤。