闭包
在函数内部实现一个子函数，子函数的作用域内能访问外部函数的局部变量。闭包就是能够读取其他函数内部变量。但是由于闭包会使得函数中的变量都被保存在内存中，内存消耗很大，所以不能滥用闭包，否则会造成程的性能问题，可能导致内存泄露。
在上次的echo异步服务器中，在极端情况下客户端关闭导致触发写和读回调函数，二者都进入错误处理逻辑，进而造成二次析构的问题。
这里，使用C++11**智能指针（引用计数的特性）**构造成一个伪闭包的状态延长session的生命周期。
Server类改造
作为Server类，希望能够管理每一个生成的普通套接字，即管理每一个客户端连接的Session。所以在头文件中增加了一个map结构，key为唯一的uid，value则是交由智能指针管理的Session会话。
再改在Server类中的start_accept函数，将每次构造的新Session交由智能指针管理
在start_accept函数中绑定了handle_accept函数，所以这个函数也需要再改造一次
当调用start_accept函数的时候，就说明已经有新的连接到来了，这个时候需要将新的session添加到map中，供server管理。
session类改造
我们可以思考一下，当读写的时候，在触发读写回调函数的时候，session已经被释放，这样的情况是非常危险的。所以在绑定将session作为智能指针传递给回调函数，延长其生命周期。
在session类中，逻辑冲start函数中开始在绑定回调函数，该怎么将对象本身作为智能指针向下传递呢？
对象类必须继承一个模板类std::enable_shared_from_this<T>，这里的T就是类本身的类名，再继承这个模板类之后，提供有一个方法shared_from_this()，这个方法能将构造返回一个对象本身的智能指针。
至此，回调函数只用拿一个智能指针参数接收即可，若需要继续绑定其它回调函数，将这个智能指针参数继续向下传递即可。
二次析构测验
这里在读回调这里测验二次析构的问题，代码如下
具体操作是在异步写的地方打下断点，客户端连接之后立马断开，server端再继续向下执行，观察是否会发生内存崩溃的情况。
测试结果是不会发生内存崩溃的情况。
分析：这里使用shared_ptr的引用计数的策略延长对象的生命周期，实现伪闭包的效果。
再server类改造的时候，引用计数就为3。构造智能指针的时候，引用计数+1；绑定回调函数的时候，引用计数+1；加入map中，引用计数+1；所以session的引用计数至少为3，因为在session中，对应的session本身也在绑定回调函数的时候向下传递，引用计数也随之增加，离开对应作用域，引用计数也随之减少。当引用计数减至为0的时候，session的资源便会自动被释放了。
bind绑定函数的时候，会返回一个新的函数对象回来，所以在绑定函数的时候对应的智能指针的引用计数会+1。
也许上边智能指针的引用计数加减还会有疑惑，建议可以举一个客户端连接的实例分析，或者调断点打印智能指针的引用计数，观察效果。