方亮的专栏

1、5、15分钟值基本相等，说明系统稳定运行；哪个值和其他值对比出现偏离，说明产生了变化。1分钟偏离，说明系统在变忙碌（值大），或者变空闲（值小）。5分钟偏离，说明中期系统出现抖动。15分钟偏离，说明系统在变空闲（值大），或者变忙碌（值小）。一般只要出现非平稳状态，就要定位原因，否则就是隐患。

当我们拿到一个比较大的项目源码时，往往需要总览代码的结构，理清脉络，发现核心点。如果没有前人给出的经验，我们该如何找到关键的函数和模块呢？这个时候我们就可以借助一些工具来生成“调用图”（Call Graph）。图中函数和模块的连线比较多，说明其被使用的很多，需要重点关注；图中函数和模块位于很多调用栈中，说明该函数是有关“脉络”的信息，也要重点关注。比如event_add被连接很多，说明被使用的地方很多，需要重点关注；

perf是一套linux操作系统上分析工具集，分析函数调用关系只是其一个子集功能。它并不像中介绍的需要在被分析程序的编译指令中插入新的选项（-pg），而是直接对原始编译结果进行分析。

gprof是一个C语言程序性能分析工具。在编译期间，我们给编译指令增加-pg选项，就可以将检测代码插入到源码中。然后使用gprof启动编译程序，它会收集程序运行的流程以及其他相关数据。最后我们使用gprof2dot将这些数据转换成dot文件，使用graphviz进行图形化展示。以中的libevent为例。

不同于之前分析C语言项目的工具，go-callvis还是很方便使用。只要把两项工作做好就能顺利的使用。我的测试环境是Ubuntu 22 TLS版，默认的Golang是1.18。这会导致go-callvis安装失败。如果版本匹配，可以忽略下面Golang升级的步骤。安装新版本直接上1.21版本。配置环境变量在文件末尾另起新行填入以下内容载入环境修改当前环境修改之后进入的环境在文件末尾另起一行新增分析我们以gorush的源码为例。它是一套基于Gin实现的消息推送框架。安装go-cal

Analizo是一款可以给C、C++、Java以及C#代码进行评分的开源软件。我们可以使用它来分析代码，并得到如下指标的评分这些评分是我们评价代码质量和可维护性的一种依据。比如Average Cyclomatic Complexity per Method (ACCM) metric，即平均圈复杂度。这是1976年由Thomas J. McCabe, Sr. 提出来的一种代码复杂度的衡量标准。它的算法也很简单，即其中e是边数量，n是节点数量。

在中我们介绍了如何使用GCC生成RTL文件，然后再借助cally和egypt来分析出调用关系的方法。GCC自身有命令可以生成代码内部的调用关系，即-fcallgraph-info参数。它会生成后缀是ci的VCG格式文件。然后我们使用graph-easy将其转换为dot格式，最后使用graphviz将其绘制出来。我们还是以libevent的为例。

