jps查不到进程是因为它依赖/tmp/hsperfdata_$user/下以pid命名的文件，若该目录权限异常、被清理、挂载限制、用户不匹配或jvm禁用attach机制，jps即失效；而ps命令仍可查到，因其基于系统进程快照。
jps 是最直接、最轻量的方式，但它的输出默认不带路径和参数，容易混淆服务——尤其在微服务集群里一堆 Bootstrap、Launcher、jar 的场景下，单看 jps 结果根本分不清哪个 PID 对应哪个服务。
为什么 jps 经常查不到进程？
它依赖 /tmp/hsperfdata_$USER/ 目录下的 PID 文件（每个 Java 进程启动时写一个以 PID 命名的空文件）。如果出现以下任一情况，jps 就会“失明”：
- 磁盘满或
/tmp被挂载为noexec或nosuid - Java 进程以其他用户身份启动（比如
root启的，你用普通用户跑jps） - 运维脚本或容器清理逻辑误删了
/tmp/hsperfdata_*目录 - 使用了
-XX:+DisableAttachMechanismJVM 参数（显式禁用 attach）
此时 ps -ef | grep java 仍能查到，因为它是纯进程快照，不依赖 JVM 内部机制。
Java Maven Common
下载
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
jps -l 和 jps -v 必须搭配用
jps -l 显示完整 jar 路径或主类全限定名，能区分同名 Bootstrap；jps -v 显示 JVM 启动参数（比如 -Xms2g -Xmx4g -Dspring.profiles.active=prod），对排查配置错误极有用。但注意：
-
jps -v可能因权限不足报Could not attach to process，尤其是容器中非 root 用户运行时 -
jps -l对 Spring Boot Fat Jar 输出的是org.springframework.boot.loader.JarLauncher，不是你的主类，得结合java -jar xxx.jar --help或看 MANIFEST.MF 确认 - 两者都只查当前用户，跨用户必须用
sudo ps -u otheruser -f | grep java
生产环境推荐组合命令
别只信 jps，用这几条快速定位真实服务：
- 查所有 Java 进程 + 完整命令行：
ps auxww | grep java | grep -v grep（auxww防止参数被截断） - 按内存排序看谁吃得多：
top -o %MEM -c -p $(pgrep java | tr '\n' ',' | sed 's/,$//') - 确认某 PID 是否真为 Java：
readlink -f /proc/<pid>/exe</pid>—— 如果指向java或jdk-*/bin/java才算数，避免误把python脚本当 Java 进程 - 容器内查不到？优先看
cat /proc/1/cmdline | tr '\0' ' '（很多 Java 应用在容器里 PID 1 就是 java 进程）
真正麻烦的不是“怎么查”，而是查出来一堆 jar、Bootstrap、Jps 后，还得靠路径、端口、日志目录反推——这些信息 jps 本身不提供，得靠你提前约定好部署规范或用 jinfo -sysprops <pid></pid> 挖系统属性。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
