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

文章目录

      • TcpConnection
      • Buffer
      • Log
      • ThreadPool
      • 定时器
      • 限制并发连接

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 Task;

// 想改成的样子
typedef std::function Task;

定时器

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

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

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

限制并发连接

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

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

再看果然会涨姿势。

你可能感兴趣的:(探索muduo)