processhandle默认仅返回当前jvm直接启动的存活子进程，受用户权限、zombie状态、pid命名空间及平台限制；onexit()需强引用保持有效；cpu/内存等指标需原生接口获取；destroy()发sigterm，destroyforcibly()发sigkill。
ProcessHandle获取不到子进程？检查是否被Zombie或权限拦截
Java 9 引入的 ProcessHandle 默认只返回当前 JVM 启动的直接子进程，且无法穿透用户隔离（比如 Linux 上非同一 UID 的进程不可见）。常见现象是调用 ProcessHandle.allProcesses() 返回空或数量远少于 ps aux 结果。
- Linux/macOS 下需确保目标进程与 JVM 运行在同一用户下；root 启动的 Java 进程才能看到所有进程，普通用户只能看到自己启动的
- Windows 上一般无此限制，但若启用了“受限令牌”（如通过服务、UAC 提权环境），也会过滤掉部分进程
- Zombie 进程（已终止但父进程未 wait）不会出现在
ProcessHandle.allProcesses()中——它只枚举当前存活的进程 - 调用
ProcessHandle.current().children()前，确认子进程确实由当前 JVM 用Runtime.exec()或ProcessBuilder.start()启动，而非 shell 脚本间接派生（后者会丢失父子关系）
ProcessHandle.onExit() 不触发？注意引用丢失和 JVM 退出时机
onExit() 返回一个 CompletableFuture<processhandle></processhandle>，但它不是“自动监听”，而是依赖 GC 友好型弱引用机制：一旦 ProcessHandle 实例被回收，监听就失效。最常踩的坑是没保留对 handle 的强引用。
- 必须将
ProcessHandle存到类字段或集合中，不能仅作为局部变量调用onExit().thenAccept(...)后就丢弃 - 如果进程在 JVM 关闭前已退出，但主线程已结束且 handle 无强引用，回调可能永远不执行
-
onExit()不阻塞，也不保证回调线程——默认使用ForkJoinPool.commonPool()，若该池被关闭（如 Spring Boot 关闭钩子中），回调会静默失败 - 替代方案：用
process.waitFor()配合单独线程，或改用ProcessHandle.toHandle().getPid()+ 定期轮询ProcessHandle.of(pid)是否为 null
获取进程 CPU/内存信息失败？别指望 ProcessHandle.getInfo() 返回完整数据
ProcessHandle.Info 是只读快照，且跨平台支持极不均衡：Linux 上能拿到命令行、启动时间、用户；Windows 上多数字段为 Optional.empty()；macOS 更保守。尤其注意 CPU 和内存使用率根本不在 Info 中暴露。
-
ProcessHandle.Info.arguments()在 Windows 上通常为空，因 Win32 API 不提供标准方式获取其他进程完整参数（除非有 SeDebugPrivilege 权限） - 想读取内存占用？必须调用平台原生接口：
ProcessHandle.current().pid()拿到 pid，再用 JNA 或 JNI 调用/proc/[pid]/statm（Linux）或GetProcessMemoryInfo（Windows） -
ProcessHandle.children()和descendants()在容器环境（Docker/Podman）中行为异常：若容器未启用pid=host，子进程可能属于不同 PID namespace，ProcessHandle根本看不见
ProcessHandle.destroy() vs destroyForcibly() 区别在哪？看信号语义
两者都发 Unix 信号（Linux/macOS）或调用 Win32 API（Windows），但语义不同：destroy() 发 SIGTERM（Unix）或 CTRL_C_EVENT（Windows），给进程机会清理；destroyForcibly() 发 SIGKILL（Unix）或 TerminateProcess（Windows），立即终结。
立即学习“Java免费学习笔记（深入）”；
- Java 层不处理信号掩码，所以即使目标进程屏蔽了
SIGTERM，destroy()仍会返回 true，但实际可能无效——需后续用isAlive()确认 - Windows 上
destroy()对控制台程序有效，但对 GUI 进程常无响应（它不发送 WM_CLOSE）；此时必须用destroyForcibly() - 调用
destroyForcibly()后立刻调用waitFor()可能阻塞，因为内核清理资源需要时间；建议加超时，例如processHandle.waitFor(10, TimeUnit.SECONDS)
ProcessHandle 的设计哲学是“轻量快照+有限控制”，它不替代 ps、top 或系统级监控工具。真正要稳定管理外部进程，得接受它只是个入口，关键指标和强控制仍得靠平台适配层补足。
