TA貢獻1788條經(jīng)驗 獲得超4個贊
DB 將盡最大努力進行檢測，但如果沒有運氣，它可能無法檢測到。最好盡快發(fā)布獲得的東西。
send() 系統(tǒng)調(diào)用將等待 TCP 連接發(fā)送數(shù)據(jù)，但客戶端不會收到任何內(nèi)容。
沒有正確釋放資源，發(fā)生斷電、網(wǎng)絡(luò)問題或裸退出。TCP keepalive 機制將啟動并嘗試檢測連接已死。
客戶端暫停，沒有收到任何數(shù)據(jù)，在這種情況下send()會阻塞。
因此，它可能會阻止
正常關(guān)閉集群。
如果將排他鎖作為事務(wù)的一部分（例如auto vacuum在 postgresql 中），則推進事件視界。
可以縮短服務(wù)器 keepalive 配置以更早地檢測到它。（例如，~2h 12m根據(jù)工作負載，postgresql 中的默認值會很長）。
最大打開連接數(shù)可能有硬性限制，直到檢測到，一些連接將成為僵尸（在那里，無法使用但會降低限制）。
TA貢獻1893條經(jīng)驗 獲得超10個贊
數(shù)據(jù)庫會注意到連接已經(jīng)死亡并采取適當(dāng)?shù)拇胧豪?，該連接上所有未提交的活動事務(wù)將被回滾，用戶會話將被終止。
但是請注意，從數(shù)據(jù)庫引擎的角度來看，這是一個“恢復(fù)”場景：它不能在客戶端斷開連接時就拋出；它必須采取明確的行動來保持一致的狀態(tài)。
另一方面，當(dāng)程序以“正常方式”（即，不是因為恐慌或log.Fatal()）關(guān)閉時關(guān)閉屬性真的沒有那么難。由于sql.DB實例通常是一個程序范圍的全局變量，它甚至更簡單：只需main()像馬特建議的那樣嘗試關(guān)閉它。
TA貢獻1886條經(jīng)驗 獲得超2個贊
如果您在任何函數(shù)中初始化連接，通常最好推遲調(diào)用以立即關(guān)閉，即
conn := sql.Connect() // for example defer conn.Close()
一旦封閉函數(shù)退出，這將關(guān)閉連接。
這在main函數(shù)中使用時很方便，因為一旦程序退出，Close()就會調(diào)用。
舉報