如果你對你的CodeLine還不是非常熟悉，但眼前有一個Urgent的Bug需要你Fix，你可以借助下面的一些小技巧：
1 根據StackTrace，如果有Exception StackTrace錯誤最好定位。有時就算是修復一個看似不相關的Exception,也可能解決你的bug
2 Log. Log中往往有大量的信息，如程序流程，Warning, Error之類的信息。如果遇到多線程問題，尤其要注意Log的線程信息，比如這一條log是線程A打印的，另一條是線程B打印的，這樣對理解線程調度的過程很有幫助，也可以排除大量無關的信息（不是你出錯的線程打印出來的，可以不重點考慮）。Thread.currentThread().getName(),? Thread.currentThread().setName() 可以幫助你編程時得到Thread的名稱。
3 利用Winword定位文件寫操作的代碼。有時程序會自動生成許多文件，如果你懷疑某個文件生成有誤，可以用Word將其打開，然后再運行你的程序，這時寫操作會失敗，你多半可以看到寫操作的StackTrace,也就可以定為這個文件是從哪里來的了。
4 注意查看代碼修改歷史。很多Bug是別人改出來的（Regression). 如果某功能上一個版本上OK，這一個版本出問題了。你就可以查查相關代碼有誰修改過，往往就能找到問題的原因。Winmerge是一個比較好的代碼比對和merge的工具。
5 代碼搜索。你可以利用一些出錯信息，查找代碼來定位錯誤的位置。比如如果你發現日志中有 abc, 你可以搜索一些可能的編程習慣 += "abc" ,? = "abc" ...
6 如果懷疑某個class的classLoader有問題，可以在調試環境中Watch??? ABC.class.getProtectionDomain().getCodeSource() 查看它的class path, 用ABC.class.getClassLoader() 查看它的class loader
7 如果調試web相關的問題，可以用Firefox的Live HTTP headers來查看http協議的header.
8 如果懷疑傳輸格式（如Webservice，IIOP）可以用TCPMon 來攔截TCP傳輸，察看服務器和客戶端之間的交互過程。https://tcpmon.dev.java.net/

最后一點要記住：
一個比較成熟的產品，它的bug往往并不大，都是些微小的地方，如果你的只修了某個地方就把問題解決了，那很好。如果你改了一大堆java文件，才讓產品Work，就要好好想想是不是你沒有找到問題的根本，更重要的是，千萬別引進新的Bug！改不出Bug不是你的錯，改出新的Bug就是你的錯了。