JDK jinfo 命令深度解析查询与修改运行中 Java 进程的系统属性与 JVM 参数【免费下载链接】jdkJDK main-line development https://openjdk.org/projects/jdk项目地址: https://gitcode.com/GitHub_Trending/jd/jdkjinfo是 JDK 随附的诊断命令之一用于在不重启目标 JVM 的前提下查看甚至动态修改其 Java 系统属性与命令行标志。本文基于 JDK 仓库中jinfo命令的官方手册页man page源文件 src/jdk.jcmd/share/man/jinfo.md 展开完整继承其命令语法、选项与平台限制说明并结合仓库中该命令的实际实现源码——入口类 JInfo.java、进程匹配器 ProcessArgumentMatcher.java、Attach 通信层 HotSpotVirtualMachine.java 以及 HotSpot 服务端 attachListener.cpp——剖析每个选项背后真实的调用链。读完本文你既能照文档正确地在生产环境中使用jinfo也能从源码层面理解它如何通过 Attach 机制与目标 JVM 通信、哪些操作是受限的、以及报错信息从何而来。命令定位实验性、不受支持的诊断工具手册页的 Name 节对jinfo的定义是jinfo - generate Java configuration information for a specified Java process为指定的 Java 进程生成 Java 配置信息。配置信息包含两大类内容Java 系统属性Java System Properties与JVM 命令行标志JVM command-line flags。需要特别注意手册页在 Synopsis 节的醒目标注Note:This command is experimental and unsupported.该命令是实验性的且不受支持unsupported且“可能在 JDK 的后续版本中不再提供”。这并非客套话而是影响使用决策的事实边界jinfo的功能与报错格式可能随版本变化关键生产场景下不宜将其写入不可控的自动化脚本核心路径同族的 jcmd.md 等命令文档可以说明jcmd是目前官方更推荐的功能等价物jinfo的大部分查询能力都可以用jcmd pid VM.flags、VM.system_properties、VM.command_line完成下文源码部分会看到二者共享同一底层通道。用法Synopsisjinfo [option] pid只有两个位置参数要素参数含义optionjinfo的命令行选项见下文“选项一览”pid目标 Java 进程的进程 ID必须是 Java 进程。要列出本机正在运行的 Java 进程可以使用ps命令或者在 JVM 进程未运行于独立 docker 实例中时使用 jps 命令手册页特别点出 docker 场景如果目标 JVM 运行在单独的容器里宿主机上的jps列不到它需要在目标容器内执行。选项一览手册页给出了如下选项。先说明一个总原则如果不使用下列任何选项jinfo会同时打印命令行标志和系统属性键值对详见后文默认行为小节。选项作用-flag name打印指定命令行标志的名称与值-flag [|-]name启用或禁用-指定的布尔型命令行标志-flag namevalue将指定的命令行标志设置为给定值-flags打印传递给 JVM 的全部命令行标志-sysprops以键值对形式打印 Java 系统属性-h或-help打印帮助信息从源码看这几个选项与手册页一一对应JInfo.java 的参数解析循环只识别-flag、-flags、-sysprops三类功能选项以及-?、-h、--help、-help其中-help被标注为 “legacy” 遗留别名四类帮助选项。值得注意的是帮助选项在源码中比手册页多认一个--help形式。三个-flag变体在实现中收敛为对同一个flag()方法的不同调用其分派逻辑是JInfo.javaint index option.indexOf(); if (index ! -1) { flag option.substring(0, index); String value option.substring(index 1); in vm.setFlag(flag, value); // 形式三-flag namevalue } else { char c option.charAt(0); switch (c) { case : in vm.setFlag(flag, 1); break; // 形式二name布尔置真 case -: in vm.setFlag(flag, 0); break; // 形式二-name布尔置假 default: in vm.printFlag(flag); break; // 形式一只读打印 } }也就是说-flag name/-flag -name在底层等价于setFlag(name, 1/0)-flag name则走只读通道printFlag(name)。无选项时的默认行为手册页之外的第三类输出手册页说“不使用任何选项时同时打印命令行标志与系统属性键值对”。而源码里的默认分支还多做了一件事JInfo.javaif (!doFlag !doFlags !doSysprops) { sysprops(pid); // Java System Properties flags(pid); // VM Flags commandLine(pid); // VM.command_line —— 额外打印目标 JVM 的启动命令行 }因此裸执行jinfo pid时实际输出三段Java System Properties:、VM Flags:以及紧随其后的目标 JVM 原始启动命令行通过VM.command_line诊断命令获得。这一“附赠”输出在排查“这个进程到底是用什么参数启动的”时非常实用。平台限制与前置条件手册页 Description 节列出的三条限制是使用前必须核对的环境事实Windows 依赖调试器支持在缺少dbgeng.dll的 Windows 系统上必须安装Debugging Tools for Windows这些工具才能工作PATH需包含jvm.dllPATH环境变量应包含目标进程所使用的jvm.dll的位置或包含 core dump 文件来源的位置临时目录必须一致-XX:AltTempDir如果目标 JVM 是以非默认临时目录启动的jinfo必须使用同一个临时目录才能与之通信默认情况下二者一致所以不受影响。从源码结构看第 3 条的原理在于 Attach 通信依赖目标 JVM 在临时目录下建立的标识文件。ProcessArgumentMatcher.java 的注释明确提到了这一机制// If this is the case, then the /tmp/hsperfdata_xxx/pid file // will have disappeared and we will get a NullPointerException.即工具通过/tmp/hsperfdata_用户/下的pid文件识别 Java 进程这正是hsperfdata机制。若目标进程用-XX:AltTempDir把该目录挪到了别处工具在默认目录下既找不到进程标识、也无法送达 Attach 请求这就是手册页强调“必须使用相同临时目录”的根因。实操示例以下示例假定本机有一个正在运行的 Java 进程PID 为pid可用jps或ps获取。打印全部配置默认行为三段输出jinfo pid查看单个标志jinfo -flag MaxHeapSize pid # 典型输出MaxHeapSize字节数查看全部 JVM 标志 / 全部系统属性jinfo -flags pid # 输出以 VM Flags: 开头 jinfo -sysprops pid # 输出以 Java System Properties: 开头动态修改运行中的进程jinfo -flag MaxHeapSize2g pid # 将数值型标志设为新值 jinfo -flag PrintGCDetails pid # 启用布尔标志 jinfo -flag -PrintGCDetails pid # 禁用布尔标志关于动态修改的边界HotSpot 服务端会校验标志的可写性。attachListener.cpp 中set_flag的实现调用WriteableFlags::set_flag(..., JVMFlagOrigin::ATTACH_ON_DEMAND, ...)若标志被标记为不可写返回JVMFlag::NON_WRITABLE工具侧即收到flag %s cannot be changed的报错标志不存在时print_flag则返回no such flag %sattachListener.cpp。换句话说能否jinfo -flag修改某个参数取决于该参数在 HotSpot 中的JVM_FLAG声明是否带可写属性而非jinfo本身的行为。帮助jinfo -h帮助文本由 JInfo.java 的usage()打印除手册页所列选项外还展示了用法形式jinfo option pid (to connect to a running process)。源码实现原理入口与参数解析jinfo的入口是 JInfo.java 的main方法流程为无参数→ 直接打印 usage 并以退出码 1 结束checkForUnsupportedOptionsL210-L237专门检测旧版 SAServiceability Agent用法。出现-F选项或-flag之外的非选项参数超过 1 个时报错退出并提示Cannot connect to core dump or remote debug server. Use jhsdb jinfo instead这是手册页没有明说、但对排查老脚本很有用的信息早期jinfo可以附加到 core dump 或远程调试服务器SA 模式该能力已从jinfo移除迁移到了jhsdb jinfo选项解析循环消费以-开头的参数识别功能选项与帮助选项PID 校验选项之后必须恰好剩下 1 个非选项参数L95-L100否则 usage 退出进程匹配与执行将 PID 传给ProcessArgumentMatcher解析随后按选项分派到sysprops/flags/commandLine/flag。进程匹配不只是裸 PIDProcessArgumentMatcher源码对参数做二分处理参数能解析为非零整数→ 视为精确 PIDsinglePid此时甚至跳过 AttachProvider 的进程列表直接返回该 PID——源码注释说明这是因为“当 VM 处于 debuggee-suspended 状态时 AttachProvider 不会列出它”L151-L159否则视为主类名的模糊匹配串遍历VirtualMachine.list()列出的所有 Java 进程用ProcessHelper.getMainClass平台相关实现或回退到jvmstat的MonitoredVmUtil.mainClass取得各进程主类做子串匹配并排除jinfo工具自身。匹配到多个进程时main会为每个 PID 的输出加一行Pid:pid前缀JInfo.java一个都没匹配到时打印Could not find any processes matching : ...并退出码 1。匹配阶段的失败路径也值得注意注释中解释了目标 JVM 在查询途中退出时hsperfdata文件消失会触发 NPE被特意捕获为“正常不匹配”ProcessArgumentMatcher.java这是对工具与目标进程生命周期竞态的显式处理。Attach 通道jinfo 与 jcmd 共用同一底层jinfo的每个功能最终都落在 HotSpotVirtualMachine 的三类方法上jinfo 功能调用发往目标 VM 的命令-flag name打印vm.printFlag(name)L309-L311printflag name-flag namevalue//-vm.setFlag(name, value)L304-L306setflag name value-flagsvm.executeJCmd(VM.flags)jcmd VM.flags-syspropsvm.executeJCmd(VM.system_properties)jcmd VM.system_properties默认行为附带的命令行vm.executeJCmd(VM.command_line)jcmd VM.command_lineexecuteJCmd的实现就是把参数包成executeCommand(jcmd, command)L313-L315——这正是“jinfo 的查询能力可以用 jcmd 等价替代”的源码级依据。输出读取由 JInfo.java 的drain()完成以 UTF-8 把目标 VM 的响应流抽干打印到 stdout随后vm.detach()断开连接。两个可配置的行为开关来自 HotSpotVirtualMachine 的静态初始化jdk.attach.allowAttachSelf默认允许是否允许附加到自身进程自附加时流式输出会被强制禁用L416-L422jdk.attach.allowStreamingOutput默认允许是否启用流式输出影响大输出场景如海量标志的读取方式附加超时sun.tools.attach.attachTimeout毫秒默认 10000msL606-L633目标进程长期无响应时可据此调整等待。此外工具端在建立通信前会先发送getversion探测目标 VM 支持的 Attach 协议版本v1/v2与streaming选项L371-L403版本不匹配时目标端返回固定错误码工具端会抛出Protocol mismatch with target VML481-L511——用旧 JDK 的jinfo操作新 JVM或反之出现该报错时原因即在于此。HotSpot 服务端命令分派表目标 JVM 一侧Attach Listener 线程维护一张命令分派表attachListener.cppstatic AttachOperationFunctionInfo funcs[] { { agentProperties, get_agent_properties }, { datadump, data_dump }, { dumpheap, dump_heap }, { load, load_agent }, { properties, get_system_properties }, { threaddump, thread_dump }, { inspectheap, heap_inspection }, { setflag, set_flag }, { printflag, print_flag }, { jcmd, jcmd }, { getversion, get_version }, { nullptr, nullptr } };setflag/printflag两个jinfo专用入口与jcmd入口并列存在说明jinfo并非独立机制而是 Attach Listener 命令集的一个消费方。print_flag通过JVMFlag::find_flag(name)在全局标志表中查找并以print_as_flag格式化输出set_flag则要求标志可写来源标记为JVMFlagOrigin::ATTACH_ON_DEMAND即“attach 时按需设置”这一来源标记会被 HotSpot 记录在标志的 origin 中后续用-flag读回时可以看到该标志是被 attach 修改过的。边界行为与常见报错对照把手册页与源码结合起来可以整理出以下可预期的行为边界便于排错时快速定位现象原因源码依据Usage: jinfo option pid ...且退出码 1无参数、选项后缺少参数、或选项外参数多于 1 个JInfo.javaCould not find any processes matching : ...PID 不是 Java 进程或类名模糊匹配失败L105-L108Error: -F option used/Cannot connect to core dump or remote debug server. Use jhsdb jinfo instead使用了已移除的 SA 模式选项L210-L237pid: attach 失败信息VirtualMachine.attach(pid)抛异常逐字打印消息后退出attach 方法常见于权限不足、跨用户、容器隔离、或AltTempDir不一致flag %s cannot be changed目标标志不可写attachListener.cppno such flag %s标志名拼写错误或该版本不存在此标志Protocol mismatch with target VM工具与目标 JVM 的 Attach 协议版本不兼容HotSpotVirtualMachine.java相关工具与延伸jinfo与同目录手册页中的 jcmd、jps、jmap、jstack、jstat 同属 JDK 诊断命令族共享同一套 Attach 基础设施。结合本文的源码分析可以给出三条实用选型结论列进程jps或ps配合jinfo pid使用查询配置jinfo -flags/-sysprops与jcmd pid VM.flags/VM.system_properties等价后者属于受支持的诊断命令接口动态改标志jinfo -flag与jcmd pid VM.set_flag namevalue走同一条setflag通道可写性约束完全一致。最后重申适用前提jinfo定位为实验性、不受支持的命令其可用性与形态可能随 JDK 版本演进变化涉及对生产系统的长期诊断与自动化建议以jcmd/jhsdb为主、jinfo为辅助对照手段。【免费下载链接】jdkJDK main-line development https://openjdk.org/projects/jdk项目地址: https://gitcode.com/GitHub_Trending/jd/jdk创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
