昨天写了一篇文章介绍了CLOSE_WAIT,有个粉丝说我没有讲到到问题的关键，因为在实际项目中，我们关心的是如果服务器保持了大量的CLOSE_WAIT应该怎么解决。自己从自己刨的坑里跳出来这里我分享自己在之前搭建的一个server保持了大量的的CLOSE_WAIT的解决方法。修改TCP/IP任务优先级，从而确保网络任务的实时响应扩大临界资源访问周期，确切的说是减少临界资源的访问，从而能够让TCP/IP任务获得更多的CPU运行权限。
昨天写了一篇文章介绍了CLOSE_WAIT ,有个粉丝说我没有讲到到问题的关键，因为在实际项目中，我们关心的是如果服务器保持了大量的CLOSE_WAIT应该怎么解决。说的也是，因为在具体的项目开发过程中，面对PM ,面对项目Schedule ,快速的重现问题、定位问题、解决问题才是王道。
自己从自己刨的坑里跳出来这里我分享自己在之前搭建的一个server 保持了大量的的CLOSE_WAIT的解决方法。
开始的时候是发现自己搭建的server 运行一段时间以后就ping 不通了，客户端也连接不上了，最后发现是server端有大量的CLOSE_WAIT状态的tcp pcb ，至于怎么发现的你就不要问了，我说过了我不是TCP/IP高手，发现问题是一个痛苦的过程
我的系统运行的是FreeRTOS操作系统的 ,TCP协议作为FreeRTOS一个Task运行，TCP/IP协议栈的优先级并不高，这个其实也不是最主要的，最最要的是其他Task中,有个Task会频繁的周期性的访问临界资源，说到这里估计高手们应该都看出门道了，是的，临界资源保护会屏蔽软件中断，协议栈线程受系统调度的影响，以至于server的应用程序不能实时响应网络上连接处理。
修改TCP/IP任务优先级，从而确保网络任务的实时响应
扩大临界资源访问周期，确切的说是减少临界资源的访问，从而能够让TCP/IP任务获得更多的CPU运行权限。
这样修改以后，问题就没了。对程序员来说，解掉一个棘手的bug ，有一种奥特曼打怪兽的感觉。
