锁 成对出现 互斥量需要在上锁期间操作 锁的目的是为了锁住临界空间，所以肯定是会有多个线程去临界空间的对吧；
std::mutex：最基本的互斥量，调用线程发生3种情况：成功上锁，阻塞（该锁被其他线程使用），死锁（反复上锁）
std::lock_guard && unique_lock：RAII相关；前者在其生命周期内自动上解锁，初始化时即上锁；
std::atomic：原子数据类型，不需要加锁，就能实现原子操作，只有部分数据类型可用；
cond(配合std::unique_lock使用)作为全局变量，在哪个线程里调用wait就在阻塞哪个线程（此时线程是处于获得锁的情况的），他被阻塞的时候会释放锁，让其他线程去执行，被唤醒时又会重新获得锁；只唤醒一个线程和唤醒所有线程是不一样的，所有线程都被唤醒后，会去竞争锁，与notify_one不同，他们不会再阻塞，会不断去尝试获得锁；
可以唤醒所有线程可能是它和sem的关键区别；sem会记录一个值，而cond没有；
sem_t；sem_init；sem_wait；sem_post；它和cond的区别是什么啊？
sem可能是由mutex + counter + condition variable实现的；
信号量可以解决条件变量中存在的唤醒丢失问题。因为信号量有一个状态，如果想精准的同步，那么信号量可能会有特殊的地方。
信号量最有用的场景是用以指明可用资源的数量。将连接数量作为信号量；
std::thread：形参为函数名，执行相应的函数，第二个参数为相应函数的参数；
shared_ptr：<>里面指明指向的数据类型；自动销毁引用计数为0的对象；
socket()
输入参数：IPV4 or 6(AF_INET)；TCP or UDP(SOCK_STREAM)；0(自动填充)；
返回文件描述符；
bind()
用于服务器端；旨在绑定套接字和自己的IP地址和端口；
输入参数：socket()返回的文件描述符；const struct sockaddr *指针，由于兼容性的原因，这里我们只能先使用sockaddr_in 结构体来定义相应的IP地址和端口号，然后再强制转换为 sockaddr 类型的方式。
返回值：0代表成功，-1代表失败；
connect()
用于客户端；旨在连接套接字和服务器端的IP地址和端口；
返回值：0代表成功，-1代表失败；
服务器端先listen再accept；
listen()：非阻塞
输入参数：socket返回的文件描述符；能接收多少个客户端请求；
返回值：0，-1
accept()：阻塞；
输入参数：只不过这里的sockaddr_in并不需要具体的给出，另外最后的长度参数也是通过指针的方式传进去的。
返回一个新的文件描述符，后续具体的通信都使用这个文件描述符进行数据的传输；
read()&&write()
为对应的文件描述符（服务器端为accept建立的，客户端为socket建立的）。
_buf：只能是字符串的形式；
close()：关闭相应的文件描述符；
0，-1
initsocket中涉及复用和优雅关闭的问题；setsockopt()
应该是和优雅关闭相关的；
sockaddr_in
IP地址：htonl(INADDR_ANY)或者inet_addr()
端口号：htons(port_)
socklen_t
epoll事件：
处理监听；listenFd_获取的文件描述符如果和这个相等则处理监听
epollrdhup(0x2000)，epollhup(0x010)，epollerr(0x008)，关闭连接
epollin：处理读，0x001；表示对应的文件描述符可读；
epollout：处理写，0x004；
初始化了一些线程并将他们全都detach；
Listen Mode；OpenConn Mode；分别是什么含义？
epoll_create()
输入参数：size表示内核要监听的描述符数量；
返回值：文件句柄，-1
epoll_ctl()：注册要监听的事件类型；
输入参数：epoll句柄；增加，修改，删除；要监听的描述符；要监听的事件(这是另一个简单的结构体)；
返回值：0，-1
epoll_wait()：等待事件就绪，成功时返回就绪事件的数目；
输入参数：epoll句柄；从内核得到的就绪事件集合；告诉内核events的大小；等待超时时间
返回值：0，-1
服务器端listen—>epoll_wait—>accept；
底下case部分的监听部分有点看不懂，为什么要做这样一个判断呢？还有循环判断的终止索引应该是啥？
你是否还在寻找稳定的海外服务器提供商？创新互联www.cdcxhl.cn海外机房具备T级流量清洗系统配攻击溯源，准确流量调度确保服务器高可用性，企业级服务器适合批量采购，新人活动首月15元起，快前往官网查看详情吧