我们看下test-time.c的部分源码。可以看到egypt的展现更加准确，因为它将time_cb和main进行了关联，而cally则没展现出来这层关系。called++;for (i = 0;i < 10;i < NEVENT;i++) {} else {我们看到上面图片并没有展现诸如event_add这类外部函数的底层调用栈。

这类错误主要是符号类型错误，我们只要加入相关指令即可，修改如下执行完会报这个错：找不到event2这个文件夹下的event-config.h。经过寻找，这个文件并不存在。这说明该文件是在编译时生成的。

目前团队并没有QA岗，而且在很长一段时间内，可能也不会设立QA岗，所以我们需要RD保证代码的质量。而鉴于人类天生的“惰性”，很多时候质量完全依赖于作者的能力以及职业素质。于是我在团队内推动单元测试，并要求提升测试覆盖率。虽然单元测试不能“根治”bug，但是它可以驱使代码结构简洁可测，为提升测试代码覆盖率奠定基础，从而可以有效降低bug率。（转载请指明出于breaksoftware的csdn博客） 以下我将以工作中一个实际例子讲解如何将一个不可测代码变成更加合理且可测代码。...

数据竞争（data race）是指在非线程安全的情况下，多线程对同一个地址空间进行写操作。一般来说，我们都会通过线程同步方法来保证数据的安全，比如采用互斥量或者读写锁。但是由于某些笔误或者设计的缺陷，还是存在data race的可能性的。（转载请指明出于breaksoftware的csdn博客） 比如下面这段代码#define _GNU_SOURCE 1...

在《DllMain中不当操作导致死锁问题的分析--死锁介绍》一文中，我们介绍了死锁产生的原因。一般来说，如果我们对线程同步技术掌握不牢，或者同步方案混乱，极容易导致死锁。本文我们将介绍如何使用valgrind排查死锁问题。（转载请指明出于breaksoftware的csdn博客） 构造一个场景#include &lt;pthread.h&gt;pthre...

在进行多线程编程时，我们可能会存在同时操作（读、写）同一份内存的可能性。为了保证数据的正确性，我们往往会使用互斥量、读写锁等同步方法。（转载请指明出于breaksoftware的csdn博客） 互斥量的用法如下 pthread_mutex_lock(&amp;mutex); // do something pthread_mutex_unlock(...

在《动态执行流程分析和性能瓶颈分析的利器——valgraind的callgrind》中，我们领略了valgrind对流程和性能瓶颈分析的强大能力。本文将介绍拥有相似能力的gperftools的Cpu Profiler。（转载请指明出于breaksoftware的csdn博客） 我们依然以callgrind一文中的例子为例#include &lt;thread...

当项目中引入了一些第三方或者开源库时，如果没有详细的文档说明，我们往往有种“盲人摸象”的感觉。如果只是简单的使用还好，但是这些代码需要被定制时，就需要深入阅读理解其实现。这个时候又往往有种“无从入手”的感觉。特别是对一些大型的项目，管理者往往需要划分出不同模块交由下属去理解，于是划分的依据是什么？如果没有一个总体统筹的认识，很多工作都无法开展下去。本文将探讨的工具将协助我们解决这些...

“工欲善其事必先利其器”，这是我写这个系列的主要原因。（转载请指明出于breaksoftware的csdn博客） 在进入这个系列之前，我们先看下大概在十几年前的一个段子： “我”win98系统崩溃了，需要重装，但是没有系统盘。于是“我”找了一个大牛。他找我要了一个连着电话线的座机，把电话线一端插在电脑上。他在另一端的座机上不停按着0...

在工作中，我们可能遇到这样的需求：如何评估程序在一核和多核下的工作效率差距？最简单的想法是找一台只有一个CPU逻辑核的机器和一台有多个逻辑核的机器。（转载请指明出于breaksoftware的csdn博客）但是这种方式有明显的问题：不容易找到这样的机器。 找到的机器不能保证其他配置一致，比如CPU主频。 找的的机器不能保证环境一致，比如操作系统或者运行中的其他程序。 ...

一般来说，如果我们在研发过程中需要对代码进行修改，是不需要通过打补丁的方式的，因为我们可以直接改动文件即可。但是如果针对一款要上线的产品，我们总不能在研发的电脑上编译通过后直接发布到线上的。（转载请指明出于breaksoftware的csdn博客）因为这样做有很多缺陷：最后负责编译的同事，可能忘记提交最终的代码。这样代码库中的代码逻辑和线上运行的产品逻辑将存在差异。 最后负责...

在《内存、性能问题分析的利器——valgraind》一文中我们简单介绍了下valgrind工具集，本文将使用callgrind工具进行动态执行流程分析和性能瓶颈分析。（转载请指明出于breaksoftware的csdn博客） 之前的《利器》系列中，我们介绍了两种静态分析函数调用关系的工具（《静态分析C语言生成函数调用关系的利器——calltree》和《静态分析C语...

在《内存、性能问题分析的利器——valgraind》一文中我们简单介绍了下valgrind工具集，本文将使用memcheck工具分析各种内存问题。（转载请指明出于breaksoftware的csdn博客） 本文所有的代码都是使用g++ -O0 -g mem_error.c -o mem_erro编译；分析都是使用valgrind --tool=memcheck ./m...

valgrind是一个知名的分析软件集。我们可以使用它进行内存、多线程及性能等各种问题的分析。它采用非侵入方式，所谓非侵入方式是指：我们不用在代码中插入分析工具的库。这对于开发者来说是友好的。因为如果要将工具编译到文件中，或者要调用其提供的一些API，才能进行问题分析，无疑增大了用户的学习和使用成本。（转载请指明出于breaksoftware的csdn博客）valgrind ...

堆问题也是内存问题的一部分。如果我们发现程序内存一直在增加，怀疑是内存泄漏，则可以使用《内存问题分析的利器——valgrind的memcheck》一文中介绍的“内存泄露”方法去分析定位。当然我们还可以使用本文介绍的工具——massif。（转载请指明出于breaksoftware的csdn博客） 以下代码为例#include &lt;stdlib.h&gt;...

在《堆问题分析的利器——valgraind的massif》一文中，我们介绍了如何使用massif查看和分析堆分配/释放的问题。但是除了申请和释放，堆空间还有其他问题，比如堆空间的使用率、使用周期等。通过分析这些问题，我们可以对程序代码进行优化以提高性能。本文介绍的工具DHAT——dynamic heap analysis tool就是分析这些问题的利器。（转载请指明出于breaks...

在《内存泄漏分析的利器——gperftools的Heap Checker》一文中，我们介绍了如何使用gperftools分析内存泄漏。本文将介绍其另一个强大的工具——Heap Profiler去分析堆的变化过程。（转载请指明出于breaksoftware的csdn博客） 我们使用类似于《堆状态分析的利器——valgraind的DHAT》中的测试代码作为例子。为了让...

在《内存问题分析的利器——valgraind的memcheck》一文中，我们介绍了如何使用valgrind分析各种内存问题。valgrind是基于模拟器的技术实现，而本文介绍的gperftools则是通过在用户代码中嵌入检测代码实现的。（转载请指明出于breaksoftware的csdn博客） 先介绍下gperftools的编译安装。 首先下载安...

除了《静态分析C语言生成函数调用关系的利器——calltree》一文中介绍的calltree，我们还可以借助cflow辅助我们阅读理解代码。（转载请指明出于breaksoftware的csdn博客）cflow的说明和安装 cflow是一款静态分析C语言代码的工具，通过它可以生成函数的调用关系。和calltree不一样，cflow有独立的网页介绍它（https://ww...