-
我的服务跑着跑着就再也连不上下游了,报 too many open files,netstat 一看几千个 CLOSE_WAIT 堆在那,我对着忘记关闭 HTTP 响应体导致连接泄漏这个坑排查大半天的复盘
一个让我对关闭资源彻底敬畏的网络坑,可怕在它是缓慢累积定时爆发的雷:服务刚启动一切正常,运行几小时甚至几天后突然像被掐住喉咙,再也无法建立任何新连接、整个服务瘫痪。需求很常见:服务频繁调下游 HTTP 接口拿数据,我用 Go 写了个调用函数 resp,err := http.Get(url),用完却忘了 resp.Body.Close()。测试和刚上线跑得好好的,运行一段后告警:dial tcp …- 0
- 0
-
我在 for 循环里处理一批文件、每个都 defer f.Close(),结果跑到一半就报 too many open files,我对着 defer 的执行时机排查了大半天的复盘
写了个 Go 批处理:一个函数里 for 循环遍历几千个文件,每个打开、处理、defer f.Close() 关闭,自觉很规范每个打开都配了 defer Close。结果跑到一半就崩:too many open files。困惑——我明明每个文件都 defer Close 了啊怎么还打开太多?排查大半天才理解 defer 一个关键却极易忽略的特性:defer 是在"函数返回时"…- 0
- 0
资源管理
幸运之星正在降临...
点击领取今天的签到奖励!
恭喜!您今天获得了{{mission.data.mission.credit}}积分
我的优惠劵
-
¥优惠劵使用时效:无法使用使用时效:
之前
使用时效:永久有效优惠劵ID:×
没有优惠劵可用!


