在Tcp中断开连接比创建连接更加困难
真正执行断开连接的时候是从在channel中的handleEvent函数，在Channel中并没有handleRead、handleWrite、handleClose函数出里的实现，都是借助注册的回调来进行的。
在某一个channel上有事件到达时，执行相应的操作，更具事件类型执行相应的操作这个步骤是在handleEvent函数中进行的。在channel中有closecallback_的回调，这个函数是在什么时候被初始化的呢？肯定是它的拥有者在创建的时候赋值的。这么一来，就是在新建TcpConnection的时候，channel中的closeCallback是TcpConnection初始化的，在初始化TcpConnection的时候将TcpConnection中的handleClose赋值个Channel宏的closeCallback。那么在TcpConnection中的handleClose都是什么工作呢？
handleClose的在read为0的时候也被调用，同时也被注册到Channel的closecallback.
在handleClose函数中，首先保证执行这个函数实在IO线程。然后调用用户的connectionCallback_,最用调用它的成员函数closeCallback_。
所以到目前为止出现了两个closeCallback,Channel中是给TcpConnection使使用的，TcpConnection中的是个TcpServer使用的，用于通知他们移除所持有的TcpConnectionPtr.不是给普通用户用的，普通用户继续使用ConnectionCallback.
接下来看看，TcpServer给TcpConnection注册的是什么closeCallback_
注册的是removeConnection函数
这个函数保证是在主IO线程中执行removeConnectionInLoop函数。后者又执行了connectDestory函数.
TcpConnection::handleClose()的主要功能是调用closeCallback_，这个回调绑定到TcpServer::removeConnection()函数。
TcpServer中的removeConnection函数被非为了两个部分，因为TcpConnection会在自己的ioLoop线程调用removeConnection（原因是新建TcpConnection的时候将他分为某一个ioLoop），为了避免这样情况发生，所以需要把它移到TcpServer的loop_线程。但是为了保证TcpConnection的ConnectionCallback始终在其ioLoop回调，在removeInLoop函数中需要将connectDestoryed放发哦ioLoop中执行！！！
muduo源码分析--连接的断开,布布扣,bubuko.com
muduo源码分析--连接的断开
原文：http://blog.csdn.net/yusiguyuan/article/details/22679299
