即使7年过去了，我刚刚遇到这个问题，因为我正在运行SpringBoot应用程序，需要在开发期间启动webpack-dev-server，并需要在后端进程停止时杀死它。

我尝试使用Runtime.getRuntime()。addShutdownHook，但它在Windows 10上工作，但在Windows 7上不工作。

我已经将其更改为使用一个专门的线程来等待进程退出或用于InterruptedException，这似乎在两个Windows版本上都正确工作。

private void startWebpackDevServer() {
    String cmd = isWindows() ? "cmd /c gradlew webPackStart" : "gradlew webPackStart";
    logger.info("webpack dev-server " + cmd);

    Thread thread = new Thread(() -> {

        ProcessBuilder pb = new ProcessBuilder(cmd.split(" "));
        pb.redirectOutput(ProcessBuilder.Redirect.INHERIT);
        pb.redirectError(ProcessBuilder.Redirect.INHERIT);
        pb.directory(new File("."));

        Process process = null;
        try {
            // Start the node process
            process = pb.start();

            // Wait for the node process to quit (blocking)
            process.waitFor();

            // Ensure the node process is killed
            process.destroyForcibly();
            System.setProperty(WEBPACK_SERVER_PROPERTY, "true");
        } catch (InterruptedException | IOException e) {
            // Ensure the node process is killed.
            // InterruptedException is thrown when the main process exit.
            logger.info("killing webpack dev-server", e);
            if (process != null) {
                process.destroyForcibly();
            }
        }

    });

    thread.start();
}

以防它与任何人相关，当我从c++派生子进程中的JVM实例时，我可以让JVM实例在父进程完成后正确终止的唯一方法是执行以下操作。如果这不是最好的方法，希望有人能在评论中提供反馈。

1)在通过execv启动Java应用程序之前，在fork子进程上调用prctl(PR_SET_PDEATHSIG, SIGHUP)

2)在Java应用程序中添加一个shutdown钩子，轮询直到其父PID等于1，然后执行一个硬的Runtime.getRuntime().halt(0)。轮询是通过启动运行ps命令的单独shell来完成的(参见:如何在Linux上的Java或JRuby中找到我的PID ?)

130118年编辑:

这似乎不是一个可靠的解决方案。我仍然在努力理解发生的事情的细微差别，但在屏幕/SSH会话中运行这些应用程序时，有时仍然会遇到孤立的JVM进程。

Instead of polling for the PPID in the Java app, I simply had the shutdown hook perform cleanup followed by a hard halt as above. Then I made sure to invoke waitpid in the C++ parent app on the spawned child process when it was time to terminate everything. This seems to be a more robust solution, as the child process ensures that it terminates, while the parent uses existing references to make sure that its children terminate. Compare this to the previous solution which had the parent process terminate whenever it pleased, and had the children try to figure out if they had been orphaned before terminating.

通过在prctl()系统调用中指定PR_SET_PDEATHSIG选项，子进程可以要求内核在父进程死亡时传递SIGHUP(或其他信号)，就像这样:

prctl（PR_SET_PDEATHSIG， SIGHUP）;

详见man 2 prctl。

编辑:这是linux专用的

通过滥用终端控制和会话，我设法用3个进程实现了一个可移植的、非轮询的解决方案。

诀窍在于:

process A is started process A creates a pipe P (and never reads from it) process A forks into process B process B creates a new session process B allocates a virtual terminal for that new session process B installs SIGCHLD handler to die when the child exits process B sets a SIGPIPE handler process B forks into process C process C does whatever it needs (e.g. exec()s the unmodified binary or runs whatever logic) process B writes to pipe P (and blocks that way) process A wait()s on process B and exits when it dies

这种方式:

如果进程A死亡:进程B得到一个SIGPIPE并死亡 如果进程B死亡:进程A的wait()返回并死亡，进程C将得到一个SIGHUP(因为当一个连接终端的会话的会话领导者死亡时，前台进程组中的所有进程都会得到一个SIGHUP) 如果进程C死亡:进程B得到一个SIGCHLD并死亡，那么进程a也会死亡

缺点:

进程C不能处理SIGHUP 进程C将在不同的会话中运行 进程C不能使用会话/进程组API，因为这会破坏脆弱的设置 为每一个这样的操作创建一个终端并不是最好的主意

安装一个陷阱处理程序来捕获SIGINT，如果你的子进程还活着，它就会杀死它，尽管其他的帖子是正确的，它不会捕获SIGKILL。

以独占访问的方式打开一个.lockfile，并让子进程尝试打开它——如果打开成功，子进程应该退出

受到这里另一个答案的启发，我提出了以下全posix解决方案。一般思想是在父进程和子进程之间创建一个中间进程，其目的只有一个:注意父进程何时死亡，并显式地终止子进程。

当子进程中的代码无法修改时，这种解决方案非常有用。

int p[2];
pipe(p);
pid_t child = fork();
if (child == 0) {
    close(p[1]); // close write end of pipe
    setpgid(0, 0); // prevent ^C in parent from stopping this process
    child = fork();
    if (child == 0) {
        close(p[0]); // close read end of pipe (don't need it here)
        exec(...child process here...);
        exit(1);
    }
    read(p[0], 1); // returns when parent exits for any reason
    kill(child, 9);
    exit(1);
}

使用这种方法有两个小注意事项:

如果你故意杀死中间进程，那么当父进程死亡时，子进程不会被杀死。 如果子进程在父进程之前退出，那么中间进程将尝试杀死原来的子进程pid，该进程现在可以引用一个不同的进程。(这可以通过在中间过程中编写更多代码来解决。)

顺便说一句，我使用的实际代码是Python的。为了完整起见，这里是:

def run(*args):
    (r, w) = os.pipe()
    child = os.fork()
    if child == 0:
        os.close(w)
        os.setpgid(0, 0)
        child = os.fork()
        if child == 0:
            os.close(r)
            os.execl(args[0], *args)
            os._exit(1)
        os.read(r, 1)
        os.kill(child, 9)
        os._exit(1)
    os.close(r)