CowNew開源團隊網(wǎng)站 http://www.cownew.com
作者 楊中科 是CowNew開源團隊JDBMonitor開發(fā)組的開發(fā)人員，郵箱about521? at 163 dot com
論壇 http://www.cownew.com/newpeng/
轉(zhuǎn)載請注明此版權(quán)信息
以前我一直是用使用數(shù)據(jù)源的系統(tǒng)測試JDBMonitor，昨天我準備把JDBMonitor嵌入到一個小的jsp留言板中，這個留言板寫的非常簡單，數(shù)據(jù)庫操作也是connection隨取隨用、用完了就關(guān)這種最簡單的形式，這倒是幫助我發(fā)現(xiàn)了一個超級大bug。
在記事本運行中常常不規(guī)律的DataBaseDBListener的logSQL方法報空指針錯誤，是在logStatement.setString(1, randomGUID.toString());這一句拋出的，我跟蹤到mysql驅(qū)動的內(nèi)部（我使用的是mysql數(shù)據(jù)庫做DataBaseDBListener的輸出數(shù)據(jù)庫），發(fā)現(xiàn)在setString的實現(xiàn)中會去調(diào)用connection的方法，而此時connection已經(jīng)是null了，所以會報空指針錯誤。
從其不規(guī)律的特點我判斷出應(yīng)該是多線程導(dǎo)致的問題。我跟蹤發(fā)現(xiàn)，有的時候是先調(diào)用DataBaseDBListener的close后logSql才被調(diào)用。經(jīng)過分析找出了問題所在，問題就在DBLogger中內(nèi)部類LogConsumer的startConsumer方法，這個是修改以前的代碼：
for (;;)
?{
??SQLInfo info = (SQLInfo) channel.take();????
??if(info==null)
??{
???ontinue;
??}
??for (int i = 0, n = dbListeners.length; i < n; i++)
??{
???dbListeners[i].logSql(info);
??}
?}
在調(diào)用channel.take()以后，這個SQLInfo就從channel中去除了。這時如果DBLogger的方法被調(diào)用，那么即使dbListeners[i].logSql(info)仍然在運行，但是DBLogger會認為channel已經(jīng)空了，所有的dbListeners都可以被close了，而在DataBaseDBListener的close方法中會把輸出目標數(shù)據(jù)庫connection關(guān)掉，那么此時如果DataBaseDBListener的logSql方法還在調(diào)用的話，那么一旦使用這個connection，那么就會出現(xiàn)錯誤了。
我是如下修改的：
修改BlockedChannel類，去掉其take方法，增加一個peek方法和一個remove方法，peek方法是從channel中查出一個對象，但是不把它從channel中移走，只有調(diào)用remove方法后才會被移走。
修改DBLogger中內(nèi)部類LogConsumer的startConsumer方法為如下：
for (;;)
?{
??SQLInfo info = (SQLInfo) channel.peek();
??if(info==null)
??{
???continue;
??}
??for (int i = 0, n = dbListeners.length; i < n; i++)
??{
???dbListeners[i].logSql(info);
??}
??channel.remove(info);
?}
也就是只有SQLInfo被處理完了，才會從channel中移走。
看來JDBMonitor還是要多多測試多多驗證，我近期準備對JDBMonitor進行性能測試，看看有沒有并發(fā)問題有沒有性能問題，不要再急著加新功能了，把這些基礎(chǔ)的功能做好再說，否則別人用著用著就出現(xiàn)中斷性錯誤了，那將會是比缺少功能更可怕的事情。一位同事曾經(jīng)說過一句話：“做的越多錯的越多。不要你做的多好，只要把已經(jīng)做完的東西做的更好就可以了。”，看來確實有一定道理呀。把基本的東西做好再說，否則被人罵不專業(yè)就慘了。