线上服务有一类问题特别隐蔽不会直接宕机不会瞬间报错只会随着运行时间慢慢恶化。刚开始一切正常跑几天或者一两周后接口开始随机超时、请求失败、服务日志刷不出来最后彻底拒绝新连接。很多人遇到这种情况第一反应就是重启服务重启完立马恢复所有人都以为是内存泄漏、资源抖动真正的根源很少有人查到——文件句柄泄露。平时开发读写文件、调用脚本、请求socket、操作数据流很多资源打开之后没有正常关闭。单次执行完全无感系统资源看似正常归还。但高并发、高频调用场景下句柄会持续累积不会自动释放。服务器对单个进程的最大文件句柄数是有限制的。一旦打满所有需要新建文件、连接、日志、流操作的行为全部失败表现出来的症状五花八门很难直接联想到根源。最迷惑人的一点是报错信息非常零散。有的节点提示无法创建日志文件有的提示socket创建失败有的第三方接口请求直接超时还有的数据库连接获取异常。不同功能爆出完全不相关的错误很容易让人误以为是多处代码同时出问题不会统一归因为系统资源耗尽。我之前遇到过一个真实案例导出功能、日志打印、消息推送、数据库查询四个完全不同的模块同时间歇性报错。排查半天看不出关联性最后查进程句柄数量早已远超系统阈值才确认是泄露导致的连锁问题。日常开发里句柄泄露的原因大多不是复杂逻辑而是不起眼的编码习惯。读取本地临时文件不关闭流、模板解析后不释放资源、压缩解压操作残留数据流、http请求响应不关闭、第三方工具类内部打开资源不回收。这些代码单次执行毫无问题压测短时间也看不出异常只有长期运行才会暴露。更隐蔽的是一些工具类、开源组件自带的资源泄漏问题。很多人直接引用外部工具包处理Excel、PDF、压缩包、图片解析只调用方法获取结果完全不清楚底层会打开文件流、创建临时资源。组件内部异常时资源关闭逻辑跳过句柄悄悄堆积开发者完全感知不到。还有一种场景是异常分支跳过关闭逻辑。正常流程能顺利关闭资源一旦中途抛出异常程序直接跳出关闭代码没有执行。长期累积下来异常场景越多句柄泄露越严重。这类问题随机性极强完全取决于线上报错频次本地几乎复现不了。很多团队的排查盲区也在这里。日常监控大多只看CPU、内存、磁盘、QPS很少有人监控文件句柄占用数。资源慢慢被耗尽的过程全程无告警等到问题爆发服务已经濒临瘫痪。重启服务能瞬间释放所有句柄问题临时解决但根本原因不动过几天必然复现陷入反复重启的恶性循环。实际上这类问题根治并不难关键在于平时没有建立资源回收的意识。所有流操作、资源打开、外部调用不管正常还是异常都必须保证最终关闭。使用自动关闭的语法、finally兜底、资源池复用都是很简单有效的手段。定时巡检服务器句柄占用提前发现溢出苗头也能避免线上故障。线上稳定性问题很多时候不是来自复杂架构缺陷而是这种日积月累的微小资源泄露。不起眼的代码细节长期累积最终就能拖垮一整个服务。