整理下muduo主要类的实现思路

TcpConnection

唯一一个用智能指针控制声明周期的类，找了好久才找到什么时候结束。在TcpServer里面会有保存Conn的一个智能指针，所以引用计数一直为1。

当你收到对端关闭的消息的时候，因为是在handleEvent()里面，不能直接析构，所以TcpConnection::handleClose()里面用了一个shared_from_this()把引用计数临时加1，并且把TcopConnection::connectDestory()函数当成任务让loop去执行，这样，当loop执行这个函数之后就可以愉快的进行析构了。

Buffer

这个buffer真的是被老师diss了好久。。。说一下它的数据结构，就是一个vector，里面分成三部分。第一部分是8个字节，作为留出来的头部，方便之后在前面加个buflen之类的东西。第二部分是readable部分，数据从对端来了之后都要放在这里，没有固定大小，太大了会占用后面部分的空间，再大vector会自动扩容，但是不会自动缩小。第三部分紧跟着第二部分的结尾，作为writeable部分，意义是发送缓冲区，同上，自动扩大但不会自动缩小。

有一个问题，当每个连接都用很大的Buffer的时候，连接一多内存占用就会很大，但是这些Buffer的利用率并不大。所以muduo给了一个解决方案，在栈上分配空间，然后用readv()进行读取。那么问题来了，这个栈空间是谁的栈？答案是，栈是在Buffer::readFD()里面，当函数结束的时候就会销毁。目的是减少系统调用，一次性读的数据越多越好。用开辟栈空间和append数据的时间 替换 多次调用read系统调用的时间，如果read时间更长的话那么这么做会更快。

Log

日志呢，用了双缓冲技术，思路就是准备两个buffer A和B。前端向A写数据，A满了之后交换A和B，后端把填满的A写回硬盘，如此往复。muduo那边是准备了4块，不够用的话还可以再临时申请空间。程序崩溃问题解决方案是内存中的日志消息都带有cookie/centery，其值是某个函数的地址，可用gdb find命令去查看，可以看到崩溃时的日志消息。（还不太懂，以后看到再补充，如果还能想起来补充的话）

ThreadPool

这个就是正常的线程池了，生产者消费者模型，用条件变量、互斥锁进行维护。感觉上锁代价还是挺高的，没和CAS对比过。

关于状态机和回调函数的问题，muduo是没办法处理的(至少我觉得不好处理)。改进方案是改变Task的函数，在里面放点参数进去，比如状态啊，回调函数啊，参数啥的，这样就会好很多。

// 原本Task长这样
typedef std::function<void()> Task;

// 想改成的样子
typedef std::function<void(ThreadData,CallBack,param1,param2, ...)> Task;

定时器

set+时间线实现的，嗯，就是感觉时间线更贴切一点。

维护两个set，timers和 activeTimers，一个用来正常情况下，保存各种任务，另一个负责在cancel任务的时候保证任务可以正确cancel掉。

因为在getExpired的时候会将过期任务从times里面删掉，执行完成之后如果有repeat任务再添加上去。那么当执行的时候我调用cancel命令就不会再times里面找到该任务，这时activeTimers就可以派上用场了，现在activeTimers里面找，如果找到，则加入到calcelingTimers里面，没找到就是取消一个不存在的任务，不用管。当执行完任务想要reset的时候，如果任务再cancelingTimers里面就不会reset上去。

限制并发连接

这块muduo是用了一个空闲文件描述符来完成的。

具体就是用一个文件描述符指向一个空闲文件，当连接满了之后，用这个文件描述符去接这个新连接，然后close掉，再指向空闲文件，如此往复。这样就不会出现busy loop的情况，client也会知道服务器繁忙。

再看果然会涨姿势。