MySQL 連接異常「Too many open files」根因排查與文件句柄泄漏修復實戰

MySQL 連接異常「Too many open files」根因排查與修復實戰

線上系統拋出 Communications link failure，堆疊信息末尾隱藏著關鍵線索：java.net.SocketException: 打開的文件過多。本文記錄從現象到根因的完整排查過程。

異常堆疊關鍵信息

Caused by: com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure
...
Caused by: java.net.SocketException: 打開的文件過多
    at java.net.Socket.createImpl(Socket.java:447)
    at com.mysql.jdbc.StandardSocketFactory.connect(StandardSocketFactory.java:257)
    ...
    at org.apache.commons.dbcp.PoolingDataSource.getConnection(PoolingDataSource.java:106)

誤區與轉折

• 初步判斷：連接池配置不當、連接未關閉、MySQL wait_timeout 導致連接失效
• 關鍵發現：堆疊最底層 SocketException: 打開的文件過多，而非 MySQL 端拒絕連接
• Linux 限制：ulimit -n 默認 1024，進程打開文件句柄超限將無法建立新 Socket 連接

根因定位

經代碼審查發現：某第三方 JAR 包中 InputStream 僅 new 打開，缺少 close() 調用，在高頻循環中反覆打開文件，導致句柄泄漏，最終突破 1024 限制。

修復方案

1. 定位泄漏代碼，補全 try-with-resources 或 finally 中的 close()
2. 驗證修復：壓測確認文件句柄數穩定在合理範圍
3. 系統層面調優（可選）：/etc/security/limits.conf 調大 nofile 限制

預防清單

• 所有 InputStream/OutputStream/Reader/Writer/Socket/Connection 必須顯式關閉
• 優先使用 try-with-resources (Java 7+) 自動管理資源
• 定期檢查 lsof -p 監控句柄數變化趨勢
• 連接池配置 maxTotal、maxIdle 需小於系統文件句柄限制

核心教訓

異常堆疊最底層往往藏著真相。不要被上層業務異常（如 Hibernate/JDBC 封裝）誤導，務必追溯到根因 Cause by 鏈的末端。