IT项目研发过程中的利器
“工欲善其事必先利其器”，这是我写这个系列的主要原因。（转载请指明出于breaksoftware的csdn博客）
在进入这个系列之前，我们先看下大概在十几年前的一个段子：
“我”win98系统崩溃了，需要重装，但是没有系统盘。于是“我”找了一个大牛。他找我要了一个连着电话线的座机，把电话线一端插在电脑上。他在另一端的座机上不停按着0或1。过了一段时间win98系统被他装上了。 后来进入xp时代，由于又要装系统。此时DVD已经普及了，但是仍然没有系统盘。于是我又找了一个大牛。他找“我”要了一个空的光盘和一根针，然后飞速的用针在光盘上戳。过了一段时间他刻出了一个可用的xp系统盘。 再后来，“我”的D盘数据没了（可能当时只推出到XP系统，“不知有汉，无论魏晋”）。于是“我”又找了一个大牛，告知他D盘上有某知名作品。于是这个大牛找“我”要了一个磁铁，然后把硬盘拆下来。他用磁铁在硬盘上不停的画圈。过了一段时间，“我”硬盘上的数据恢复了。 如果对计算机不太了解的人来说，应该看不出那种“信服”的感觉。当时年少无知，还把这段子当成真的，还佩服了很久。这个段子其实还是包含了很多道理的。比如计算机的本质就是高低电位（0/1），再比如机械硬盘写入操作就是磁头磁化盘片的过程。所以我当时还是很崇拜这三位“大牛”。 但是通过这个例子，我们还看到“大牛”成为“传奇”的三个工具——电话座机、针、磁铁。如果没有这三个“利器”，大牛应该没法展现出超凡的能力。 在“传说”之外，我们工作中，也是需要不同的利器，同时“站在巨人的肩膀上”，才能让我们达到事倍功半的效果。 本系列就将探讨一系列利器的使用方法。我并没打算写一个“大而全”的百科，也不会将每个工具的所有知识点都罗列出来。因为有些工具在设计时可能距离现在有一定时间了，有些功能随着技术的更新而变得不实用，或者相关联的技术已经不再维护或者不再可用，导致一些功能被阉割。正如这个系列标题所言，这些文章注重的是“使用”，所以它们只会覆盖主要的方面。 然而这个系列要写哪些“利器”我还没决定好，所以这段文字只能算是一个前言。未来，我将完成的各种工具相关文章，以目录条目的形式引入本文。
阅读理解
工作中，我们难免会接手一些其他组的项目，或者要使用一些开源项目。一般来说，如果没有详细的文档，理解这些项目还是有一定难度。这个时候只能自己一点一点的抠代码了。而对于代码量有点大，或者调用比较复杂的项目，如果我们可以使用一些工具，自动分析出一些脉络供我们分析怎么阅读，可能会让阅读理解过程变得有规章。
阅读理解可以分为两种，一种是静态分析，一种是动态分析。静态分析是一个比较简单的过程，它不需要我们把程序执行起来，而只是通过源码或者编译结果进行分析。通过源码分析往往存在一些缺陷，但是它要求最低。我们先看下两个自动生成Ｃ语言代码中函数调用关系的工具的使用方法。
《静态分析C语言生成函数调用关系的利器——calltree》
《静态分析C语言生成函数调用关系的利器——cflow》
代码编译
由于种种原因，我们不能修改一些代码文件。然而我们又必须修改它们，这个时候给代码“打补丁”的方案可以帮我们做到这点
《代码打补丁的利器——diff和patch》
锁问题分析
《互斥量、读写锁长占时分析的利器——valgrind的DRD》
《死锁问题分析的利器——valgrind的DRD和Helgrind》
性能瓶颈分析
当我们发现自己的程序性能不如意时，可能会采用打日志的方式进行分析。但是这种方式有很大的弊端，比如分析问题过程冗长。此时我们可以考虑借助其他工具。
《动态执行流程分析和性能瓶颈分析的利器——valgraind的callgrind》
《动态执行流程分析和性能瓶颈分析的利器——gperftools的Cpu Profiler》
如果需要测试程序在不同个数的逻辑核心上运行的效率，除了修改代码，我们还可以考虑使用settask工具。
《绑定CPU逻辑核心的利器——taskset》
内存问题分析
内存问题的定位一般比较棘手，但是在强大的工具面前，很多问题不再困难。
《内存问题分析的利器——valgraind的memcheck》
《堆问题分析的利器——valgraind的massif》
《堆状态分析的利器——valgraind的DHAT》
《内存泄漏分析的利器——gperftools的Heap Checker》
《堆状态分析的利器——gperftools的Heap Profiler》
《数据竞争（data race）问题分析的利器——valgrind的Helgrind》
未完待续。