性能分析之调试工具——GDB之一（你以为性能分析中用不到吗？)

前几天碰到一个redis的问题。

说复杂倒也不复杂，但是我想在重现的时候下载了redis的源码，编译什么的折腾了一遍。

在这个过程中，也用到了调试工具GDB。

我以为这个工具早就写过了文章了，结果一查自己公众号，居然没有。

（我现在已经有了一个习惯，在碰到性能分析方面不会的时候，先查自己的公众号和自己的笔记，一般都会找到答案。）

先看一个例子吧：

真是人越老，越觉得helloword示例的好处。直观又简单。

GDB是一个老牌的调试工具。

上面的示例中，我写了一个死循环的代码，左边窗口执行，右边窗口调试。

之前经常看到有人用GDB调试coredump文件。

当然gdb也可以调试正在运行中的程序，不过这里有前提，就是编译时加上-g的参数。

通过attach连进去之后，可以做很多动作，不过要知道attach的同时也会导致运行中的程序暂停。要想接着运行，就输入c（continue）。

GDB的调试要求是个静态的状态。

当然现在也有很多动态调试的手段了，后面如果有需要我也接着写一下。

attach之后，可以看线程信息info threads。

输入bt是查看当前程序运行到了哪里。

调试coredump文件的好处是，程序已经crash了，这时直接bt就知道crash在了什么地方。但是同样也是需要在编译时加上-g的参数的。

另外，调试会要求系统中有debuginfo的支持。这个版本一定要和系统内核版本对应，不然是不可用的。

gdb支持设置断点、观察点、捕捉点。还有查看堆栈、运行时数据、源代码等等好使的命令。

本来想着能写很多示例命令的，可是写着写着，又觉得那样像在写操作手册。

而操作手册已经很多了，所以还是算了，如果有人觉得有兴趣，我再根据读者的要求写相应的示例。

我们在性能分析中经常用的的场景是：

1. 就是查看断在了什么地方，然后跟着堆栈去找代码。
2. 设置断点在某个函数或变量上，执行程序，当断点命中的时候，查看堆栈信息。

后面也写一下动态调试工具，像systemtap之类的。

性能分析的过程中经常会用到一些看似不是性能工程师的技术所需的工具，我经常会听到有些做性能的人觉得这不是自己应该做的。还是按我以前的观点，职位可以受限，但是能力不要给自己设限。

但是，也不要学偏了，技术需要有一条主线，所有的能力都会主线服务，不然不知道你要干吗了。

调试方面的可以看张银奎大师的相关书籍。我也经常向张大师讨教些技术问题，他的功底那是相当的强悍。

我在有些客户那里做培训时，有时提到调试也会提起他，给他做些软广告。有些客户说，嗯，他也来这里培训过，调试确实讲的挺好。

再回到说性能分析。经常有些初学者或者有些经验的人，在跟测试工具纠结较劲。

今天一早，有人问我会不会locust？我一听，这是要考我的意思呀，赶紧说，以前用过，但是不敢说太熟悉。后一句问：现在当学习性能，不知道选择什么工具。松了一大口气，原来是这。于是我说，不用纠结，选择一个用就行了。

在性能领域中，要说工具的功能比较全面的。当loadrunner/jmeter莫属了。要学习的话，其他的工具不用考虑。这两工具如果精通的话，其他的压力工具也就是半天一天的事情。

另外，在性能领域中，确实没有什么是一个人肯定会的。学一招吃一生的可能性是没有的。

我浪荡江湖这么多年，碰到新问题，也只能跟人说，让我先看一眼，太难了可能我解决不了。

可是浪的多了，总会有些常见的，这就是经验的累积了。

哎呀，我不是要写GDB的吗？怎么跑题了。

后面应看官的要求再补上更多的技术文章吧。