容器内 perf record -a 失败因默认禁用 perf_event_open 系统调用（perf_event_paranoid=2），且缺乏调试符号；须在宿主机用 perf record -e sched:sched_switch -p 采集，再通过 tid 映射 jstack 线程与 perf 数据交叉验证。
不能直接在普通容器内用 perf record -a 抓上下文切换事件，会报 Operation not permitted；必须从宿主机视角采集，并手动关联 Java 线程与容器进程。
为什么容器里跑 perf record 会失败
普通 Docker 容器默认禁用 perf_event_open 系统调用，这是内核安全机制（/proc/sys/kernel/perf_event_paranoid 默认为 2）。即使你改了这个值，也仅缓解权限问题，不解决符号解析、Java JIT 代码无调试信息等根本障碍。
- 错误典型输出：
perf_event_open(, PERF_FLAG_FD_CLOEXEC) failed with unexpected error 1 (Operation not permitted) - 特权模式（
--privileged）虽能绕过，但生产环境禁止开启 - 容器内无
/usr/lib/debug或 JVM 调试符号，perf report显示大量[unknown]，无法定位到 Java 方法
正确做法：宿主机上用 perf record -e sched:sched_switch 捕获调度事件
上下文切换的根因（如锁竞争、线程抢占）发生在内核调度层，和容器隔离无关——只要在宿主机上运行 perf，就能捕获所有进程/线程的 sched:sched_switch tracepoint 事件。
- 先确认容器主进程 PID：
docker inspect -f '{{.State.Pid}}' <container_name></container_name> - 再采集 10 秒调度事件：
sudo perf record -e sched:sched_switch -p <pid> -g -- sleep 10</pid>（-p限定进程，避免全系统噪音） - 生成带调用栈的报告：
sudo perf report -F comm,dso,symbol --no-children，重点关注pthread_mutex_lock、__futex_wait、java_lang_Thread_State等符号 - 若看到大量线程在
_raw_spin_unlock_irqrestore上切换（如你知识库中提到的 10%+ 占比），说明内核自旋锁争抢严重，常与高并发 I/O 或中断风暴相关
如何把 perf 数据和 Java 线程状态对齐
perf 给出的是内核线程 ID（TID），而 jstack 输出的是 Java 线程的 nid（十六进制 TID）。二者必须映射，否则无法判断哪个 Java 方法正在触发频繁切换。
- 获取容器内所有 Java 线程 TID：
docker exec <container> jstack <java_pid> | grep 'nid=' | awk -F'=' '{print $2}' | cut -d' ' -f1 | xargs -I{} printf "%d\n" 0x{}</java_pid></container> - 用
perf script导出原始事件流，过滤出目标 TID：sudo perf script | awk '$3 ~ /tids/ {print}' | grep -E 'TID1|TID2' - 关键检查点：如果多个 Java 线程 TID 频繁出现在
sched:sched_switch的prev_comm/next_comm字段中，且都卡在同一个 native 方法（如Unsafe.park），基本可断定是 synchronized 或ReentrantLock争抢
真正难的不是采集数据，而是把 perf 的内核调度路径、pidstat -w 的 cswch/s 和 ncswch/s 数值、jstack 的线程堆栈三者串起来——漏掉任意一环，就容易把锁竞争误判成 GC 停顿或网络中断。别信单点工具输出，交叉验证才是底线。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
