我想覆蓋連接接口中的一些方法，以便在調(diào)用連接對(duì)象上的提交時(shí)關(guān)閉 preparedStatements 和 resultSets。我的代碼庫(kù)中有很多資源泄漏，作為故障保護(hù)，我想實(shí)現(xiàn)這個(gè)解決方案，在每次提交時(shí)，我都可以查找所有打開的語(yǔ)句和結(jié)果集并關(guān)閉它們。但是，在這種情況下，我沒有一個(gè)類可以在所有其他方法上覆蓋和調(diào)用 super() 。作為連接返回的對(duì)象是動(dòng)態(tài)代理 - com.sun.proxy.$Proxy。不確定如何為這個(gè)對(duì)象調(diào)用我自己的方法。任何線索都受到高度贊賞。PS：我在項(xiàng)目中使用的是ojdbc8的jar，是最近從ojdbc7升級(jí)而來(lái)的。據(jù)我所知，我們?cè)谝郧暗陌姹局袕奈从龅竭^任何資源泄漏問題（例如超出最大打開游標(biāo)數(shù)）。
2 回答
肥皂起泡泡
TA貢獻(xiàn)1829條經(jīng)驗(yàn) 獲得超6個(gè)贊
您的 JDBC 庫(kù)是開源的嗎？然后下載 JDBC 版本的源代碼，更改這一代碼，再次生成 JAR 并使用它。當(dāng)您這樣做時(shí)，問題是代碼中的所有“關(guān)閉”調(diào)用不再是合法的關(guān)閉類，而是冗余調(diào)用，在這種情況下，我不知道 JDBC 是否會(huì)再拋出一個(gè)異常（類似于'連接已經(jīng)關(guān)閉'）或沒有，但如果是，你需要抑制異?；蚱渌麞|西。
但這里的基本思想是您正在修改源代碼，這是有風(fēng)險(xiǎn)的。
現(xiàn)在，即使你找到了一個(gè)通用的修復(fù)，下一個(gè)問題是關(guān)于影響的，包括你在內(nèi)的任何人都不能說出這個(gè)的影響，其他人應(yīng)該批準(zhǔn)這個(gè)改變（假設(shè)這是一個(gè)大代碼并且是某個(gè)項(xiàng)目）。
因此，與其做這樣的事情并引發(fā)新問題，不如接受這樣一個(gè)事實(shí)，即過去有人做過一些糟糕的工作，我們現(xiàn)在以正確的方式解決它。
我知道這正是您在這里要避免的，那么我認(rèn)為您應(yīng)該嘗試修改 JDBC 源并試一試。一切順利！
MMTTMM
TA貢獻(xiàn)1869條經(jīng)驗(yàn) 獲得超4個(gè)贊
如果您只是想查找泄漏，為什么不改用調(diào)試器呢？您可以在每個(gè)相關(guān)方法上設(shè)置斷點(diǎn)并查看調(diào)用它們的位置，然后繼續(xù)檢查以確保它們已正確關(guān)閉。作為一個(gè)額外的好處，如果有任何邊緣情況阻止正確關(guān)閉，您將只是單步執(zhí)行相關(guān)代碼，因此您可以更快地找出需要修復(fù)的內(nèi)容。
添加回答
舉報(bào)
0/150
提交
取消