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