ProcessHandle 本身不提供优雅回收，需子进程自行响应 SIGTERM 等信号完成清理；destroy() 发送 SIGKILL/TerminateProcess 强制终止，无法执行 shutdown hook；应优先用 destroy()（Linux/macOS 发 SIGTERM）并确保子进程捕获信号，Windows 无等效机制；后代进程需用 descendants() 遍历管理，避免孤儿进程；须持 ProcessHandle 引用调用 isAlive() 判断活性，禁用 PID 轮询；所有方法均可能抛 CompletionException，生产环境必须捕获。
ProcessHandle 本身不提供“优雅回收”能力，它只负责识别和控制本机进程；真正的优雅回收必须由子进程自身响应信号（如 SIGTERM）并完成清理，Java 层只能触发、等待、判断——这点不搞清，后续所有操作都会误入歧途。
为什么 destroy() 不等于优雅退出
ProcessHandle.destroy() 发送的是 SIGKILL（Unix/Linux）或 TerminateProcess（Windows），操作系统强制终止，子进程没机会执行 shutdown hook、关闭文件句柄、释放锁或 flush 缓冲区。
常见错误现象：destroy() 后磁盘文件写入不全、数据库连接未关闭、临时目录残留、端口被占用无法重用。
真正需要的是：ProcessHandle.destroyForcibly() 仅作兜底，主路径应先调用 destroy()（注意：此处的 destroy() 在 ProcessHandle 中实际发送的是 SIGTERM，但行为依赖底层实现和子进程是否捕获该信号）——等等，这里有个关键陷阱：
- Java 9+ 的
ProcessHandle.destroy()在 Linux/macOS 上确实尝试发SIGTERM，但 Windows 上仍等价于TerminateProcess（无信号机制） - 子进程是否响应
SIGTERM完全取决于它自己——比如 Python 脚本要显式注册signal.signal(signal.SIGTERM, handler)，Node.js 需监听process.on('SIGTERM', ...) - 没有统一跨平台的“发送可被捕获的终止信号”API，
ProcessHandle不封装信号抽象层
如何组合使用 children() + onExit() 实现树状资源观察
子进程可能派生孙子进程（如 shell 脚本调用 ffmpeg 再 fork 出编码线程），仅 kill 直接子进程会导致孤儿进程泄漏。
正确做法是主动遍历后代，并为每个进程绑定生命周期钩子：
- 用
ProcessHandle.descendants()获取全部后代，而非仅children()（后者只返回一级子进程） -
onExit()返回CompletableFuture<processhandle></processhandle>，但注意：它只在进程**已终止**时完成，不保证你能在其退出前做任何事；想“退出前清理”，必须靠子进程自己实现 - 典型误用：
process.onExit().thenRun(() -> cleanupResources())—— 这里的cleanupResources()是 Java 当前进程做的事，不是子进程做的；若子进程退出时已损坏状态（如崩溃），这个回调毫无意义 - 推荐模式：启动后立即用
descendants()快照当前树，定期 diff 或配合ProcessHandle.allProcesses()扫描残留（注意性能开销）
避免 PID 复用导致的竞态问题
操作系统会复用 PID，ProcessHandle 对象一旦失效（进程退出），其 pid() 值可能被新进程占用。
直接缓存 PID 整数并后续轮询检查，大概率误杀或漏杀：
- 不要用
long pid = handle.pid(); ... if (ProcessHandle.of(pid).isPresent()) { ... }判断活跃性——这无法区分是原进程还是新进程 - 正确方式：始终持有
ProcessHandle引用，用handle.isAlive()检查（它内部做了原子状态校验） -
ProcessHandle.of(pid)应仅用于从外部获取 PID 后的初始接入（如监控日志里提取的 PID），且必须立刻检查isAlive()并绑定onExit() - 对长期运行的子进程管理，建议用
ProcessHandle.info().command()+startInstant()辅助做身份确认，降低误判概率
最易被忽略的一点：ProcessHandle 的所有方法（包括 isAlive()、info()）都可能抛出 java.util.concurrent.CompletableFuture.CompletionException 包裹的底层系统错误（如权限不足、进程已不存在），但文档没强制要求 try-catch——生产环境务必包裹处理，否则静默失败。
