问题分类：
1、逻辑问题：结构、处理流程的设计有问题，尤其在多线程操作同一个对象时；
2、接口定义和使用问题：例如接口结构或返回情况改了，未及时编译或更改其他模块的调用；
3、对接问题：对讲问题不是你的问题，就是我的问题，需要联查；
4、理解问题：对功能、逻辑流程或函数定义和使用的理解不清晰；
5、异常处理机制问题；
6、代码细节问题：变量类型、返回值、引用、指针；
socket绑定(bind)本地端口失败
问题描述：地标协议在启用时，会主动向平台注册，socket本地端口6600（可修改），当快速关闭使能再打开时，概率性出现socket绑定本地端口失败。
问题分析：bind 普遍遭遇的问题是试图绑定一个已经在使用的端口。 该陷阱是也许没有活动的套接字存在，但仍然禁止绑定端口（bind 返回 EADDRINUSE），它由 TCP 套接字状态 TIME_WAIT 引起。该状态在套接字关闭后约保留 2 到 4 分钟。在 TIME_WAIT 状态退出之后，套接字被删除，该地址才能被重新绑定而不出问题。
解决方法：等待 TIME_WAIT 结束可能是令人恼火的一件事，特别是如果您正在开发一个套接字服务器，就需要停止服务器来做一些改动，然后重启。幸运的是，有方法可以避开 TIME_WAIT 状态。可以给套接字应用 SO_REUSEADDR 套接字选项，以便端口可以马上重用。通过sesockopt函数重置本地端口来解决该问题；
线程池、任务队列阻塞问题
问题描述：有远程操控协议为TCP短连接，通过客户端操作设备时，设备会频繁的创建线程、销毁线程，后来将设备端来请求就创建线程的机制，修改为线程池模式（固定创建4个线程，来处理请求）。线程池模型机制如下：
epoll监听socket状态→ 设备/服务端检测socket可读 → 创建task丢进任务队列 → 若任务队列为空则唤醒一个等待线程（线程池线程通过条件变量阻塞）
逻辑上是来一个任务，即唤醒一个阻塞线程，任务即被取出，任务队列又恢复成空队列。根据任务队列是否为空这个判断条件来唤醒线程就要求有一个前提是，来任务，任务被线程池取出处理后，下一次任务才会进来。当epoll监听线程添加任务、唤醒一个等待线程、但是该线程没有及时取出任务、又有新的任务添加进来时（任务队列非空），就是出现唤醒一次，但是任务队列有两个甚至多个任务，这就导致这些任务只能有这个被唤醒的线程处理，并且再有任务进来，也不会执行唤醒，直到该线程处理完所有任务（若不能及时处理完，就会导致连接异常）。
socket套接字关闭问题
问题描述：某协议为TCP短连接，执行一次数据交互即关闭socket套接字，在Client执行close时，Server端正常；在Client不主动关闭时，Server端的处理时，读完套接字缓冲区所有数据，然后关闭套接字，readn函数封装了recv读取指定长度数据，要么读到指定数据，要么套接字异常才返回。这就导致读套接字缓冲区时，既不到指定数据，套接字又没有被Client关闭，陷在死循环里，占据一个线程池线程。
问题分析：现使用的readn是本模块自己封装的，没有select超时机制，原有readn函数，通过select设定超时机制为2秒，超时套接字不能读，则返回-1，不会陷入死循环；
