mysql服務(wù)器最近老是報錯，內(nèi)容如下：

The last packet successfully received from the server was 65,502,275 milliseconds ago. The last packet sent successfully to the server was 65,502,276 milliseconds ago. is longer than the server configured value of 'wait_timeout'. You should consider either expiring and/or testing connection validity before use in your application, increasing the server configured values for client timeouts, or using the Connector/J connection property 'autoReconnect=true' to avoid this problem.

主要的意思是：： 數(shù)據(jù)庫有長連接，由于長時間沒有使用，并且空閑時間超過了wait_timeout設(shè)置的時間。 數(shù)據(jù)庫到了wait_timeout設(shè)定的時間，自動釋放了鏈接。

客戶端還有這個長連接，客戶端使用這個長連接向mysql數(shù)據(jù)庫發(fā)送消息，可是這個鏈接數(shù)據(jù)庫服務(wù)器端已經(jīng)釋放了，所以爆出上面的錯誤.

如果你剛好在數(shù)據(jù)庫超時的第一時間內(nèi)看到日志記錄的話那么，第一次超時發(fā)生的錯誤就是這樣的：

ERROR [org.hibernate.util.JDBCExceptionReporter] - Communications link failure

Last packet sent to the server was 0 ms ago.

如果不是第一次超時后執(zhí)行，以后每次報錯就變成嵌套的錯誤了，就是下面這樣：

ERROR [org.hibernate.util.JDBCExceptionReporter] -

No operations allowed after connection closed.Connection was implicitly closed due to underlying exception/error:

解決辦法：由于項目中代碼比較多，查找哪一個長連接沒有釋放很麻煩，過程如下：

（1）查看報錯日志的詳細信息，看關(guān)系到哪一個dao類出現(xiàn)的問題

（2）然后將mysql連接池最大、最小數(shù)據(jù)設(shè)置成3,1.

（3）然后打開3個瀏覽器，進行操作

（4）發(fā)現(xiàn)項目確實很慢，然后詳細看了一下代碼，確實由于一個地方連接池沒有關(guān)系，導(dǎo)致鏈接一直存在，沒有釋放。

更多信息請查看IT技術(shù)專欄