如果你对你的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就是你的错了。