数据库连接不释放问题实际上上线之前就会发现，线上系统出这种问题根本就是测试不过关。
我之前也遇到过出现很多CLOSE_WAIT的场景，一般出现这种情况，都是同步通信的场景，server端执行业务超时，client端主动断开连接的场景。
特别是一些写库的操作，随着表越来越大，写操作越来越慢，当慢到一定程序后会触发client端的超时再重试机制，越来越多的写操作积压在server端，很短的时间内server端被搞的socket全是CLOSE_WAIT，只能重启，重启也是好一段时间。
所以现在我们现在对同步通信机制一定要保证不能有不可预估的开销。这类开销一律走异步机制
实现负载均衡：通过实现负载均衡，将请求分发到多个服务器上，以分散负载并提高系统的吞吐量。负载均衡可以帮助避免单个服务器过载的情况发生。
调整应用程序逻辑：如果应用程序的逻辑不合理或存在性能瓶颈，可能会导致接口响应缓慢或超时。可以对应用程序逻辑进行调整或优化，以提高接口的响应速度和处理能力。
看着像啊，盲猜。负载均衡对外的链接数被限制了，比如port_range设置过小达不到65536这样。请求一直发，很容易就打满端口号，
这里提出两个思考题，我觉得非常有意义，大家自己思考下：
为什么一台机器几百个 CLOSE_WAIT 就导致不可继续访问？我们不是经常说一台机器有 65535 个文件描述符可用吗？
为什么我有负载均衡，而两台部署服务的机器确几乎同时出了 CLOSE_WAIT ?
看着像啊，盲猜。负载均衡对外的链接数被限制了，比如port_range设置过小达不到65536这样。请求一直发，很容易就打满端口号，
1.需要看最大连接数配置的是多少
2.业务问题导致的异常和负载均衡没关系，出问题肯定是都出问题
请问一下 ，socket 状态 监控工具用的是什么工具