Arthas dashboard 命令详解实时监控 JVM 线程、内存、GC 与 Tomcat 状态【免费下载链接】arthasAlibaba Java Diagnostic Tool Arthas/Alibaba Java诊断利器Arthas项目地址: https://gitcode.com/gh_mirrors/ar/arthasdashboard 是 ArthasAlibaba Java Diagnostic Tool中最直观的实时监控命令它以定时刷新的控制台面板形式一屏呈现目标 JVM 的线程 CPU 占用、内存分区使用、GC 统计与运行时环境信息。本文以site/docs/en/doc/dashboard.md为核心骨架结合 core 模块源码 逐层拆解其输出含义、参数用法与底层实现原理帮助你快速定位线程热点、内存压力和 GC 异常。Arthas dashboard 命令实时面板dashboard 命令是什么dashboard 是当前 JVM 的实时统计面板进入该面板后会按固定时间间隔持续刷新输出直到你按下CtrlC或输入q退出。它面向的典型场景包括快速查看哪些线程正在消耗 CPU定位高负载线程观察heap / metaspace / code cache 等内存区域的使用率初步判断是否存在内存压力查看GC 次数与 GC 耗时判断收集器行为是否异常当运行在 Apache Tomcat阿里巴巴定制版上时还能额外展示QPS、RT、错误数、线程池等 Tomcat 实时统计。与thread命令的单次快照不同dashboard 通过持续采样两次采样点之间的 CPU 增量给出“实时 CPU 占比”这一动态指标更适合做一段时间的连续观察。命令选项与参数dashboard 仅支持两个参数均在 DashboardCommand.java 中通过注解声明名称说明[i:]两次执行刷新之间的时间间隔单位为毫秒默认 5000 ms。[n:]该命令总共执行的次数。对应源码中的默认值定义DashboardCommand.javaprivate int numOfExecutions Integer.MAX_VALUE; // -n 不指定时无限执行直到 CtrlC private long interval 5000; // -i 不指定时每 5 秒刷新一次常用用法$ dashboard # 每 5 秒刷新一次持续显示CtrlC 退出 $ dashboard -n 10 # 只执行 10 次后自动结束 $ dashboard -i 2000 # 每 2 秒刷新一次命令自带的使用说明Description部分同样给出了这三个示例可直接在 Arthas 中执行help dashboard查看。注意-n执行完指定次数后进程会自动结束并提示Process ends after N time(s).无需手动中断见 DashboardTimerTask.run()。基本使用与输出全解析执行dashboard后面板默认分为四个区域线程列表上半部分、Memory、GC下半部分左半区以及Runtime / Tomcat下半部分右半区。典型的输出如下$ dashboard ID NAME GROUP PRIORITY STATE %CPU DELTA_TIME TIME INTERRUPTE DAEMON -1 C2 CompilerThread0 - -1 - 1.55 0.077 0:8.684 false true 53 Timer-for-arthas-dashboard-07b system 5 RUNNABLE 0.08 0.004 0:0.004 false true 22 scheduling-1 main 5 TIMED_WAI 0.06 0.003 0:0.287 false false -1 C1 CompilerThread0 - -1 - 0.06 0.003 0:2.171 false true -1 VM Periodic Task Thread - -1 - 0.03 0.001 0:0.092 false true 49 arthas-NettyHttpTelnetBootstra system 5 RUNNABLE 0.02 0.001 0:0.156 false true 16 Catalina-utility-1 main 1 TIMED_WAI 0.0 0.000 0:0.029 false false -1 G1 Young RemSet Sampling - -1 - 0.0 0.000 0:0.019 false true 17 Catalina-utility-2 main 1 WAITING 0.0 0.000 0:0.025 false false 34 http-nio-8080-ClientPoller main 5 RUNNABLE 0.0 0.000 0:0.016 false true 23 http-nio-8080-BlockPoller main 5 RUNNABLE 0.0 0.000 0:0.011 false true -1 VM Thread - -1 - 0.0 0.000 0:0.032 false true -1 Service Thread - -1 - 0.0 0.000 0:0.006 false true -1 GC Thread#5 - -1 - 0.0 0.000 0:0.043 false true Memory used total max usage GC heap 36M 70M 4096M 0.90% gc.g1_young_generation.count 12 g1_eden_space 6M 18M -1 33.33% 86 g1_old_gen 30M 50M 4096M 0.74% gc.g1_old_generation.count 0 g1_survivor_space 491K 2048K -1 24.01% gc.g1_old_generation.time(ms) 0 nonheap 66M 69M -1 96.56% codeheap_non-nmethods 1M 2M 5M 22.39% metaspace 46M 47M -1 98.01% Runtime os.name Mac OS X os.version 10.15.4 java.version 15 java.home /Library/Java/JavaVirtualMachines/jdk-15.jdk/Contents/Home systemload.average 10.68 processors 8 uptime 272sMemory 区字段字段含义used该内存区域当前已使用量total当前已分配committed给 JVM 的量max最大可用的量-1表示该区域没有上限如 eden、survivor、metaspaceusageused / max 的使用率百分比Memory 数据来源于 MemoryCommand.memoryInfo() 的复用可对照memory命令查看更完整的区域列表。GC 统计则来自 JVM 的GarbageCollectorMXBean见 addGcInfo()格式为gc.收集器名.count次数与gc.收集器名.time(ms)累计耗时例如 G1 收集器下的gc.g1_young_generation.count。Runtime 区字段字段含义os.name/os.version操作系统名称与版本java.version/java.homeJDK 版本与安装路径systemload.average系统最近 1 分钟平均负载processorsJVM 可用的处理器核心数uptimeJVM 已运行秒数这些值来自 addRuntimeInfo()操作系统属性取自System.getProperty负载与 uptime 取自OperatingSystemMXBean/RuntimeMXBean处理器数来自Runtime.getRuntime().availableProcessors()。线程列表列头含义IDJVM 线程 ID。请注意它与jstack中的nativeID不是同一个值。NAME线程名称。GROUP线程组名称。PRIORITY线程优先级取值范围 110数值越大优先级越高。STATE线程状态RUNNABLE、TIMED_WAITING、WAITING、BLOCKED 等。CPU%线程的 CPU 占用率。例如采样间隔为 1000ms某线程在间隔内 CPU 增量时间为 100ms则占用率 100 / 1000 10%。DELTA_TIME距上次采样以来线程 CPU 时间的增量单位为秒。TIME线程累计 CPU 总时间格式为分钟:秒。INTERRUPTED线程是否处于中断状态。DAEMON是否为守护线程。线程列表默认按 CPU 增量时间降序排列让最活跃的线程始终排在顶部排序逻辑见 ThreadSampler.sample()。JVM 内部线程观察 GC 与 JIT 的窗口Java 8 之后dashboard 可以获取JVM 内部线程的 CPU 时间。这些线程只有名称和 CPU 时间没有 ID 与状态信息因此列表中 ID 显示为-1、优先级显示为-1、状态显示为-。通过内部线程可以感知 JVM 的整体活动GC 相关当 JVM 堆 / metaspace 空间不足或发生 OOM 时可以看到 GC 线程的 CPU 占用明显高于其他线程——这是内存压力的早期信号。JIT 相关执行trace、watch、tt、redefine等命令之后可以看到 JIT 编译线程活动变得频繁。原因是 JVM 热更新类字节码时会清除与该类相关的 JIT 编译数据需要重新编译从而带动 JIT 线程 CPU 上升。JVM 内部线程主要包括JIT 编译线程如C1 CompilerThread0、C2 CompilerThread0GC 线程如GC Thread0、G1 Young RemSet Sampling其他内部线程如VM Periodic Task Thread、VM Thread、Service Thread从源码看内部线程的 CPU 时间通过 HotSpot 专有的HotspotThreadMBean.getInternalThreadCpuTimes()获取获取失败时该能力会被自动降级关闭见 ThreadSampler.getInternalThreadCpuTimes()内部线程条目由 createThreadVO() 构造ID 固定为 -1 且标记为守护线程。Tomcat 实时统计阿里定制版当目标进程运行在 Apache Tomcat Alibaba 定制版上时dashboard 会额外展示 Tomcat 的实时统计QPS每秒请求数、RT平均响应时间、错误数以及线程池busy 忙线程数 / total 总线程数。其底层通过向本机 Tomcat 管理端口发起 HTTP 请求获取数据addTomcatInfo()http://localhost:8006/connector/stats # Connector 统计请求数、错误数、收发字节、处理时间 http://localhost:8006/connector/threadpool # 线程池统计busy 线程与总线程数如果请求http://localhost:8006失败则不显示 Tomcat 信息不会报错。QPS、错误率、收发速率等基于SumRateCounter计算相邻两次采样之间的速率DashboardCommand.javaRT 则用processingTime / requestCount计算平均响应时间毫秒。底层实现定时调度、CPU 采样与视图渲染dashboard 的实现遵循 Arthas 命令标准的Model View架构核心逻辑集中在三个文件1. 定时调度与生命周期管理DashboardCommand命令启动后创建守护线程Timer(Timer-for-arthas-dashboard-sessionId)并以scheduleAtFixedRate按-i指定的间隔反复执行采样任务process()。生命周期支持CtrlC通过DashboardInterruptHandler停止定时器退出q键通过QExitHandler从 stdin 退出会话挂起 / 恢复挂起时stop()取消定时器恢复时restart()重建并重新调度-n次数到达任务内自动timer.cancel()并结束进程。2. CPU 采样ThreadSamplerCPU% 的计算是 dashboard 的核心算法ThreadSampler.java首次采样记录每个线程的ThreadMXBean.getThreadCpuTime(id)快照与采样时刻System.nanoTime()只展示累计 TIME后续每次采样重新读取 CPU 时间计算增量delta newTime - lastTime用delta / (本次采样时刻 - 上次采样时刻)得出该采样周期的 CPU 占用率换算为百分比线程集合本身来自 ThreadUtil.getThreads()它从根 ThreadGroup 递归枚举全部存活线程再逐一封装为ThreadVO。首次采样由于没有上次快照CPU% 显示为空从第二次刷新起才出现真实的 CPU% 数值这正是示例输出中Timer-for-arthas-dashboard-07b等线程出现在列表顶部的原因——dashboard 自身的采样线程在工作。3. 面板布局DashboardView渲染逻辑在 DashboardView.java面板高度按终端尺寸动态分配——上半部分放线程 Top下半部分切分田字格左上是 Memory GC右下是 Runtime Tomcat终端较矮时优先保证 Memory 区至少 8 行以显示 metaspace 信息。不同区域的最大高度会互相让渡保证一屏内信息完整可见。4. 数据模型一次刷新的完整数据封装在DashboardModel线程列表、内存信息、GC 信息、Runtime 信息、Tomcat 信息五部分见 DashboardModel.java每个线程的字段定义见 ThreadVO.java。使用建议与注意事项先看 CPU% 排名连续观察 23 个周期CPU% 稳定靠前的线程即是热点线程可再用thread id查看其堆栈定位代码位置。配合 JVM 内部线程诊断GC 线程 CPU 飙升时及时执行memory、heapdump或检查 metaspace 配置执行trace/watch/tt/redefine后观察 JIT 线程活动是否符合预期。合理设置刷新间隔默认 5000ms 对生产环境友好需要更细粒度观察时可-i 1000甚至更小但注意采样本身会带来少量开销。限定执行次数在批处理或脚本场景参见 batch-support.md使用-n控制结束时机避免命令无限挂起。面板高度自适应终端窗口越大展示的线程越多缩小终端时面板会优先保证 Memory 与 Runtime 信息可见。Tomcat 统计仅在 Apache Tomcat Alibaba 定制版且 8006 管理端口可达时出现标准 Tomcat 或其它容器下该区域会自动隐藏属预期行为。延伸阅读commands.mdArthas 全部命令列表thread.md单次线程快照与堆栈分析memory.md内存区域详细查看vmoption.mdJVM 参数实时调整redefine.md / retransform.md类热更新可与 dashboard 中 JIT 线程观察相互印证【免费下载链接】arthasAlibaba Java Diagnostic Tool Arthas/Alibaba Java诊断利器Arthas项目地址: https://gitcode.com/gh_mirrors/ar/arthas创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考