Btrace

背景 本文记录的是 JDK 8 生产环境下的实践：线上出现问题时，在不改代码、不重启的前提下，用 BTrace attach 到运行中的 JVM，按条件过滤慢方法并持续输出。 BTrace 概念与相关文章的关系见 Java 领域知识关系图。 何时需要 BTrace（生产动机） 动机 说明 不能停机 滚动重启成本高或 SLA 不允许 保留故障现场 重启后偶现问题、特定请求参数、堆内对象态、当时流量下的慢调用往往 难以复现；需要在 故障仍在发生时 对当前 JVM 取样 观测而非热修 BTrace 用于 慢调用过滤、参数、耗时、调用路径 等可观测数据，不是用 agent 临时改业务逻辑修 Bug（机制上 agent 能改字节码，但 BTrace 产品侧用脚本校验限制为安全探针） 车联网协议解析 G4 因写 MySQL 偏慢导致 OOM、后迁移 InfluxDB 的完整案例见 物联网平台协议解析服务生产环境 OOM：MySQL 迁移 InfluxDB（职业叙事；本文偏工具用法）。 临时排查可配合 生产环境诊断工具选型（Arthas、JFR 等）；BTrace 适合 脚本化、持续输出 的采集。 安装 BTrace 不是单个原生二进制，而是 Java 工具发行包（压缩包 + shell 脚本 + JAR），运行时依赖本机 JDK。 从 GitHub Releases 下载 btrace-bin.tar.gz 或 .zip，解压后大致结构： ...

背景 生产环境曾运行在 JDK 8。线上出现问题时，用 BTrace attach 到运行中的 JVM：按条件过滤慢方法（例如耗时超过 9ms），持续输出，不改代码、不重启。 当时 JFR 仍是商业特性，attach 式动态追踪是可行且低成本的方案之一。本文先记录 JDK 8 时代的诉求与 BTrace 用法，其它 JDK 版本下的工具对照见文末章节。 JDK 8 时代 BTrace 在解决什么 从 BTrace 使用笔记 中的脚本可以看出，核心需求是： attach 到运行中的 JVM，不重启 按条件过滤慢方法（例如大于 9ms） 持续输出，而不是只看一次快照 必要时查看参数、返回值、调用栈 示例脚本（慢调用过滤 + 计数）： @OnMethod(clazz = "com.wiloon.package0.Class0", method = "method0", location = @Location(Kind.RETURN)) public static void printMethodRunTime(@ProbeClassName String probeClassName, @Duration long duration) { long d = duration / 1000000; if (d > 9) { i++; println("index: " + i + ", timestamp:" + timestamp("HH:mm:ss") + ", " + probeClassName + ", duration: " + d + " ms"); } } 执行方式： ...