← 返回

tutorial openresty-xray go cpu profiling regex flame-graph

Go 高 CPU 占用：正则表达式编译消耗了 36.8% 的 CPU 时间

章亦春发布于 Aug 23, 2023 更新于 Aug 24, 2026

用时 5 分钟

阅读次数

当一个 Go 进程把 CPU 核心占到 100% 以上时，原因通常是某条热代码路径在疯狂消耗 CPU。我们用 OpenResty XRay 剖析了一个正在运行、未经修改的 Go 聊天服务，将它的高 CPU 占用定位到了正则表达式编译——标准 regexp 库中的函数（由业务函数 CheckMessage 在 prev_processor.go 第 17 行调用）占用了 36.8% 的 CPU 时间。编译正则表达式开销很大，应尽量避免在热代码路径中进行。

本文完整展示整个剖析过程——无需修改代码、无需重启——从观察 Go 的高 CPU 占用，到定位到具体的源文件和行号。

观察 Go 进程的高 CPU 占用

运行 top 命令，可以看到名为 chat-service 的 Go 进程消耗了超过 100% 的 CPU 核心资源。（如果你的症状恰好相反——请求不断涌入而 CPU 使用率却始终上不去——请参阅追踪卡在 2% CPU 的 Go 进程。）

使用 OpenResty XRay 剖析 Go 的 CPU 使用

我们用 OpenResty XRay 实时分析这个未经修改的进程——无需添加任何特殊模块、无需修改代码、无需重启。在 Web 控制台中，进入 Guided Analysis（引导式分析） 页面，选择 High CPU Usage（高 CPU 占用） 作为问题类型。OpenResty XRay 会自动发现目标机器上正在运行的应用。在下拉列表中选择这个 Go 应用。

选择 CPU 占用 96% 的那个进程——也就是我们之前在 top 中看到的进程。

将语言级别设为 Go，最大分析时间保持默认的 300 秒。启动分析后，系统会执行多轮分析；对这个例子来说两轮就足够了。

CPU 火焰图分析

OpenResty XRay 自动生成了一个报告。

报告显示了消耗 CPU 时间最多的那些 Go 级别代码路径。其中排名第一的是正则表达式编译，它占用了 36.8% 的 CPU 时间。

这是 Go 运行时中标准 regexp 库里的两个函数，它们负责编译正则表达式。

这个 CheckMessage 函数是我们业务逻辑的一部分，它调用了我们刚才看到的正则编译函数。

定位 Go 源文件和行号

如果想进一步研究这条代码路径，点击 More 链接。

点击后会看到该代码路径更详细的视图，它是从这个 Go 级别的 CPU 火焰图中推导出来的。

这里还有关于如何改善这条代码路径性能的说明和建议。

比如，它指出正则编译函数开销很大，应尽量避免调用。

接着它解释了业务级函数 CheckMessage，以及它使用和编译正则表达式的情况。

它也提到了编译好的正则表达式。

回到代码路径，把鼠标悬停在名为 CheckMessage 的 Go 函数的绿色框上。可以看到 CheckMessage 函数的 Go 源文件，提示框中还显示了 prev_processor.go 文件的完整路径。

Go 源码的行号是 17。

点击图标，复制这个函数完整的 Go 源文件路径。

在终端粘贴刚刚复制的路径，用 vim 编辑器查看相应的 Go 业务代码。您可以自由使用喜欢的编辑器。

跳转到第 17 行，也就是报告里显示的那个行号。

可以看到，这行代码确实在编译正则表达式，调用的是 regexp.MustCompile 函数。

它也确实位于报告中显示的 CheckMessage 函数中。接下来优化这里的 Go 代码就很容易了！

通过 OpenResty XRay 产品提升您应用的性能

全自动监控与报告

对于生产环境的负载，OpenResty XRay 可以持续监控进程，并在 Insights 页面自动生成以日和周为周期的报告——无需手动执行引导式分析。

常见问题

为什么我的 Go 程序 CPU 占用这么高？

Go 高 CPU 占用的一个常见原因，是某条热代码路径中存在开销很大的操作。在本例中，OpenResty XRay 将 CPU 瓶颈定位到了正则表达式编译——标准 regexp 库中的函数占用了 36.8% 的 CPU 时间——它们由业务函数 CheckMessage 在 prev_processor.go 第 17 行调用。CPU 火焰图能揭示从业务逻辑一直到运行时库函数的完整调用链。

在 Go 中编译正则表达式开销大吗？

是的。编译一个正则表达式需要构建匹配自动机，这比执行一个已经编译好的正则要昂贵得多。OpenResty XRay 的报告明确将 regexp 编译函数标记为开销很大，并建议避免在热代码路径中调用。通行做法是每个正则只编译一次并复用编译结果，而不是反复编译。

如何找到导致 Go 高 CPU 的代码？

使用 OpenResty XRay 的引导式分析生成 Go 级别的 CPU 火焰图。火焰图以堆叠的函数调用呈现，框的宽度代表 CPU 时间。把鼠标悬停在某个函数框上即可看到源文件路径和行号，然后用任意编辑器打开该文件，检查具体负责的代码——全程无需插桩、无需修改代码。

关于 OpenResty XRay

OpenResty XRay 是一个动态追踪产品，它可以自动分析运行中的应用程序，以解决性能问题、行为问题和安全漏洞，并提供可行的建议。在底层实现上，OpenResty XRay 由我们的 Y 语言驱动，可以在不同环境下支持多种不同的运行时，如 Stap+、eBPF+、GDB 和 ODB。

立即申请 OpenResty XRay 试用

关于作者

章亦春是开源 OpenResty^® 项目创始人兼 OpenResty Inc. 公司 CEO 和创始人。

章亦春（Github ID: agentzh），生于中国江苏，现定居美国湾区。他是中国早期开源技术和文化的倡导者和领军人物，曾供职于多家国际知名的高科技企业，如 Cloudflare、雅虎、阿里巴巴, 是 “边缘计算“、”动态追踪 “和 “机器编程 “的先驱，拥有超过 22 年的编程及 16 年的开源经验。作为拥有超过 4000 万全球域名用户的开源项目的领导者。他基于其 OpenResty^® 开源项目打造的高科技企业 OpenResty Inc. 位于美国硅谷中心。其主打的两个产品 OpenResty XRay（利用动态追踪技术的非侵入式的故障剖析和排除工具）和 OpenResty Edge（最适合微服务和分布式流量的全能型网关软件），广受全球众多上市及大型企业青睐。在 OpenResty 以外，章亦春为多个开源项目贡献了累计超过百万行代码，其中包括，Linux 内核、Nginx、LuaJIT、GDB、SystemTap、LLVM、Perl 等，并编写过 60 多个开源软件库。