企业官网建设流程全解析

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 Profiling

CPU profiling采样程序运行时的CPU使用情况，告诉你时间花在哪个函数上。

packagemainimport("os""runtime/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;i<1000000;i++{// 每次都重新计算，可以优化为预计算data[i]=fib(30)}}// fib 递归计算斐波那契数，CPU消耗大户funcfib(nint)int{ifn<=1{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.mallocgc

flat和cum要分清。flat是函数自身代码消耗的CPU，cum是函数加上它调用的所有子函数消耗的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?seconds=30# 在线采集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 Profiling

Memory profiling分析内存分配，帮你找到内存大户和GC压力来源。

packagemainimport("os""runtime""runtime/pprof")// MemProfile 演示内存profilingfuncMemProfile(){// 先跑业务逻辑allocHeavy()// 获取当前堆内存快照f,_:=os.Create("heap.prof")deferf.Close()// 手动触发GC，获取更干净的快照runtime.GC()pprof.WriteHeapProfile(f)}// allocHeavy 模拟大量内存分配funcallocHeavy(){// 故意创建大量小对象// 每个map都是独立分配，GC压力大varslices[][]intfori:=0;i<100000;i++{// 每次分配一个小slices:=make([]int,10)slices=append(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回收result+=p}returnresult}// 优化:用strings.BuilderfuncgoodConcat(parts[]string)string{varsb strings.Builder// 预分配空间，减少扩容sb.Grow(len(parts)*10)for_,p:=rangeparts{sb.WriteString(p)}returnsb.String()}

四、Goroutine Profiling

Goroutine profile分析协程数量和状态，是排查协程泄漏的利器。

packagemainimport("fmt""net/http"_"net/http/pprof""sync""time")// 模拟协程泄漏:协程永远阻塞在channel接收funcleakyWorker(chchanint){// 这个协程会永远阻塞在这里// 没人往channel发数据，它永远等待val:=<-ch fmt.Println("收到:",val)}funcstartLeak(){ch:=make(chanint)// 启动100个worker但没有给channel发数据fori:=0;i<100;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?debug=1# 输出示例:# goroutine profile: total 1000# 1000 @ 0x401234 0x401456 ...# # 0x401234 main.leakyWorker+0x34# /app/main.go:15 chan receive# 用pprof分析goroutinego tool pprof http://localhost:6060/debug/pprof/goroutine# 在pprof交互界面# (pprof) top# 显示哪个函数创建了最多的goroutine

goroutine profile的debug=1输出会列出每个协程的调用栈。如果看到大量协程卡在chan receive，说明有channel没人发送数据。如果卡在select，说明所有case都不满足条件。如果卡在semacquire，说明在等锁。

五、独家踩坑:高峰期卡顿的在线采样

前面提到的那个高峰期卡顿问题，排查过程值得详细说。

第一天，本地压测。用wrk模拟线上QPS压了半小时，P99稳定50ms。怀疑是数据量的问题，造了一批大数据量的测试数据，还是50ms。

第二天，怀疑是GC问题。加了GODEBUG=gctrace=1跑线上，看GC日志。GC暂停时间都在1ms以内，排除GC。

第三天，上pprof。写了脚本在高峰期前30秒自动采CPU profile。

#!/bin/bash# 高峰期前自动采样脚本# 每天下午2:59触发SCHEDULE="59 14 * * *"# 采样30秒，覆盖高峰期开始阶段go tool pprof-seconds=30\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(","))}first=false// 逐条序列化写入data,_:=json.Marshal(order)w.Write(data)}offset+=batchSize}w.Write([]byte("]"))}

改成流式序列化后，单次请求的内存峰值从序列化整个大数组降到序列化单条记录。高峰期P99从2秒降到80ms。

六、对比分析

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。