Java 线上 Linux 服务器怎么通过 perf 工具分析系统底层性能热点-java教程-PHP中文网

perf能精准暴露java应用底层瓶颈，关键在于识别java行为触发的系统开销：如gc引发的频繁系统调用、锁竞争导致的内核调度延迟、i/o卡在ext4/blk层或jni陷入低效内核路径；需配置perf_event_paranoid、安装debuginfo，并用dwarf栈采样结合火焰图定位真实热点。

java 线上 linux 服务器怎么通过 perf 工具分析系统底层性能热点

Java 应用跑在 Linux 服务器上，JVM 层做了大量抽象（如 JIT 编译、GC、线程调度），直接看 Java 方法名对 perf 来说不可见——perf 只能看到机器码、JIT 编译后的热点汇编、以及内核态调用。但只要方法得当，perf 依然能精准暴露底层瓶颈：比如 GC 导致的频繁系统调用、锁竞争引发的内核调度延迟、磁盘 I/O 卡在 ext4 或 blk 层、甚至 JNI 调用陷入低效内核路径。

关键不是“看到 Java 方法”，而是“识别 Java 行为触发的底层开销”。

? 确保 perf 基础可用

检查权限：
```
echo -1 | sudo tee /proc/sys/kernel/perf_event_paranoid
```
若是容器环境，需启动时加 --cap-add=SYS_ADMIN 或 privileged: true。
安装对应内核 debuginfo（否则内核函数显示为地址）：
Ubuntu/Debian：
```
sudo apt install linux-image-$(uname -r)-dbgsym
```
CentOS/RHEL：
```
sudo debuginfo-install kernel-$(uname -r)
```
验证 /proc/kallsyms 可读：
```
sudo cat /proc/kallsyms | head -3
```
若报 Permission denied，上面 perf_event_paranoid 已解决。

? 抓取真实 Java 进程的底层热点（含内核栈）

Java 进程 PID 假设为 12345，推荐用 DWARF 模式采集完整调用链（尤其现代内核默认关闭 CONFIG_FRAME_POINTER）：

sudo perf record -p 12345 -g --call-graph dwarf,4096 -F 99 -a -- sleep 60

说明：

-p 12345：只抓目标 Java 进程（及其线程）
--call-graph dwarf,4096：强制用 DWARF 解析调用栈，4KB 栈深防截断（ARM64/x86_64 均适用）
-F 99：99Hz 采样频率，平衡精度与开销
-a：同时采集内核态（必须加，否则看不到 sys_read、do_page_fault 等）
-- sleep 60：持续采样 60 秒（可替换为任意命令，或直接 Ctrl+C 结束）

⚠️ 注意：DWARF 模式比 fp 模式开销略高，但能还原出 jvm.dll → os::Linux::safe_point_poll → epoll_wait → __x64_sys_epoll_wait → do_epoll_wait 这类关键链路。

Java JDK 25
Java JDK 25 来自 OpenJDK 官方归档，版本为 JDK 25，本条下载地址已指向官方 Windows x64 zip 安装包直链，适合调试旧项目或兼容旧版 Java 运行环境。

下载

? 分离并聚焦 Java 相关的底层行为

原始 perf report 会混杂 JVM 自身代码（如 libjvm.so 中的 CompiledIC::verify）、系统库（libc）、内核函数。用以下方式快速定位真瓶颈：

只看内核态热点（排除用户态干扰）：

perf script | awk -F';' '$1 ~ /^\[kernel\]/ {print $0}' | sort | uniq -c | sort -nr | head -10

过滤 I/O 相关内核函数（排查磁盘/网络卡点）：

perf script | grep -E "(ext4|bio|blk|scsi|nvme|tcp|udp|epoll|io_uring)" | head -20

统计某内核函数被 Java 进程触发的次数（例如 GC 触发的页回收）：
```
perf script | cut -d';' -f1-3 | grep "try_to_free_pages" | wc -l
```
确认是否 JIT 代码被采样到：
```
perf report | grep -E "(libjvm|java|HotSpot)"
```
若看到 libjvm.so 下大量 [.] 地址，说明 JIT 编译后代码已被采样；若全是 [unknown]，检查 JVM 是否启用了 -XX:+PreserveFramePointer（Java 10+ 默认关闭，影响 fp 栈，但 DWARF 不依赖它）。

? 生成火焰图看全局热区（含 Java + 内核混合栈）

用 FlameGraph 工具可视化：

sudo perf script > perf.out
./stackcollapse-perf.pl perf.out > folded.out
./flamegraph.pl folded.out > java-flame.svg

打开 java-flame.svg 后，你会看到：

左侧宽条可能是 libjvm.so 的 G1CollectedHeap::garbage_collect_impl → os::sleep → nanosleep → hrtimer_nanosleep
顶部突然变宽的 [kernel] 区域可能对应 ext4_writepages → mpage_submit_bio → submit_bio
大量 epoll_wait 堆叠说明应用处于高并发等待状态（未必是瓶颈，但需结合业务判断）

✅ 小技巧：用浏览器搜索 epoll_wait 或 ext4，快速定位 I/O 或调度层耗时。

? 典型 Java 场景对应的 perf 信号

现象	perf 中典型表现	可能原因
Full GC 频繁	`perf script` 大量出现 `do_page_fault`、`try_to_free_pages`、`shrink_slab`	堆外内存泄漏、DirectByteBuffer 未释放、元空间不足
接口响应慢但 CPU 不高	`off-cpu` 火焰图中 `futex_wait_queue_me` 占比高	锁竞争（synchronized / ReentrantLock）、线程阻塞在 `Object.wait()`
日志写入慢	`ext4_file_write_iter` → `generic_perform_write` → `pagecache_get_page` 长栈	文件系统缓存压力大、磁盘 I/O 饱和、日志同步策略（`<appender></appender>` 中 `immediateFlush="true"`）
Netty 连接建立慢	`tcp_v4_connect` → `ip_route_output_flow` → `fib_lookup` 耗时高	网络路由表膨胀、DNS 解析卡顿（看 `getaddrinfo` 是否在栈中）

不复杂但容易忽略。

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南