几年来定位故障的几大利器

     在最开始入公司的时候，会遇到一些比较麻烦的软件故障；在实在解不开和没有头绪的时间，就去喜欢去问在公司指派的引路师父。他就告诉我，你给我说这个故障时，你看当时的日志没有？我说还没有，他就说你先把日志看看再回来，呵呵，很有大师的风范的。

 

    后来，我想快速解决问题，请教于他，想向他指点迷津的时候，他也总是这样问？！这种学习过程让我也养成了遇到故障，必看日志的习惯。现在来看，这个过程是很锻炼人的，呵呵。后来听一个年长几岁的过来人讲，年轻的几年取不得轻巧的路走，不然能力没有被训练出来，人悠闲惯了，在年轻的的几年就被废掉，就很有可能一辈子无成。后来自己想想是如此的，由勤入懒容易，但是由懒入勤相对就难多了。。。 其实自然界或者不是公平的，或者可以说，在自然界都是公平的，但是对于人类而言，总是存在一些单向的东西，由一个方向向另一个方向容易，但反过来就难多了。

 
   按照我师父的观点，不看日志你就没有办法理解程序当时在做什么，更是对这个故障没有初步的把握。这几年下来，我对看日志这种定位故障的方式，更深入一点的发展是：当你看日志觉得信息量不足时，那么就是你要补充日志的时候了：）

 

   除了看日志这种基本功，对于我定位故障这几年的心得，还要包括程序调试、网络抓包、堆栈、查看系统状态(内存、文件、Socket资源)等都是不可缺少的手段。不管怎么样，就是要竭尽一切方式知晓当时发生了什么，你就会定位得更准确的。

 

    另外，关于正常情况和异常情况的对比，以比对的手法来定位故障也是非常有效的。当所有的信息充满错误的情况下，你的思维和景象会很混乱，这时唯有正确的逻辑能救你一把了，呵呵！

  

   对于linux java程序获取其堆栈信息，可以通过 kill -3来实现
refer to:http://java.sun.com/developer/technicalArticles/Programming/linux/
Generating a Java stack trace on Linux
As you learned in the section on threads, Linux threads are implemented as Linux processes. This makes debugging Java programs running on Linux a little different. To generate a stack trace from the terminal window where you started your application, you only need to type the sequence <CTRL>/ to send the QUIT signal to generate a stack trace. However, if you need to generate a stack trace from a Java application already running in the background, you need to send QUIT or signal number 3 to the launcher process ID. The launcher process in this example is process ID 11667. The stack trace can be generated by sending the signal via the kill command as follows:

kill -3 11667
The resulting stack trace will be a snapshot of the Java threads in the main threads which details the state of each thread. This information can be used to track down deadlocks or busy sections in your application. For more details on analyzing Java stack traces, refer to the Debugging Applets, Applications, and Servlets chapter in Advanced Programming for the Java 2 Platform (Addison-Wesley, 2000).