“工欲善其事必先利其器”,这是我写这个系列的主要原因。(转载请指明出于breaksoftware的csdn博客)
在进入这个系列之前,我们先看下大概在十几年前的一个段子:
“我”win98系统崩溃了,需要重装,但是没有系统盘。于是“我”找了一个大牛。他找我要了一个连着电话线的座机,把电话线一端插在电脑上。他在另一端的座机上不停按着0或1。过了一段时间win98系统被他装上了。 后来进入xp时代,由于又要装系统。此时DVD已经普及了,但是仍然没有系统盘。于是我又找了一个大牛。他找“我”要了一个空的光盘和一根针,然后飞速的用针在光盘上戳。过了一段时间他刻出了一个可用的xp系统盘。 再后来,“我”的D盘数据没了(可能当时只推出到XP系统,“不知有汉,无论魏晋”)。于是“我”又找了一个大牛,告知他D盘上有某知名作品。于是这个大牛找“我”要了一个磁铁,然后把硬盘拆下来。他用磁铁在硬盘上不停的画圈。过了一段时间,“我”硬盘上的数据恢复了。 如果对计算机不太了解的人来说,应该看不出那种“信服”的感觉。当时年少无知,还把这段子当成真的,还佩服了很久。这个段子其实还是包含了很多道理的。比如计算机的本质就是高低电位(0/1),再比如机械硬盘写入操作就是磁头磁化盘片的过程。所以我当时还是很崇拜这三位“大牛”。 但是通过这个例子,我们还看到“大牛”成为“传奇”的三个工具——电话座机、针、磁铁。如果没有这三个“利器”,大牛应该没法展现出超凡的能力。 在“传说”之外,我们工作中,也是需要不同的利器,同时“站在巨人的肩膀上”,才能让我们达到事倍功半的效果。 本系列就将探讨一系列利器的使用方法。我并没打算写一个“大而全”的百科,也不会将每个工具的所有知识点都罗列出来。因为有些工具在设计时可能距离现在有一定时间了,有些功能随着技术的更新而变得不实用,或者相关联的技术已经不再维护或者不再可用,导致一些功能被阉割。正如这个系列标题所言,这些文章注重的是“使用”,所以它们只会覆盖主要的方面。 然而这个系列要写哪些“利器”我还没决定好,所以这段文字只能算是一个前言。未来,我将完成的各种工具相关文章,以目录条目的形式引入本文。
工作中,我们难免会接手一些其他组的项目,或者要使用一些开源项目。一般来说,如果没有详细的文档,理解这些项目还是有一定难度。这个时候只能自己一点一点的抠代码了。而对于代码量有点大,或者调用比较复杂的项目,如果我们可以使用一些工具,自动分析出一些脉络供我们分析怎么阅读,可能会让阅读理解过程变得有规章。
阅读理解可以分为两种,一种是静态分析,一种是动态分析。静态分析是一个比较简单的过程,它不需要我们把程序执行起来,而只是通过源码或者编译结果进行分析。通过源码分析往往存在一些缺陷,但是它要求最低。我们先看下两个自动生成C语言代码中函数调用关系的工具的使用方法。
《静态分析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》
未完待续。