謹(jǐn)慎使用類變量及正確使用單例模式

2019-11-18 12:13:31

字體：大中小

供稿：網(wǎng)友

CowNew開源團(tuán)隊(duì)網(wǎng)站 http://www.cownew.com
論壇 http://www.cownew.com/newpeng/
轉(zhuǎn)載請注明此版權(quán)信息

        昨天發(fā)現(xiàn)JDBMonitor在多數(shù)據(jù)源的情況下會有問題，這個問題就是對單例模式理解不深造成的。為了減少系統(tǒng)中的對象數(shù)目，我用單例模式設(shè)計(jì)DBLogger，也就是提供一個getLogger方法返回一個日志處理器，getLogger則返回的是一個緩存了的DBLogger實(shí)例。昨天我用一個大型的信息系統(tǒng)測試了一下，發(fā)現(xiàn)當(dāng)有多個數(shù)據(jù)源存在的時候，所有的日志都記錄到了第一個啟動的JDBMonitor的配置文件指定的監(jiān)聽器中了。經(jīng)過分析得知，雖然多個數(shù)據(jù)源啟動了多個JDBMonitor，但是由于這些JDBMonitor實(shí)例是運(yùn)行在同一個JVM中的，而一個類變量在同一個JVM是唯一的，所以這些實(shí)例調(diào)用getLogger的時候得到的都是第一個JDBMonitor中配置的了。
        我采用如下方式解決：為getLogger增加一個connectionId參數(shù)，將原先的單例去掉，改成一個hash表的靜態(tài)變量instanceMap。在調(diào)用getLogger的時候，先以connectionId為key到instanceMap中找是不是已經(jīng)有一個實(shí)例了，假如有則直接返回這個實(shí)例，否則構(gòu)造一個DBLogger，將此DBLogger以connectionId為key保存到instanceMap中，然后返回實(shí)例。
        根據(jù)JDBMonitor的功能特點(diǎn)配置文件的路徑就可以做為這個connectionId了，也就是假如是多個數(shù)據(jù)源指向一個配置文件，那么這幾個數(shù)據(jù)源其實(shí)還是共用一個DBLogger，這個也是合理的，而且也可以節(jié)省很多資源。
        從這個例子我們可以看出，單例模式并不一定是只創(chuàng)建一個實(shí)例這么簡單。Log4j的getLogger就是很好的證實(shí)。
        但是多個數(shù)據(jù)源共用一個DBLogger又引來了另一個問題，就是當(dāng)有一個數(shù)據(jù)源的Connection被close掉以后，DBLogger也會隨之close掉，其他數(shù)據(jù)源再訪問的時候就會報(bào)錯。我采用類似GC、COM等的引用機(jī)制解決此問題。在DBLogger內(nèi)部維護(hù)一個計(jì)數(shù)器refCounter，初始值是0,當(dāng)調(diào)用getLogger訪問到此實(shí)例的時候，就refCounter自動加1，當(dāng)調(diào)用DBLogger的close的時候就自動減1，當(dāng)refCounter降到0的時候就說明沒有對象引用到它了，這個時候再釋放DBLogger中的各種資源。當(dāng)然addRef、releaseRef、close等方法都要標(biāo)識成synchronized的。
        同理，以前的這些channel、dbListeners類變量也要改成實(shí)例變量。consumerthread也要改成實(shí)例變量，在close中再關(guān)閉這個線程。這樣就保證了每一個JDBMonitor都有自己的消費(fèi)者線程。
        為了使語意更加明確，我將getLogger重命名為createLogger。
        代碼已經(jīng)提交到CVS，今天晚些時候?qū)⒋虬诺綀F(tuán)隊(duì)網(wǎng)站上。
        向大家匯報(bào)，SQL解析引擎已經(jīng)有階段成果，強(qiáng)類型AST節(jié)點(diǎn)都已定義完畢，也已經(jīng)可以生成最簡單的CommonAST。

上一篇：關(guān)于23種設(shè)計(jì)模式的有趣見解

下一篇：把業(yè)務(wù)流程從操作中剝離出來