摘要: A項(xiàng)目一開始code的時(shí)候,沒有加任何test。現(xiàn)在需要重構(gòu)了,我們根據(jù)use case設(shè)計(jì)了一些automation的high level 的接近integration test的functional tests. 但跑下來發(fā)現(xiàn)code coverage不高。于是老大讓我看看想些方法提高一下code coverage。總結(jié)一下。 閱讀全文
J2SE and JVM
java core and JVM
摘要: 在一個(gè)月黑風(fēng)高的晚上,產(chǎn)品環(huán)境上所有application都OOM了,令人心驚膽寒,打開log文件,上下打諒著他,他就是傳說中的“java.lang.OutOfMemoryError: unable to create new native thread‘,到底誰創(chuàng)造出了這個(gè)魔鬼,原來一個(gè)application在瘋狂創(chuàng)建線程池,不過用TDA(Thread dump analyzer)看到也就只創(chuàng)建了400×2(2JVMs)個(gè)線程,但這并不算多,應(yīng)該還可以更多。奇怪!讓我們來剝下“java.lang.OutOfMemoryError: unable to create new native thread‘的外衣,看看誰是幕后黑手。。。。。 閱讀全文
摘要: 通過Context lookup出來的是DataSource卻能完成XADataSource的功能,雖然用了動(dòng)態(tài)代理,但是為什么不用繼承呢? 閱讀全文
摘要: 原有的應(yīng)用沒有開放RMI服務(wù),由于將schedule模塊移到了standalone的JVM上,需要在遠(yuǎn)程通過RPC Call回來,于是在已有的系統(tǒng)中增加了RMI服務(wù),關(guān)鍵是如何方便而有效地加入這個(gè)RMI服務(wù),和原有的系統(tǒng)解耦,還要方便以后的升級(jí)。這篇隨便記錄了在已有系統(tǒng)中加入RMI服務(wù)模塊的一些心得。 閱讀全文
摘要: 在java端調(diào)用存儲(chǔ)過程的時(shí)候需要存儲(chǔ)過程串行的執(zhí)行,如果使用synchronized lock在應(yīng)用服務(wù)器突然down掉的情況下會(huì)出現(xiàn)問題,因?yàn)閟ession并沒有立即斷掉,后臺(tái)的存儲(chǔ)過程還在繼續(xù)執(zhí)行,這樣如果應(yīng)用服務(wù)器立即重啟,再調(diào)用該存儲(chǔ)過程或者其他需要一起串行化處理的存儲(chǔ)過程就會(huì)違反同步執(zhí)行的原則,所以我們必須把鎖放在oracle db端,利用oracle鎖機(jī)制來完成存儲(chǔ)過程的同步,文章總結(jié)了一下在java端如何使用oracle這個(gè)用戶鎖機(jī)制。 閱讀全文
摘要: 最近要寫message在傳送過程中狀態(tài)改變的流程,并根據(jù)不同的狀態(tài)作不同的處理,同時(shí)記錄當(dāng)前的狀態(tài)。于是,看了一下狀態(tài)模式,發(fā)現(xiàn)還是不太好用,比如狀態(tài)對(duì)象創(chuàng)建的太多了,稍加修改了一下,大概是就是文章中的這個(gè)模樣了:把它分為了“狀態(tài)持有者”, “狀態(tài)對(duì)象“, ”狀態(tài)管理者”, “狀態(tài)機(jī)”等。 閱讀全文
摘要: 《Head First Design Pattern》一書在講單例模式時(shí)舉了一個(gè)double check的例子,覺得它的代碼寫的有問題,修改了一下它的代碼,不知道正確與否,大家討論。討論的結(jié)果兩種寫法在舊的JMM上都是錯(cuò)的,在新的JMM上都是正確的,文中添加了一些個(gè)人的理解。 閱讀全文
摘要: 因?yàn)閘og對(duì)象常常不需要序列化,我們?nèi)绾卧诳尚蛄谢愔卸xlog對(duì)象? 閱讀全文
摘要: 用ASM直接分析字節(jié)碼來加載Class級(jí)別的Annotation。文中給出了一個(gè)例子,例子的主程序會(huì)加載用某個(gè)Annotation標(biāo)注的class,而那些沒有被該Annotation標(biāo)注的class就不會(huì)被加載。 閱讀全文
摘要: 總結(jié)了有幾種方法編寫自定義Annotation 閱讀全文