人工智能AI AgentAgent 框架工具调用Agent 工作流RAGMCP Clients强化学习【免费下载链接】agent-core-javaopenJiuwen agent core Java是 openJiuwen Core的 Java版本提供AI Agent开发、运行、调优与演进相关的全套SDK能力。项目地址https://gitcode.com/openJiuwen/agent-core-java点击查看免费下载本篇技术指南以 openJiuwen/agent-core-java 仓库自带的 JVM 排障技能库jvm-troubleshoot中 JFR 事后分析文档为主体系统讲解如何利用JDK Flight RecorderJFR应对 OOM、CPU 100%、线程死锁、高频 GC、类加载泄漏等生产事故的复盘与根因定位。读者将掌握JFR 事件分类与按故障选事件的速查方法、启动时 always-on / 临时采集 / 后台采集 / 在线流式四种采集方式、JMC 与jfr命令行的分析手法以及可直接照搬落地的四大排障工作流与配置模板。为什么生产排障首选 JFR与 jstack/jmap 的对比在 JDK 17 时代传统的反应式排障三板斧jstack看线程、jmap看堆正逐步被 JFR 取代。JFR 是随 JDK 内置的采样与事件记录框架JDK 17 下开销低于 1%可以常开运行因此成为线上事故发生后进行复盘分析的首选工具而 jstack/jmap 降级为补充手段。维度jstack / jmapJFR开销中每次执行都会影响应用极低 1%可常开数据形态单一时点快照连续时间窗事件流在线流式不支持支持JDK 14火焰图需额外加工内置最佳场景一次性诊断长期监控 事后分析容器友好度需要 JDK SYS_PTRACE 权限启动时配置即可使用结论在 JDK 17 上优先使用 JFRjstack/jmap 作为辅助工具。从本仓库的构建配置看core/pom.xml 声明java.version17、maven.compiler.release17即整个 agent-core-java 默认运行在 JDK 17 之上JFR 常开、jfr命令行工具与jdk.jfrAPI 均为开箱可用无需引入任何第三方依赖。JFR 事件分类速查JFR 的事件按功能域分类事故复盘的第一步往往是“按症状定位该看哪类事件”。下表整理自仓库排障技能库中的 JFR 分析文档分类代表事件用途GCjdk.GarbageCollection排查频繁 GC / 停顿内存jdk.ObjectAllocationSample/jdk.GCHeapSummary排查内存分配热点锁jdk.JavaMonitorWait/jdk.JavaMonitorEnter排查锁竞争 / 死锁线程jdk.ThreadStart/jdk.ThreadPark排查线程泄漏 / 阻塞CPUjdk.ExecutionSample火焰图数据源类加载jdk.ClassLoad/jdk.ClassUnload排查 ClassLoader 泄漏IOjdk.FileRead/jdk.SocketRead排查 IO 阻塞异常jdk.JavaExceptionThrow排查异常风暴JVMjdk.JVMInformation/jdk.OSInformation环境信息两点补充其一所有事件名均带jdk.前缀后续jfr print --events、EventStream.onEvent中引用的都是这一全限定事件名其二事件采样强度由启动时的settingsprofile/settingsdefault决定——profile采样率高、default开销更小这直接关系到下面“按故障类型选事件”时样本是否足够。按故障类型选择事件OOM 之前该盯哪些事件OOM 的最佳治理窗口在“事故发生前”。只要在启动时开启了 JFR事后就能还原堆内存的整个恶化过程事件检查要点jdk.ObjectAllocationSample谁在大量分配对象找热点jdk.GCHeapSummary堆增长曲线从何时开始涨jdk.GarbageCollectionGC 频率 回收率回收不掉 泄漏jdk.JavaExceptionThrow是否大量出现 OOM 前兆异常分析步骤在 JMC 中打开.jfr文件查看 GC Heap 趋势——堆占用从什么时候开始不再回落查看 Object Allocation Sample——哪个类分配最多关联时间线——是哪个业务流量段触发的。CPU 100% 该盯哪些事件事件检查要点jdk.ExecutionSample火焰图中哪个方法最耗 CPUjdk.CPULoadCPU 负载趋势jdk.ThreadCPULoad哪个线程在消耗 CPU分析步骤JMC 火焰图找出最宽的方法检查是否是 GC 线程在消耗 CPU若最宽的是GC Thread本质是内存问题而非业务问题检查业务线程是否陷入死循环栈帧固定不变即高度疑似。死锁之前该盯哪些事件事件检查要点jdk.JavaMonitorEnter锁等待时长 等待的是哪把锁jdk.JavaMonitorWaitwait()的等待时长jdk.ThreadPark线程 park 阻塞jdk.ExecutionSample线程栈看卡在哪个方法注意JFR不会自动检测死锁。死锁的最终确认仍要靠jcmd pid Thread.print在输出中查找Found Java deadlock。JFR 的价值在于还原死锁的前兆查看JavaMonitorEnter等待时长分布——P99 等待时间很长 锁竞争激烈查看时间线——等待飙升从何时开始关联ExecutionSample——线程是在哪个方法里等待锁的。高频 GC 该盯哪些事件事件检查要点jdk.GarbageCollectionGC 次数 时长 触发原因jdk.GCHeapSummaryGC 前后堆占用 停顿时间jdk.G1HeapRegionInformationG1Region 占用情况jdk.ObjectAllocationSample分配热点分析步骤检查 GC 频率与触发原因Allocation Rate/System.gc()/Metaspace看 Young GC 与 Full GC 的比例看 GC 后老年代是否回落不回落 泄漏关联分配采样找到分配热点。类加载泄漏该盯哪些事件事件检查要点jdk.ClassLoad加载的类数量 ClassLoaderjdk.ClassLoaderStatisticsClassLoader 数量 占用分析步骤查看 ClassLoader 数量趋势确认哪一类 ClassLoader 在持续增长热部署、动态代理是常见来源关联ClassLoad事件看具体在加载什么类。JFR 启动与采集的四种方式方式一启动时 Always-On生产推荐生产环境推荐在 JVM 启动时就开启 JFR保证事故发生后数据一直都在-XX:StartFlightRecordingfilename/var/log/jfr/app.jfr,maxage1h,maxsize100M,settingsprofile -XX:FlightRecorderOptionsstackdepth64参数说明maxage1h滚动保留 1 小时的数据maxsize100M文件大小上限两者共同构成滚动窗口settingsprofile高采样率相比default更耗资源但火焰图与分配采样更细stackdepth64栈深度默认 64复杂应用可调到 128。方式二临时 30 秒采集最常用的反应式排障手段——问题正在发生时现场抓 30 秒# 启动 30 秒采集 jcmd pid JFR.start duration30s filename/tmp/recording.jfr # 容器内主进程即 PID 1 jcmd 1 JFR.start duration30s filename/tmp/recording.jfr容器场景下的 PID 1 问题在仓库的 container_troubleshooting.md 中有专门说明jps默认看不到容器主进程PID 1此时直接用jcmd 1 ...即可这也是 JFR 在容器里比 jstack/jmap 更省事的原因之一。方式三持续后台采集# 后台启动一直采集到显式停止 jcmd pid JFR.start filename/tmp/cont.jfr maxage1h maxsize100M settingsprofile # 查看正在运行的录制 jcmd pid JFR.check # 停止并落盘 jcmd pid JFR.stop name1 filename/tmp/final.jfr方式四在线流式JDK 14无需写盘应用内直接消费 JFR 事件适用于内置实时监控与告警import jdk.jfr.consumer.EventStream; try (EventStream stream EventStream.openRepository()) { // 实时 GC 监控 stream.onEvent(jdk.GarbageCollection, e - { System.out.println(GC: e.getDuration(duration) ms); if (e.getDuration(duration).toMillis() 100) { alertService.notify(Long GC detected!); } }); // 实时锁等待监控 stream.onEvent(jdk.JavaMonitorEnter, e - { if (e.getDuration(duration).toMillis() 50) { log.warn(Long lock wait: e.getDuration(duration)); } }); stream.startAsync(); Thread.sleep(Long.MAX_VALUE); }典型适用场景在应用内做嵌入式实时监控与告警对接 APM 厂商的采集端不依赖任何外部工具纯 JDK 自带 API。JMCJDK Mission Control分析JMC 是官方出品的 JFR 文件查看 GUI 工具。安装时从 OpenJDK 官方发布渠道获取对应 JDK 版本的 JMC 发行包即可无需与 JDK 绑定安装。主要视图OverviewCPU / 内存 / GC / 线程汇总GC Configuration / PausesGC 频率、停顿时间分布Memory堆占用趋势、分配热点Threads线程状态分布、锁等待Code方法级 CPU 采样I/O文件 / 网络 IOSystemJVM 参数、环境信息。JMC 火焰图JDK 14 的 JMC 支持火焰图打开.jfr文件选择 Method Profile 或 Memory 视图点击火焰图按钮。读图要点X 轴调用栈横向展开Y 轴栈深度宽度CPU / 内存时间占比找到最宽的“平顶”——那就是优化目标或问题根因所在。命令行 JFR 分析不装 JMC 也能看线上环境往往不便安装 GUI 工具JDK 自带jfr命令即可完成大部分分析# 查看所有事件默认前 10 条 jfr print recording.jfr # 查看指定事件 jfr print --events jdk.GarbageCollection recording.jfr # 查看指定事件 JSON 格式输出 jfr print --events jdk.JavaMonitorEnter --json recording.jfr # 查看汇总统计 jfr summary recording.jfr # 按分类过滤 jfr print --categories GC recording.jfr--json输出便于把事件数据接入脚本或监控系统做二次加工jfr summary则是事故复盘时最快的“一页纸总览”。JFR 与 async-profiler 的选型维度JFRasync-profiler来源Oracle / OpenJDK 官方社区开源集成方式内置于 JVM外部 agent火焰图通过 JMC /jfr print内置直接生成 HTML事件类型丰富GC / 锁 / IO / 类加载……较少CPU / Alloc / Lock在线流式支持JDK 14不支持生产常开推荐可行易用性GUIJMC CLICLI 火焰图选型建议全局排障、长期监控 → JFR快速出火焰图、定位 CPU / Alloc 热点 → async-profiler生产环境 → 启动时 JFR always-on 临时采样时用 async-profiler 补充。四大实战工作流以下四条工作流均整理自仓库技能库可直接按步骤执行。工作流 1OOM 事后分析启动时开启 JFR-XX:StartFlightRecording...OOM 触发JVM 不退出HeapDumpOnOutOfMemoryError会先落 dump事后复盘 JFRjfr print --events jdk.GCHeapSummary recording.jfr看堆增长曲线jfr print --events jdk.ObjectAllocationSample recording.jfr看分配热点用 JMC 打开关联时间线取 dump 用 MAT 分析找 GC Root 链定位泄漏点JFR dump 结合dump 告诉你在哪里泄漏JFR 告诉你是从什么时候开始泄漏的。工作流 2CPU 100% 排查抓 30 秒 JFRjcmd pid JFR.start duration30s filename/tmp/cpu.jfrJMC 火焰图找最宽的方法排除 GC 抢 CPUjfr print --events jdk.GarbageCollection recording.jfr查线程 CPU 分布看jdk.ThreadCPULoad事件配合 jstackjcmd pid Thread.print看是否死循环栈帧固定。工作流 3死锁 / 锁竞争排查抓 30 秒 JFR查锁等待jfr print --events jdk.JavaMonitorEnter recording.jfr按等待时长排序找到最长的锁等待关联线程栈用jdk.ExecutionSample看线程在哪个方法里等锁配合 jstackjcmd pid Thread.print检查Found Java deadlock。工作流 4高频 GC 排查抓 30 秒 JFR查 GC 事件jfr print --events jdk.GarbageCollection recording.jfr查触发原因字段是Allocation Rate、System.gc()还是Metaspace查 GC 前后堆占用jdk.GCHeapSummary看老年代是否回落查分配热点jdk.ObjectAllocationSample找谁在分配决策老年代不回落 → 内存泄漏取 dump 分析分配过快 → 优化代码减少分配System.gc()→ 加-XX:DisableExplicitGC。JFR 配置模板模板 1临时排障30 秒-XX:StartFlightRecordingduration30s,filename/tmp/r.jfr,settingsprofile模板 2生产 Always-On-XX:StartFlightRecordingfilename/var/log/jfr/app.jfr,maxage1h,maxsize100M,settingsprofile,disktrue -XX:FlightRecorderOptionsstackdepth64模板 3低开销监控-XX:StartFlightRecordingfilename/var/log/jfr/app.jfr,maxage24h,maxsize500M,settingsdefault -XX:FlightRecorderOptionsstackdepth32settingsdefault相比profile采样率更低、开销更小适合长期监控场景——maxage/maxsize 拉长到 24h/500M 后相当于用低开销换取一整天的完整事件窗口。在 agent-core-java 项目中的落地要点JDK 17 基线本仓库以 JDK 17 编译运行见 core/pom.xmlJFR 相关能力jdk.jfrAPI、jfr命令、-XX:StartFlightRecording全部可用。仓库通过反射方式兼容 JDK 21 的虚拟线程能力见 VirtualThreadSupport.javaJDK 17 上自动回退到平台线程这意味着排障时既要关注平台线程的状态也需了解运行在 JDK 21 上时虚拟线程不占用原生线程上限这一差异。容器环境注意若 agent-core-java 以 K8s/Docker 方式部署JFR 的落盘与采集有专门注意事项详见 container_troubleshooting.mdJFR 写盘路径必须挂载 PVC / hostPath否则容器重启后.jfr文件丢失JRE-only 精简镜像没有jcmd工具但 JFR 内置于 JVM启动时配置-XX:StartFlightRecording即可绕过工具缺失问题——这也是容器场景推荐 JFR 的核心原因容器主进程为 PID 1 时采集命令统一写为jcmd 1 JFR.start ...。与技能库其他文档的配合本篇对应技能库中的 JFR 事后分析分支references/jfr_analysis.md。事故发生时先按 SKILL.md 的“症状速查表”跳转定位命令输出字段含义不清楚时查阅 diagnostic_commands.mdGC 类问题配合 gc_tuning_guide.md 的响应式诊断视角完整端到端案例见 troubleshooting_cases.md堆泄漏 / CPU 100% / 死锁 / Metaspace 泄漏四个案例。此外主动式性能优化GC 选型、JVM 参数选择、JMH 基准测试与 JFR 常开组合属于 performance-tuning 技能范畴可参考 jmh_profiling.md——排障解决的是“已经出事怎么办”性能调优解决的是“如何避免出事”二者边界清晰、互为补充。参考与深入阅读主入口jvm-troubleshoot/SKILL.md按症状跳转诊断命令细节diagnostic_commands.mdjcmd/jstack/jmap 输出字段GC 排障gc_tuning_guide.md响应式诊断视角容器排障container_troubleshooting.md容器内 JFR 落盘与采集配置实战案例troubleshooting_cases.md堆泄漏 / CPU 100% / 死锁 / Metaspace 泄漏四个端到端案例主动式 JMH JFRjmh_profiling.md基准测试 JFR 生产常开项目构建基线core/pom.xmlJDK 17 编译与运行约束赞分享人工智能AI AgentAgent 框架工具调用Agent 工作流RAGMCP Clients强化学习【免费下载链接】agent-core-javaopenJiuwen agent core Java是 openJiuwen Core的 Java版本提供AI Agent开发、运行、调优与演进相关的全套SDK能力。项目地址https://gitcode.com/openJiuwen/agent-core-java点击查看免费下载相关推荐openJiuwen agent-core-java 生产环境 GC 排障实战指南从症状识别到根因定位openJiuwen agent core java 生产环境 GC 排障实战指南从症状识别到根因定位 本篇技术指南以仓库内 jvm troubleshoot人工智能AI AgentAgent 框架工具调用Agent 工作流RAGMCP Clients强化学习PyTorch Flight Recorder 实战指南定位分布式训练卡死任务的根因PyTorch Flight Recorder 实战指南定位分布式训练卡死任务的根因 导读 分布式训练中作业长时间无法取得有意义的进展——即卡死stu示例工程GraalVM Native Image 中的 JDK Flight RecorderJFR使用指南构建、配置与事件采集GraalVM Native Image 中的 JDK Flight RecorderJFR使用指南构建、配置与事件采集 JDK Flight Recor编译器JIT编译语言运行时高性能计算内存管理上一篇掌握Windows与Office智能激活KMS_VL_ALL_AIO技术深度解析下一篇3分钟完成Windows和Office永久激活KMS_VL_ALL_AIO智能脚本完整指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
