Go性能分析:pprof工具实战摘要: 本篇讲解Go pprof性能分析工具实战涵盖CPU profiling用go tool pprof分析热点函数、Memory profiling用heap和alloc_objects分析内存分配、Goroutine profiling排查协程泄漏、net/http/pprof在线采样分享线上服务只在高峰期卡顿本地无法复现最终用pprof web在线采样定位到JSON序列化瓶颈的踩坑经历对比pprof、go tool trace、delv调试器三款工具。开篇故事去年有个线上服务平时响应50ms一到每天下午三点高峰期就飙到2秒。我在本地压测模拟同样的QPS延迟稳定在50ms完全复现不了。运维说CPU和内存都正常看不出问题。折腾了三天最后用pprof在线采样发现高峰期有个JSON序列化函数占了80%的CPU。那个函数在高峰期处理的payload特别大序列化一个2MB的JSON结构体。加了字段过滤只序列化必要字段后高峰期延迟降到80ms。pprof是Go性能问题的终极排查工具。这篇讲CPU、内存、协程三种profiling的实战用法。一、CPU ProfilingCPU profiling采样程序运行时的CPU使用情况告诉你时间花在哪个函数上。packagemainimport(osruntime/pprof)// CPUProfile 演示CPU profiling的基本用法funcCPUProfile(){// 创建CPU profile文件f,_:os.Create(cpu.prof)deferf.Close()// 开始CPU采样pprof.StartCPUProfile(f)deferpprof.StopCPUProfile()// 运行被分析的代码heavyCompute()}// heavyCompute 模拟CPU密集型计算funcheavyCompute(){// 故意写一个低效的计算data:make([]int,1000000)fori:0;i1000000;i{// 每次都重新计算可以优化为预计算data[i]fib(30)}}// fib 递归计算斐波那契数CPU消耗大户funcfib(nint)int{ifn1{returnn}returnfib(n-1)fib(n-2)}生成profile文件后用go tool pprof分析。# 命令行交互模式go tool pprof cpu.prof# 常用命令# top10 查看CPU占用最高的10个函数# list fib 查看fib函数的逐行CPU消耗# web 生成调用图(需要graphviz)# tree 以树形展示调用关系# Web界面模式更直观go tool pprof-http:8080 cpu.prof# 浏览器打开localhost:8080查看火焰图# top10输出示例 # flat表示函数自身消耗的CPU时间 # cum表示函数及其调用链消耗的CPU时间 flat flat% sum% cum cum% 12.50s 62.50% 62.50% 12.50s 62.50% main.fib 3.20s 16.00% 78.50% 15.70s 78.50% main.heavyCompute 0.10s 0.50% 79.00% 0.10s 0.50% runtime.mallocgcflat和cum要分清。flat是函数自身代码消耗的CPUcum是函数加上它调用的所有子函数消耗的CPU。fib的flat最高说明fib函数本身的递归计算是瓶颈。heavyCompute的cum很高但它自身的flat只有3秒因为它调用了fib。二、在线Profiling生产环境不能随便重启服务来生成profile文件。Go提供了net/http/pprof包通过HTTP端点在线采样。packagemainimport(net/http// 导入即可自动注册/debug/pprof路由_net/http/pprof)funcmain(){// 业务服务mux:http.NewServeMux()mux.HandleFunc(/api/process,processHandler)// pprof端点监听在单独端口不暴露给外网// 生产环境建议用独立端口或加IP白名单gofunc(){http.ListenAndServe(localhost:6060,nil)}()http.ListenAndServe(:8080,mux)}funcprocessHandler(w http.ResponseWriter,r*http.Request){// 模拟业务处理result:heavyCompute()w.Write([]byte(result))}# 在线采集CPU profile采样30秒go tool pprof http://localhost:6060/debug/pprof/profile?seconds30# 在线采集heap profilego tool pprof http://localhost:6060/debug/pprof/heap# 在线采集goroutine profilego tool pprof http://localhost:6060/debug/pprof/goroutine# 查看所有可用profile端点curlhttp://localhost:6060/debug/pprof/在线采样是pprof最强大的能力。服务不用重启在高峰期实时采样30秒就能拿到CPU热点。注意生产环境pprof端口不要暴露到公网用localhost监听或加防火墙规则。三、Memory ProfilingMemory profiling分析内存分配帮你找到内存大户和GC压力来源。packagemainimport(osruntimeruntime/pprof)// MemProfile 演示内存profilingfuncMemProfile(){// 先跑业务逻辑allocHeavy()// 获取当前堆内存快照f,_:os.Create(heap.prof)deferf.Close()// 手动触发GC获取更干净的快照runtime.GC()pprof.WriteHeapProfile(f)}// allocHeavy 模拟大量内存分配funcallocHeavy(){// 故意创建大量小对象// 每个map都是独立分配GC压力大varslices[][]intfori:0;i100000;i{// 每次分配一个小slices:make([]int,10)slicesappend(slices,s)}}# 分析heap profilego tool pprof heap.prof# 关键命令# top 查看内存分配最多的函数# list fn 查看函数逐行分配情况# web 生成内存分配图# 使用-inuse_space看当前占用内存go tool pprof-inuse_spaceheap.prof# 使用-alloc_objects看历史分配对象数go tool pprof-alloc_objectsheap.prof-inuse_space和-alloc_objects是两个不同的视角。inuse看的是采样时还活着的对象占用的内存。alloc看的是程序运行期间累计分配过的对象数量。如果服务内存一直涨但inuse不高说明是分配频率太高导致GC频繁看alloc_objects更有用。// 常见内存问题:字符串拼接产生大量临时对象funcbadConcat(parts[]string)string{result:for_,p:rangeparts{// 每次拼接都分配新字符串// 旧字符串变成垃圾等GC回收resultp}returnresult}// 优化:用strings.BuilderfuncgoodConcat(parts[]string)string{varsb strings.Builder// 预分配空间减少扩容sb.Grow(len(parts)*10)for_,p:rangeparts{sb.WriteString(p)}returnsb.String()}四、Goroutine ProfilingGoroutine profile分析协程数量和状态是排查协程泄漏的利器。packagemainimport(fmtnet/http_net/http/pprofsynctime)// 模拟协程泄漏:协程永远阻塞在channel接收funcleakyWorker(chchanint){// 这个协程会永远阻塞在这里// 没人往channel发数据它永远等待val:-ch fmt.Println(收到:,val)}funcstartLeak(){ch:make(chanint)// 启动100个worker但没有给channel发数据fori:0;i100;i{goleakyWorker(ch)}// 函数返回后100个协程泄漏}funcmain(){// 每秒泄漏100个协程gofunc(){for{startLeak()time.Sleep(time.Second)}}()// pprof端点http.ListenAndServe(localhost:6060,nil)}# 查看当前goroutine数量curlhttp://localhost:6060/debug/pprof/goroutine?debug1# 输出示例:# goroutine profile: total 1000# 1000 0x401234 0x401456 ...# # 0x401234 main.leakyWorker0x34# /app/main.go:15 chan receive# 用pprof分析goroutinego tool pprof http://localhost:6060/debug/pprof/goroutine# 在pprof交互界面# (pprof) top# 显示哪个函数创建了最多的goroutinegoroutine profile的debug1输出会列出每个协程的调用栈。如果看到大量协程卡在chan receive说明有channel没人发送数据。如果卡在select说明所有case都不满足条件。如果卡在semacquire说明在等锁。五、独家踩坑:高峰期卡顿的在线采样前面提到的那个高峰期卡顿问题排查过程值得详细说。第一天本地压测。用wrk模拟线上QPS压了半小时P99稳定50ms。怀疑是数据量的问题造了一批大数据量的测试数据还是50ms。第二天怀疑是GC问题。加了GODEBUGgctrace1跑线上看GC日志。GC暂停时间都在1ms以内排除GC。第三天上pprof。写了脚本在高峰期前30秒自动采CPU profile。#!/bin/bash# 高峰期前自动采样脚本# 每天下午2:59触发SCHEDULE59 14 * * *# 采样30秒覆盖高峰期开始阶段go tool pprof-seconds30\http://localhost:6060/debug/pprof/profile\-outputpeak_cpu.prof采到profile后用go tool pprof -http:8080 peak_cpu.prof打开火焰图。一眼看到encoding/json.Marshal占了80%的CPU。定位到具体函数高峰期处理的是全量数据导出请求一个用户一次请求拉上万条记录每条记录做JSON序列化。// 问题代码:高峰期序列化大量数据funcExportHandler(w http.ResponseWriter,r*http.Request){// 查出所有数据可能上万条orders:queryAllOrders()// 全量序列化大对象序列化极慢json.NewEncoder(w).Encode(orders)}// 优化:流式序列化分批写入funcExportHandlerFixed(w http.ResponseWriter,r*http.Request){w.Header().Set(Content-Type,application/json)w.Write([]byte([))// 分批查询每批100条batchSize:100offset:0first:truefor{orders:queryOrdersBatch(offset,batchSize)iflen(orders)0{break}for_,order:rangeorders{if!first{w.Write([]byte(,))}firstfalse// 逐条序列化写入data,_:json.Marshal(order)w.Write(data)}offsetbatchSize}w.Write([]byte(]))}改成流式序列化后单次请求的内存峰值从序列化整个大数组降到序列化单条记录。高峰期P99从2秒降到80ms。六、对比分析特性pprofgo tool tracedlv调试器分析类型CPU/内存/协程执行轨迹交互式断点调试采样方式采样或在线全量记录断点暂停性能开销低(采样)高(全量)高(暂停)适用场景性能瓶颈定位调度延迟分析逻辑bug排查可视化火焰图时间线无在线分析支持(http/pprof)不支持不支持学习成本低中高pprof适合性能瓶颈定位开销低可以在线采样。trace适合分析调度延迟和GC停顿但开销大不适合生产环境。dlv适合排查逻辑bug打断点单步调试。总结与预告pprof三件套记住了。CPU profile找热点函数用top和火焰图定位。Memory profile找内存大户区分inuse和alloc两个视角。Goroutine profile找协程泄漏看调用栈判断阻塞原因。生产环境一定要接net/http/pprof高峰期在线采样是定位问题的杀手锏。下一篇讲Go内存管理原理与GC调优sync.Pool怎么把GC暂停从50ms降到5ms。 
长河君 · 2026/8/17 19:26:58 · 阅读 1.2k Go性能分析:pprof工具实战
Go性能分析:pprof工具实战摘要: 本篇讲解Go pprof性能分析工具实战涵盖CPU profiling用go tool pprof分析热点函数、Memory profiling用heap和alloc_objects分析内存分配、Goroutine profiling排查协程泄漏、net/http/pprof在线采样分享线上服务只在高峰期卡顿本地无法复现最终用pprof web在线采样定位到JSON序列化瓶颈的踩坑经历对比pprof、go tool trace、delv调试器三款工具。开篇故事去年有个线上服务平时响应50ms一到每天下午三点高峰期就飙到2秒。我在本地压测模拟同样的QPS延迟稳定在50ms完全复现不了。运维说CPU和内存都正常看不出问题。折腾了三天最后用pprof在线采样发现高峰期有个JSON序列化函数占了80%的CPU。那个函数在高峰期处理的payload特别大序列化一个2MB的JSON结构体。加了字段过滤只序列化必要字段后高峰期延迟降到80ms。pprof是Go性能问题的终极排查工具。这篇讲CPU、内存、协程三种profiling的实战用法。一、CPU ProfilingCPU profiling采样程序运行时的CPU使用情况告诉你时间花在哪个函数上。packagemainimport(osruntime/pprof)// CPUProfile 演示CPU profiling的基本用法funcCPUProfile(){// 创建CPU profile文件f,_:os.Create(cpu.prof)deferf.Close()// 开始CPU采样pprof.StartCPUProfile(f)deferpprof.StopCPUProfile()// 运行被分析的代码heavyCompute()}// heavyCompute 模拟CPU密集型计算funcheavyCompute(){// 故意写一个低效的计算data:make([]int,1000000)fori:0;i1000000;i{// 每次都重新计算可以优化为预计算data[i]fib(30)}}// fib 递归计算斐波那契数CPU消耗大户funcfib(nint)int{ifn1{returnn}returnfib(n-1)fib(n-2)}生成profile文件后用go tool pprof分析。# 命令行交互模式go tool pprof cpu.prof# 常用命令# top10 查看CPU占用最高的10个函数# list fib 查看fib函数的逐行CPU消耗# web 生成调用图(需要graphviz)# tree 以树形展示调用关系# Web界面模式更直观go tool pprof-http:8080 cpu.prof# 浏览器打开localhost:8080查看火焰图# top10输出示例 # flat表示函数自身消耗的CPU时间 # cum表示函数及其调用链消耗的CPU时间 flat flat% sum% cum cum% 12.50s 62.50% 62.50% 12.50s 62.50% main.fib 3.20s 16.00% 78.50% 15.70s 78.50% main.heavyCompute 0.10s 0.50% 79.00% 0.10s 0.50% runtime.mallocgcflat和cum要分清。flat是函数自身代码消耗的CPUcum是函数加上它调用的所有子函数消耗的CPU。fib的flat最高说明fib函数本身的递归计算是瓶颈。heavyCompute的cum很高但它自身的flat只有3秒因为它调用了fib。二、在线Profiling生产环境不能随便重启服务来生成profile文件。Go提供了net/http/pprof包通过HTTP端点在线采样。packagemainimport(net/http// 导入即可自动注册/debug/pprof路由_net/http/pprof)funcmain(){// 业务服务mux:http.NewServeMux()mux.HandleFunc(/api/process,processHandler)// pprof端点监听在单独端口不暴露给外网// 生产环境建议用独立端口或加IP白名单gofunc(){http.ListenAndServe(localhost:6060,nil)}()http.ListenAndServe(:8080,mux)}funcprocessHandler(w http.ResponseWriter,r*http.Request){// 模拟业务处理result:heavyCompute()w.Write([]byte(result))}# 在线采集CPU profile采样30秒go tool pprof http://localhost:6060/debug/pprof/profile?seconds30# 在线采集heap profilego tool pprof http://localhost:6060/debug/pprof/heap# 在线采集goroutine profilego tool pprof http://localhost:6060/debug/pprof/goroutine# 查看所有可用profile端点curlhttp://localhost:6060/debug/pprof/在线采样是pprof最强大的能力。服务不用重启在高峰期实时采样30秒就能拿到CPU热点。注意生产环境pprof端口不要暴露到公网用localhost监听或加防火墙规则。三、Memory ProfilingMemory profiling分析内存分配帮你找到内存大户和GC压力来源。packagemainimport(osruntimeruntime/pprof)// MemProfile 演示内存profilingfuncMemProfile(){// 先跑业务逻辑allocHeavy()// 获取当前堆内存快照f,_:os.Create(heap.prof)deferf.Close()// 手动触发GC获取更干净的快照runtime.GC()pprof.WriteHeapProfile(f)}// allocHeavy 模拟大量内存分配funcallocHeavy(){// 故意创建大量小对象// 每个map都是独立分配GC压力大varslices[][]intfori:0;i100000;i{// 每次分配一个小slices:make([]int,10)slicesappend(slices,s)}}# 分析heap profilego tool pprof heap.prof# 关键命令# top 查看内存分配最多的函数# list fn 查看函数逐行分配情况# web 生成内存分配图# 使用-inuse_space看当前占用内存go tool pprof-inuse_spaceheap.prof# 使用-alloc_objects看历史分配对象数go tool pprof-alloc_objectsheap.prof-inuse_space和-alloc_objects是两个不同的视角。inuse看的是采样时还活着的对象占用的内存。alloc看的是程序运行期间累计分配过的对象数量。如果服务内存一直涨但inuse不高说明是分配频率太高导致GC频繁看alloc_objects更有用。// 常见内存问题:字符串拼接产生大量临时对象funcbadConcat(parts[]string)string{result:for_,p:rangeparts{// 每次拼接都分配新字符串// 旧字符串变成垃圾等GC回收resultp}returnresult}// 优化:用strings.BuilderfuncgoodConcat(parts[]string)string{varsb strings.Builder// 预分配空间减少扩容sb.Grow(len(parts)*10)for_,p:rangeparts{sb.WriteString(p)}returnsb.String()}四、Goroutine ProfilingGoroutine profile分析协程数量和状态是排查协程泄漏的利器。packagemainimport(fmtnet/http_net/http/pprofsynctime)// 模拟协程泄漏:协程永远阻塞在channel接收funcleakyWorker(chchanint){// 这个协程会永远阻塞在这里// 没人往channel发数据它永远等待val:-ch fmt.Println(收到:,val)}funcstartLeak(){ch:make(chanint)// 启动100个worker但没有给channel发数据fori:0;i100;i{goleakyWorker(ch)}// 函数返回后100个协程泄漏}funcmain(){// 每秒泄漏100个协程gofunc(){for{startLeak()time.Sleep(time.Second)}}()// pprof端点http.ListenAndServe(localhost:6060,nil)}# 查看当前goroutine数量curlhttp://localhost:6060/debug/pprof/goroutine?debug1# 输出示例:# goroutine profile: total 1000# 1000 0x401234 0x401456 ...# # 0x401234 main.leakyWorker0x34# /app/main.go:15 chan receive# 用pprof分析goroutinego tool pprof http://localhost:6060/debug/pprof/goroutine# 在pprof交互界面# (pprof) top# 显示哪个函数创建了最多的goroutinegoroutine profile的debug1输出会列出每个协程的调用栈。如果看到大量协程卡在chan receive说明有channel没人发送数据。如果卡在select说明所有case都不满足条件。如果卡在semacquire说明在等锁。五、独家踩坑:高峰期卡顿的在线采样前面提到的那个高峰期卡顿问题排查过程值得详细说。第一天本地压测。用wrk模拟线上QPS压了半小时P99稳定50ms。怀疑是数据量的问题造了一批大数据量的测试数据还是50ms。第二天怀疑是GC问题。加了GODEBUGgctrace1跑线上看GC日志。GC暂停时间都在1ms以内排除GC。第三天上pprof。写了脚本在高峰期前30秒自动采CPU profile。#!/bin/bash# 高峰期前自动采样脚本# 每天下午2:59触发SCHEDULE59 14 * * *# 采样30秒覆盖高峰期开始阶段go tool pprof-seconds30\http://localhost:6060/debug/pprof/profile\-outputpeak_cpu.prof采到profile后用go tool pprof -http:8080 peak_cpu.prof打开火焰图。一眼看到encoding/json.Marshal占了80%的CPU。定位到具体函数高峰期处理的是全量数据导出请求一个用户一次请求拉上万条记录每条记录做JSON序列化。// 问题代码:高峰期序列化大量数据funcExportHandler(w http.ResponseWriter,r*http.Request){// 查出所有数据可能上万条orders:queryAllOrders()// 全量序列化大对象序列化极慢json.NewEncoder(w).Encode(orders)}// 优化:流式序列化分批写入funcExportHandlerFixed(w http.ResponseWriter,r*http.Request){w.Header().Set(Content-Type,application/json)w.Write([]byte([))// 分批查询每批100条batchSize:100offset:0first:truefor{orders:queryOrdersBatch(offset,batchSize)iflen(orders)0{break}for_,order:rangeorders{if!first{w.Write([]byte(,))}firstfalse// 逐条序列化写入data,_:json.Marshal(order)w.Write(data)}offsetbatchSize}w.Write([]byte(]))}改成流式序列化后单次请求的内存峰值从序列化整个大数组降到序列化单条记录。高峰期P99从2秒降到80ms。六、对比分析特性pprofgo tool tracedlv调试器分析类型CPU/内存/协程执行轨迹交互式断点调试采样方式采样或在线全量记录断点暂停性能开销低(采样)高(全量)高(暂停)适用场景性能瓶颈定位调度延迟分析逻辑bug排查可视化火焰图时间线无在线分析支持(http/pprof)不支持不支持学习成本低中高pprof适合性能瓶颈定位开销低可以在线采样。trace适合分析调度延迟和GC停顿但开销大不适合生产环境。dlv适合排查逻辑bug打断点单步调试。总结与预告pprof三件套记住了。CPU profile找热点函数用top和火焰图定位。Memory profile找内存大户区分inuse和alloc两个视角。Goroutine profile找协程泄漏看调用栈判断阻塞原因。生产环境一定要接net/http/pprof高峰期在线采样是定位问题的杀手锏。下一篇讲Go内存管理原理与GC调优sync.Pool怎么把GC暂停从50ms降到5ms。