개발수양록이 글은 JDK 25와 Linux 6.x를 기준으로 Java에서 외부 프로세스를 실행하는 코드를 작성할 때 주의해야 할 요소와 활용할 수 있는 라이브러리를 소개합니다.
이어서 Linux에서 JVM이 자식 프로세스를 만드는 방식인 posix_spawn() 함수와 JDK에 포함된 작은 실행 파일인 jspawnhelper의 동작, 큰 힙에서 나타나는 실행 지연, 실행 방식을 바꾸는 설정까지 살펴봅니다.
이 글의 실행 결과는 아래 환경에서 확인했습니다. 예제 코드는 GitHub 저장소에 있습니다.
| 항목 | 값 |
|---|---|
OS |
Ubuntu 24.04.4 LTS, 커널 6.17 |
아키텍처 |
x86-64 |
glibc |
2.39 |
JDK |
Temurin 25+36 |
zt-exec |
1.13.0 |
Apache Commons Exec |
1.6.0 |
JDK 기본 클래스로 외부 프로세스를 실행할 때의 주의점
ProcessBuilder와 Runtime.exec의 차이
Java 코드에서 실행한 외부 프로세스는 java.lang.Process 객체로 다룹니다. Process 객체는 ProcessBuilder.start()나 Runtime.exec()로 얻습니다. ProcessBuilder는 JDK 5.0(Java 1.5)에 추가되었고, Sun JDK의 Runtime.exec()도 이때부터 내부에서 ProcessBuilder에 위임하도록 바뀌었습니다. JDK 1.5.0-beta2의 소스를 확인한 당시 자료에도 이 구현이 나옵니다. OpenJDK 25의 Runtime 소스에서도 ProcessBuilder를 만들어 start()를 호출합니다. 따라서 두 API는 프로세스 생성 구현을 공유하며, 주요 차이는 실행 설정을 다루는 방법입니다.
새로 작성하는 코드에는 ProcessBuilder를 권장합니다. 이 클래스는 환경 변수와 작업 디렉터리, 출력 리다이렉트를 지정하는 더 편리한 API를 제공합니다. 이 글에서 다룰 출력 파이프 처리도 redirectOutput(), redirectError(), redirectErrorStream() 등으로 구성할 수 있습니다.
| 항목 | Runtime.exec() | ProcessBuilder |
|---|---|---|
실행 시점 |
|
설정을 구성한 뒤 |
명령과 인자 |
문자열 하나 또는 문자열 배열 |
인자를 구분한 가변 인자 또는 리스트 |
환경 변수 |
|
|
작업 디렉터리 |
오버로드의 인자로 전달 |
|
입출력 설정 |
리다이렉트와 표준 오류 병합을 설정하는 API 없음 |
|
특히 명령을 문자열 하나로 받는 Runtime.exec(String) 계열은 JDK 18부터 deprecated입니다. Runtime Javadoc은 이 메서드가 공백만으로 인자를 나누기 때문에 공백이 들어간 파일명 등을 잘못 처리할 수 있다고 설명합니다. 따옴표를 붙여도 셸처럼 인자를 묶어 주지 않습니다.
// 공백이 있는 파일명을 하나의 인자로 전달하지 못함
Runtime.getRuntime().exec("cat \"my file.txt\"");
// 두 방식 모두 파일명을 하나의 인자로 전달
Runtime.getRuntime().exec(new String[]{"cat", "my file.txt"});
new ProcessBuilder("cat", "my file.txt").start();ProcessBuilder 기본 옵션의 한계
Java에서는 다음과 같이 ProcessBuilder 클래스를 사용하는 몇 줄의 단순한 코드로 외부 프로세스를 실행할 수 있습니다.
ProcessBuilder 호출Process process = new ProcessBuilder("echo", "hello").start();
int exitCode = process.waitFor();
System.out.println("exit=" + exitCode);출력이 적고 금방 끝나는 echo hello에서는 이 코드가 문제없이 동작합니다.
하지만 출력이 많거나 표준 입력을 기다리거나 끝나지 않는 명령을 실행하면 이 코드는 멈출 수 있습니다.
표준 출력과 표준 오류의 파이프 처리
부모 프로세스가 읽지 않는 사이에 자식 프로세스가 표준 출력(stdout)이나 표준 오류(stderr) 파이프의 한정된 용량을 다 채우면, 자식 프로세스는 다음 쓰기에서 멈춥니다. 그런 상황을 막으려면 표준 출력과 표준 오류를 계속 소비하는 코드가 필요합니다. 다음 두 방법 중 하나를 써야 합니다.
-
별도의 스레드에서 표준 출력과 표준 오류의 스트림을 읽습니다.
-
두 출력을 구분해서 처리하거나 참조해야 한다면 스레드 두 개에서 각각 읽어야 합니다.
-
두 출력을 구분할 필요가 없다면 하나로 합쳐 스레드 하나에서 읽을 수도 있습니다.
-
-
해당 스트림을 읽을 필요가 없다면 파일, 부모의 출력,
/dev/null중 하나로 리다이렉트해야 합니다.
앞에서 나온 '기본 옵션으로 ProcessBuilder 호출' 코드는 위의 두 방법 중 어느 것도 쓰지 않았습니다.
이어지는 절에서 이 코드가 멈추는 과정을 예제로 재현하고 해결 방법을 설명합니다.
읽지 않은 파이프 버퍼가 부르는 교착
자식 프로세스의 표준 출력과 표준 오류는 ProcessBuilder에서도 기본값으로는 각각 별도의 파이프로 부모 프로세스에 전달됩니다. 부모가 파이프를 읽지 않으면 파이프 버퍼가 차고, 자식 프로세스는 쓰기를 마치지 못합니다.
waitFor()를 호출하지 않아도 이 문제는 생깁니다. 부모는 자식 프로세스 시작 후 이어지는 코드를 실행할 수 있지만, 자식 프로세스는 가득 찬 파이프에 쓰려는 write() 호출이 블록되어 작업을 마치지 못할 수 있습니다. 여기에 부모가 waitFor()로 자식 프로세스의 종료만 기다리면 서로를 기다리는 교착이 됩니다. 따라서 waitFor()를 빼도 해결되지 않고, 출력 파이프를 읽거나 리다이렉트해야 합니다. JDK 25의 Process Javadoc은 이 멈춤과 교착 가능성을 경고합니다.
Process 클래스의 Javadoc 중Because some native platforms only provide limited buffer size for standard input and output streams, failure to promptly write the input stream or read the output stream of the process may cause the process to block, or even deadlock.
일부 네이티브 플랫폼은 표준 입력과 표준 출력 스트림에 제한된 크기의 버퍼만 제공하므로, 프로세스의 입력 스트림에 제때 쓰지 않거나 출력 스트림을 제때 읽지 않으면 프로세스가 멈추거나 심하면 교착에 빠질 수 있습니다.
Javadoc에 언급된 "limited buffer size"가 Linux에서는 얼마인지 pipe(7) 매뉴얼에 나옵니다. 커널 2.6.11부터 기본 파이프 용량은 16페이지, 즉 4KiB 페이지 기준 64KiB입니다. 다만 사용자별 파이프 메모리 한도나 시스템 설정에 따라 더 작아질 수 있고, F_SETPIPE_SZ로 바꿀 수도 있으므로 64KiB를 고정 한계로 가정하면 안 됩니다.
아래 코드는 seq 1 100000 명령으로 588,895바이트를 출력하게 하고 읽지 않은 채 3초를 기다립니다.
Process process = new ProcessBuilder("seq", "1", "100000").start();
boolean finished = process.waitFor(3, TimeUnit.SECONDS);
System.out.println("finished within 3s: " + finished + ", alive: " + process.isAlive());
long lines = process.inputReader().lines().count();
int exitCode = process.waitFor();
System.out.println("read " + lines + " lines, exit=" + exitCode + ", alive: " + process.isAlive());finished within 3s: false, alive: true
read 100000 lines, exit=0, alive: false부모 프로세스가 3초를 기다린 뒤에도 자식 프로세스는 살아 있습니다. 파이프 버퍼가 가득 찬 뒤로는 seq의 write() 호출이 블록되어 반환되지 않기 때문입니다. 부모가 파이프를 끝까지 읽자 자식 프로세스는 남은 출력을 마저 쓰고 종료 코드 0으로 끝났습니다(alive: false). 제한 시간이 없었다면 부모도 waitFor()에서 계속 기다렸을 것입니다.
예제에 쓴 inputReader() 메서드는 JDK 17에 추가됐습니다. 그 전에는 getInputStream()을 InputStreamReader와 BufferedReader로 감싸야 했습니다.
inputReader()의 활용// JDK 17 이전
BufferedReader reader = new BufferedReader(
new InputStreamReader(process.getInputStream()));
long lines = reader.lines().count();
// JDK 17 이후
long lines = process.inputReader().lines().count();두 코드는 기본 인코딩을 선택하는 기준이 다릅니다. inputReader()는 native.encoding 시스템 속성이 가리키는 인코딩으로 디코딩하고, 인자를 넘기지 않은 InputStreamReader는 Charset.defaultCharset()을 씁니다. JDK 18부터 기본 문자 인코딩은 UTF-8이지만, -Dfile.encoding=COMPAT을 지정하면 기본 인코딩이 이전처럼 운영체제와 로캘 등에 따라 정해집니다.
inputReader()는 자식 프로세스의 출력 인코딩을 자동으로 감지하지 않습니다. 자식이 부모 JVM의 native.encoding과 같은 인코딩으로 출력한다면 이 기본값이 적합합니다. 자식이 UTF-8을 명시적으로 쓰거나 다른 로캘로 실행된다면 출력 인코딩에 맞춰 inputReader(StandardCharsets.UTF_8)처럼 직접 지정해야 합니다.
출력을 읽을 때는 두 스트림을 동시에 처리
표준 출력과 표준 오류를 따로 받아서 가공해야 한다면 파이프 두 개를 동시에 비워야 합니다. 한 파이프를 다 읽은 뒤에 다른 파이프를 읽는 순차 처리로는 부족합니다. 표준 오류 파이프가 먼저 차면 자식 프로세스는 표준 출력을 더 쓰지 못하고, 부모는 표준 출력의 EOF를 기다리는 교착이 생깁니다. 이 경우에는 waitFor()에 도달하기도 전에 읽기 작업에서 멈춥니다.
아래 코드는 표준 오류에 588,895바이트를 쓴 뒤에 표준 출력에 한 줄을 쓰는 명령을 실행하고, 표준 출력을 끝까지 읽은 다음에 표준 오류를 읽습니다.
Process process = new ProcessBuilder("sh", "-c", "seq 1 100000 >&2; echo done").start();
System.out.println("reading stdout...");
long outLines = process.inputReader().lines().count();
long errLines = process.errorReader().lines().count();
System.out.println("stdout " + outLines + ", stderr " + errLines + ", exit=" + process.waitFor());위의 코드를 실행하면 첫 줄을 출력한 뒤로는 아무리 기다려도 다음 줄이 나오지 않고, ps로 확인하면 자식 seq 프로세스도 그대로 살아 있습니다.
reading stdout...seq는 표준 오류 파이프가 차서 멈췄고, 부모는 아직 오지 않은 표준 출력의 EOF를 기다립니다. 표준 오류를 읽는 다음 줄은 실행되지 않으므로 교착이 풀리지 않습니다. 두 스트림에 각각 읽기 스레드를 두면 어느 한쪽을 읽느라 다른 쪽을 방치하는 문제를 피할 수 있습니다. 뒤에 나올 PlainJdkRunner 예제가 그 방식입니다.
두 출력을 구분할 필요가 없다면 redirectErrorStream(true)로 표준 오류를 표준 출력에 합칠 수 있습니다. 이렇게 하면 읽어야 할 파이프가 하나로 줄어서 스레드 하나로 처리할 수 있습니다.
Process process = new ProcessBuilder("sh", "-c", "seq 1 100000 >&2; echo done")
.redirectErrorStream(true)
.start();
long lines = process.inputReader().lines().count();
System.out.println("read " + lines + " lines, exit=" + process.waitFor());같은 명령이지만 이번에는 끝까지 진행합니다. 100,001줄은 표준 오류로 나온 100,000줄과 표준 출력의 done 한 줄을 합한 수입니다.
read 100001 lines, exit=0Java 프로세스에서 읽지 않을 출력은 리다이렉트
자식 프로세스의 출력을 부모 프로세스가 참조하거나 가공할 필요가 없다면 Java 코드가 읽어야 할 파이프를 만들지 않는 편이 가장 단순합니다. 기본값인 Redirect.PIPE 대신 쓸 수 있는 선택지는 다음과 같습니다.
-
Redirect.INHERIT: 자식 프로세스가 부모의 표준 출력과 표준 오류에 바로 씁니다. (JDK 7부터 지원)-
inheritIO()메서드는 부모 프로세스의 세 스트림(표준 입력, 표준 출력, 표준 오류)을 한 번에 물려줍니다. (JDK 7부터 지원)
-
-
Redirect.DISCARD: 출력을/dev/null로 보냅니다. (JDK 9부터 지원) -
Redirect.to(File): 출력을 파일로 보냅니다. (JDK 7부터 지원)
// 부모의 표준 출력과 표준 오류로 바로 내보내기
new ProcessBuilder("seq", "1", "100000")
.redirectOutput(Redirect.INHERIT)
.redirectError(Redirect.INHERIT)
.start()
.waitFor();
// 표준 입력까지 세 스트림을 한 번에 물려주기
new ProcessBuilder("seq", "1", "100000")
.inheritIO()
.start()
.waitFor();
// 출력을 /dev/null로 버리기
new ProcessBuilder("seq", "1", "100000")
.redirectOutput(Redirect.DISCARD)
.redirectError(Redirect.DISCARD)
.start()
.waitFor();
// 파일로 보내기
new ProcessBuilder("seq", "1", "100000")
.redirectOutput(Redirect.to(new File("seq-out.log")))
.redirectError(Redirect.to(new File("seq-err.log")))
.start()
.waitFor();이 환경에서는 네 방식 모두 앞의 교착 예제와 같은 588,895바이트를 출력하고 정상 종료했습니다.
부모 JVM이 직접 읽어야 하는 자식 출력 파이프를 만들지 않으므로, 파이프를 읽지 않아서 생기는 교착이 없습니다.
다만 INHERIT로 물려받은 출력 대상이 파이프라면, 예를 들어 부모 JVM의 표준 출력이 파이프로 다른 프로그램에 연결되어 있다면, 그 프로그램이 읽는 속도에 따라 자식의 쓰기가 막히거나 늦어질 수 있습니다.
출력을 버릴 때는 표준 출력과 표준 오류 모두 DISCARD를 지정합니다. 한쪽만 지정하면 다른 쪽은 기본값인 PIPE로 남아서 앞의 교착이 다시 생길 수 있습니다. Redirect.to(File)은 파일이 이미 있으면 기존 내용을 지우고 덮어쓰므로, 실행할 때마다 뒤에 이어 붙이려면 Redirect.appendTo(File)을 씁니다.
표준 입력 닫기와 EOF
앞의 Javadoc 인용문이 출력과 함께 경고한 표준 입력(stdin)도 기본값은 파이프입니다. 부모 JVM이 이 파이프의 쓰기 끝을 열어 둔 채로 있으면 자식 프로세스는 EOF를 받지 못합니다. 인자 없이 실행한 cat처럼 표준 입력을 끝까지 읽는 명령은 더 올 입력이 없는데도 계속 기다리고, 부모는 waitFor()에서 그 명령이 끝나기를 기다립니다. 출력 파이프를 모두 비워도 이 대기는 풀리지 않습니다.
입력을 보낼 일이 없으면 start() 직후에 process.getOutputStream().close()로 쓰기 끝을 닫거나, redirectInput(new File("/dev/null"))처럼 빈 입력을 지정합니다. 입력을 보내야 한다면 다 쓴 뒤에 스트림을 닫아야 합니다. 뒤에서 살펴볼 zt-exec과 Apache Commons Exec은 입력을 지정하지 않으면 자식 프로세스의 표준 입력을 바로 닫습니다.
아래 예제는 cat을 네 번 실행하면서 표준 입력을 다루는 방식만 바꿉니다.
Process opened = new ProcessBuilder("cat").start();
System.out.println("stdin 열어 둠: finished within 1s=" + opened.waitFor(1, TimeUnit.SECONDS)
+ ", alive=" + opened.isAlive());
opened.destroy();
opened.waitFor();
Process closed = new ProcessBuilder("cat").start();
closed.getOutputStream().close();
System.out.println("stdin 닫음: finished within 1s=" + closed.waitFor(1, TimeUnit.SECONDS)
+ ", exit=" + closed.exitValue());
Process devNull = new ProcessBuilder("cat")
.redirectInput(new File("/dev/null"))
.start();
System.out.println("/dev/null 입력: finished within 1s=" + devNull.waitFor(1, TimeUnit.SECONDS)
+ ", exit=" + devNull.exitValue());
Process fed = new ProcessBuilder("cat").start();
try (Writer writer = fed.outputWriter()) {
writer.write("hello\n");
}
String echoed = fed.inputReader().readLine();
System.out.println("입력 후 닫음: echoed=" + echoed + ", exit=" + fed.waitFor());다음은 실행 결과입니다. stdin에 쓰는 스트림을 열어 둔 첫 번째만 1초 안에 끝나지 못했고, 나머지 셋은 EOF를 받아 바로 종료했습니다.
stdin 열어 둠: finished within 1s=false, alive=true
stdin 닫음: finished within 1s=true, exit=0
/dev/null 입력: finished within 1s=true, exit=0
입력 후 닫음: echoed=hello, exit=0첫 번째 cat은 destroy()로 끝냈습니다. 정리하지 않으면 남은 예제가 실행되는 동안 계속 살아 있습니다.
다만 부모 JVM이 끝나면 파이프의 쓰기 끝도 함께 닫히므로 그 시점에는 cat도 EOF를 받고 종료합니다.
마지막 예제에 쓴 outputWriter()는 inputReader()와 함께 JDK 17에 추가된 메서드로, getOutputStream()을 OutputStreamWriter와 BufferedWriter로 감싸는 코드를 대신합니다.
인자 없이 부르면 native.encoding 시스템 속성의 문자 집합을 쓰고, outputWriter(Charset) 메서드로 직접 지정할 수도 있습니다.
outputWriter()의 활용// JDK 17 이전
try (BufferedWriter writer = new BufferedWriter(
new OutputStreamWriter(process.getOutputStream()))) {
writer.write("hello\n");
}
// JDK 17 이후
try (BufferedWriter writer = process.outputWriter()) {
writer.write("hello\n");
}시간제한과 종료 정책
지금까지 설명한 것처럼 자식 프로세스와 연결되는 파이프 세 개를 처리해도 외부 명령이 네트워크나 잠금을 기다리며 멈출 수 있습니다.
그래서 시간제한과 종료 정책이 별도로 필요합니다.
명령이 멈춰 있는 동안 waitFor()를 부른 스레드는 외부 명령이 끝날 때까지 블로킹됩니다. JDK 8부터 있는 waitFor(long, TimeUnit) 메서드는 시간이 지나면 false를 돌려줄 뿐 프로세스를 종료하지 않습니다.
그때는 destroy()로 정상 종료를 요청하고 유예 시간 뒤에도 살아 있으면 destroyForcibly()를 쓰거나, 아래 예제처럼 바로 강제 종료할 수 있습니다.
Linux의 OpenJDK 구현에서 destroy()는 SIGTERM을, destroyForcibly()는 SIGKILL을 보냅니다.
프로세스는 SIGTERM을 핸들러로 받아서 임시 파일 삭제나 잠금 해제, 자신이 만든 자식 프로세스 정리 같은 마무리를 한 뒤에 끝날 수 있습니다.
SIGKILL은 핸들러를 통한 마무리 기회 없이 강제 종료하므로 정리하지 못한 파일과 후손 프로세스가 남을 수 있습니다. 그래서 정리할 것이 있는 명령에는 destroy()로 SIGTERM을 먼저 보내고 유예 시간을 두는 편이 안전합니다.
다만 destroyForcibly()가 반환된 직후에도 프로세스가 잠시 살아 있을 수 있으므로, 종료 완료가 필요하면 waitFor()로 확인해야 합니다.
아래 예제는 sleep처럼 정리할 것이 없는 명령만 실행하므로 바로 강제 종료합니다.
두 출력 스트림을 각각 JDK 21의 가상 스레드에서 읽으면서 종료 대기에 1초 제한을 둡니다.
static void run(String... command) throws IOException, InterruptedException, TimeoutException {
Process process = new ProcessBuilder(command).start();
StringBuilder stdout = new StringBuilder();
StringBuilder stderr = new StringBuilder();
Thread outPump = Thread.ofVirtual().start(() -> process.inputReader().lines().forEach(l -> stdout.append(l).append('\n')));
Thread errPump = Thread.ofVirtual().start(() -> process.errorReader().lines().forEach(l -> stderr.append(l).append('\n')));
if (!process.waitFor(1, TimeUnit.SECONDS)) {
process.destroyForcibly().waitFor();
throw new TimeoutException("timed out: " + String.join(" ", command));
}
outPump.join();
errPump.join();
System.out.println(command[0] + ": exit=" + process.exitValue()
+ ", stdout chars=" + stdout.length() + ", stderr=" + stderr.toString().trim());
}다음은 echo hello, seq 1 100000, ls /no-such-dir, sleep 60 네 명령을 이 메서드로 실행한 결과입니다. seq의 588,895바이트 출력도 멈추지 않고, ls의 표준 오류는 따로 모이고, 1초를 넘긴 sleep은 예외로 끝납니다.
echo: exit=0, stdout chars=6, stderr=
seq: exit=0, stdout chars=588895, stderr=
ls: exit=2, stdout chars=0, stderr=ls: cannot access '/no-such-dir': No such file or directory
timed out: sleep 60이 예제는 입력을 요구하지 않고 후손 프로세스를 만들지 않는 명령을 대상으로 합니다. 다른 명령에도 안전하게 쓰려면 다음 항목을 더 챙겨야 합니다.
-
표준 입력을 읽는 명령에는 앞 절의 EOF 처리를 더합니다.
-
읽기 스레드에서 난 예외를 호출 스레드에 전달하고, 인터럽트나 시간 초과 때도 프로세스와 스트림을 정리합니다.
-
위 코드의 1초 제한은
waitFor()에만 적용됩니다.start()나 뒤이은 종료 대기와join()까지 포함한 전체 시간제한이 필요하면 따로 구현합니다. -
출력이 아주 크면
StringBuilder에 다 담지 말고 줄 단위나 고정 크기 버퍼로 처리합니다. -
출력 인코딩이 부모 JVM의
native.encoding과 다른 명령에는inputReader(Charset)으로 인코딩을 지정합니다.
후손 프로세스의 정리
destroy()와 destroyForcibly()는 직접 만든 자식에게만 시그널을 보냅니다.
실행한 명령이 다시 자식 프로세스를 만들었다면 그 후손은 남을 수 있습니다.
자식이 먼저 끝나면 그 자식이 만든 후손 프로세스는 PID 1이나 가장 가까운 subreaper 프로세스의 자식으로 바뀌어 계속 실행됩니다.
subreaper는 prctl(PR_SET_CHILD_SUBREAPER)로 지정한 프로세스로, 부모를 잃은 후손을 PID 1 대신 넘겨받습니다. systemd는 대부분의 Linux 배포판에서 부팅 때 PID 1로 가장 먼저 실행되어 다른 서비스를 시작하고 관리하는 프로그램이며, 로그인한 사용자마다 systemd --user라는 별도 인스턴스도 실행합니다. 데스크톱 세션의 systemd --user가 subreaper의 예입니다.
후손 프로세스가 남는 사례
후손 프로세스가 남는 상황은 크게 네 가지입니다.
-
셸을 거쳐 실행한 명령:
sh -c "a | b"나run.sh같은 스크립트를 실행하다가 시간 초과로 종료하는 경우입니다. 스크립트를 실행하는 비대화형 셸은 자신이 받은 SIGTERM을 자식에게 전달하지 않으므로 셸만 끝납니다. -
래퍼나 런처를 거쳐 실행되는 프로그램:
npm run은 Node.js로 실행되는 npm이sh -c로 스크립트를 실행하므로, npm 프로세스를 끝내도 셸이 실행한 명령이 남을 수 있습니다. LibreOffice의soffice는oosplash를 거쳐 실제 작업을 하는soffice.bin을 실행하며,oosplash를 SIGKILL로 끝내면soffice.bin은 종료되지 않고 남습니다.git도 fetch나 clone 중에ssh나git-remote-https를 자식으로 실행합니다. -
스스로 데몬이 되는 프로그램: Gradle daemon, Kotlin 컴파일 데몬,
adb start-server,ssh의 ControlPersist 연결은 호출한 쪽이 끝나도 남아 있도록 만들어졌습니다. 이런 프로그램은setsid()로 원래 세션과 그룹을 벗어나기도 합니다. -
백그라운드 작업을 기다리지 않는 스크립트:
server &뒤에wait가 없으면 스크립트가 정상 종료해도server는 계속 실행됩니다. 이 후손이 물려받은 출력 파이프를 열어 두면waitFor()는 반환되어도 출력을 읽는 쪽은 EOF를 받지 못합니다.
첫 번째 경우를 재현해 보겠습니다. 아래 코드는 셸로 sleep 60을 실행하고 0.3초 뒤에 destroy()를 호출한 다음, 종료 전에 조회해 둔 후손 중 살아 있는 프로세스와 그 부모 PID를 출력합니다.
public static void main(String[] args) throws Exception {
run("sh", "-c", "sleep 60");
run("sh", "-c", "sleep 60; echo done");
run("sh", "-c", "sleep 60 | cat");
run("bash", "-c", "sleep 60");
}
static void run(String... command) throws Exception {
Process process = new ProcessBuilder(command).start();
Thread.sleep(300);
List<ProcessHandle> descendants = process.descendants().toList();
process.destroy();
process.waitFor(1, TimeUnit.SECONDS);
Thread.sleep(100);
List<String> left = descendants.stream()
.filter(ProcessHandle::isAlive)
.map(p -> name(p) + "(ppid=" + p.parent().map(ProcessHandle::pid).orElse(-1L) + ")")
.toList();
System.out.println(String.join(" ", command) + " -> shell alive=" + process.isAlive()
+ ", children=" + descendants.size() + ", left=" + left);
descendants.forEach(ProcessHandle::destroyForcibly);
}sh -c sleep 60 -> shell alive=false, children=1, left=[sleep(ppid=1693)]
sh -c sleep 60; echo done -> shell alive=false, children=1, left=[sleep(ppid=1693)]
sh -c sleep 60 | cat -> shell alive=false, children=2, left=[sleep(ppid=1693), cat(ppid=1693)]
bash -c sleep 60 -> shell alive=false, children=0, left=[]sh -c로 실행한 세 경우 모두 셸은 끝났지만 sleep과 cat은 남았습니다. 남은 프로세스의 부모인 PID 1693은 이 환경의 systemd --user입니다.
명령이 한 줄뿐인 sh -c "sleep 60"에서도 후손이 남은 점을 주의해야 합니다. Ubuntu 24.04의 /bin/sh인 dash 0.5.12는 -c로 받은 마지막 명령도 자식 프로세스로 실행했습니다. 반면 bash -c는 셸 프로세스를 sleep으로 바꿔 실행했으므로(children=0) 남은 후손이 없습니다.
셸의 종류와 버전에 따라 이 동작이 다르므로, 셸을 거친 명령은 후손이 남는다고 가정하고 정리 방법을 준비하는 편이 안전합니다.
남은 후손이 곧 끝나는 명령이라면 문제는 그 후손이 실행되는 동안만 이어집니다. 그래도 그동안 시간 초과로 실패 처리한 작업이 뒤에서 계속 파일을 쓰거나 외부 API를 호출할 수 있습니다.
더 큰 문제는 스스로 끝나지 않는 후손입니다. 시간 초과가 났다는 것 자체가 명령이 제시간에 끝나지 않았다는 뜻이므로, 남은 후손도 곧 끝난다고 기대하기 어렵습니다. 서버나 데몬처럼 원래 끝나지 않는 후손은 실행할 때마다 쌓여 메모리와 프로세스 수 한도를 차지합니다. 포트나 파일 잠금을 계속 잡고 있으면 다음 실행이 Address already in use 같은 오류로 실패합니다.
남은 후손이 물려받은 출력 파이프를 계속 열고 있으면, 진행 중인 읽기가 후손의 파이프 닫기를 기다리면서 join()도 지연될 수 있습니다. JDK 25의 Process 구현은 직접 자식이 종료하면 파이프에 남은 출력을 회수하고 스트림을 닫지만, 이미 진행 중인 읽기와 이 종료 처리의 순서에 따라 대기 여부가 달라집니다.
위 예제처럼 JDK 9의 ProcessHandle.descendants()로 후손을 조회해 하나씩 종료할 수도 있습니다. 하지만 그 결과는 스냅샷이므로, 조회와 종료 사이에 생기거나 부모 종료 뒤 재부모화된 프로세스까지 확실하게 정리하지는 못합니다.
후손까지 한 번에 끝내려면 OS 수준의 프로세스 그룹이나 cgroup으로 관리해야 합니다.
프로세스 그룹 단위의 종료
후손이 같은 프로세스 그룹에 남는 명령은 setsid로 새 세션과 그룹을 만들어 실행하고, 작업이 끝나면 그 그룹 전체에 시그널을 보내 정리할 수 있습니다.
JDK API에는 프로세스 그룹을 만들거나 그룹에 시그널을 보내는 기능이 없으므로, setsid와 kill 명령을 함께 실행하는 식으로 구성합니다.
public static void main(String[] args) throws Exception {
run("sleep 60 | cat");
run("(trap '' TERM; sleep 60) & sleep 60");
run("setsid sleep 60 & sleep 60");
}
static void run(String script) throws Exception {
Process process = new ProcessBuilder("setsid", "sh", "-c", script).start();
List<ProcessHandle> descendants = List.of();
try {
if (!process.waitFor(1, TimeUnit.SECONDS)) {
descendants = process.descendants().toList(); // 결과 확인용 스냅샷
}
} finally {
killGroup(process.pid()); // setsid로 그룹 리더가 된 자식의 PID가 곧 프로세스 그룹 ID
process.waitFor();
}
List<String> left = descendants.stream()
.filter(ProcessHandle::isAlive)
.map(p -> p.info().commandLine().orElse("?"))
.toList();
System.out.println("[" + script + "] pgid=" + process.pid() + ", left=" + left);
descendants.forEach(ProcessHandle::destroyForcibly);
}
static void killGroup(long pgid) throws Exception {
signalGroup("TERM", pgid);
if (!awaitGroupExit(pgid, 5)) {
signalGroup("KILL", pgid);
awaitGroupExit(pgid, 5);
}
}
static boolean awaitGroupExit(long pgid, long seconds) throws Exception {
long deadline = System.nanoTime() + TimeUnit.SECONDS.toNanos(seconds);
while (signalGroup("0", pgid)) {
if (System.nanoTime() > deadline) {
return false;
}
Thread.sleep(100);
}
return true;
}
// kill의 종료 코드 0은 그룹에 시그널을 받은 프로세스가 하나 이상 있다는 뜻
static boolean signalGroup(String signal, long pgid) throws Exception {
Process kill = new ProcessBuilder("kill", "-" + signal, "--", "-" + pgid)
.redirectErrorStream(true)
.redirectOutput(Redirect.DISCARD)
.start();
return kill.waitFor() == 0;
}util-linux의 setsid 명령은 호출한 프로세스가 이미 그룹 리더일 때만 fork()하고, 그렇지 않으면 자기 프로세스에서 setsid()를 호출한 뒤 명령을 실행합니다. JVM이 만든 자식은 그룹 리더가 아니므로 PID가 바뀌지 않고, process.pid()를 새 그룹의 ID로 쓸 수 있습니다.
kill의 PID 인자에 음수를 넘기면 그 절댓값을 ID로 쓰는 프로세스 그룹 전체에 시그널이 갑니다. 단, -1은 그룹이 아니라 권한이 있는 모든 프로세스를 뜻합니다. kill은 -9나 -KILL처럼 -로 시작하는 인자를 시그널로 받으므로, --를 앞에 두어 -295952를 PID로 읽게 합니다. 시그널 번호 0은 실제로 시그널을 보내지 않고 대상의 존재와 권한만 확인하므로, kill -0이 성공하면 그룹에 프로세스가 남아 있다는 뜻입니다.
waitFor()는 직접 자식인 셸만 기다리므로, 셸이 끝났다고 그룹 전체가 끝났다고 볼 수 없습니다. 그래서 killGroup()은 SIGTERM을 보낸 뒤 kill -0으로 그룹에 남은 프로세스가 있는지 확인하면서 최대 5초를 기다리고, 그 뒤에도 남아 있으면 그룹 전체에 SIGKILL을 보냅니다.
정리는 시간 초과 때만이 아니라 finally에서 항상 합니다. 직접 자식이 정상 종료해도 백그라운드로 띄운 후손은 남을 수 있기 때문입니다. 예를 들어 sleep 60 &만 실행하는 스크립트는 셸이 바로 끝나서 waitFor()가 true를 돌려주지만, finally의 killGroup()이 남은 sleep을 정리합니다.
[sleep 60 | cat] pgid=295952, left=[]
[(trap '' TERM; sleep 60) & sleep 60] pgid=295959, left=[]
[setsid sleep 60 & sleep 60] pgid=296018, left=[/usr/bin/sleep 60]첫 번째 명령의 sleep과 cat은 셸과 같은 그룹에 있으므로 SIGTERM으로 함께 끝났습니다.
두 번째 명령의 셸은 SIGTERM으로 바로 끝났지만, SIGTERM을 무시하도록 실행한 sleep은 5초 유예 뒤 SIGKILL로 끝났습니다. 셸의 종료만 보고 SIGKILL을 생략했다면 이 sleep은 남았을 것입니다.
세 번째 명령에서 setsid로 실행한 sleep은 새 세션과 그룹으로 이동해서 그룹에 보낸 시그널을 받지 않았습니다. 후손이 setsid()나 setpgid()로 새 세션이나 다른 그룹으로 이동하면 이 방법으로는 정리하지 못합니다. 앞에서 본 데몬형 프로그램이 이런 경우에 해당합니다.
cgroup 단위의 종료
cgroup(control group)은 Linux 커널이 프로세스를 계층 구조의 그룹으로 묶어 CPU, 메모리, I/O, 프로세스 수 같은 자원을 제한하고 측정하는 기능입니다. Docker 컨테이너의 메모리 제한도 cgroup으로 동작합니다.
fork()로 만든 자식은 부모의 cgroup에 속한 채로 시작하므로 손자와 그 아래 후손도 모두 같은 cgroup에 들어갑니다.
setsid()는 세션과 프로세스 그룹만 바꾸고 cgroup은 바꾸지 않습니다. cgroup v2에서 프로세스를 다른 cgroup으로 옮기려면 원래 cgroup과 옮길 cgroup의 공통 조상에 있는 cgroup.procs 파일에 쓸 권한이 필요합니다. 그래서 권한이 없는 후손은 cgroup을 벗어나지 못합니다.
현재 프로세스가 속한 cgroup은 /proc/self/cgroup에서, 전체 트리는 systemd-cgls 명령으로 확인할 수 있습니다.
systemd는 서비스마다 cgroup을 따로 만들고, 서비스를 멈출 때 그 cgroup에 남은 프로세스를 모두 종료합니다(KillMode=control-group이 기본값).
systemd-run --scope를 쓰면 한 번 실행할 명령에도 같은 방식을 적용할 수 있습니다. 아래 코드는 앞에서 프로세스 그룹을 벗어난 명령을 임시 scope 단위로 실행하고, 작업이 끝나면 그 단위를 멈춥니다.
String unit = "job-" + UUID.randomUUID() + ".scope";
Process process = new ProcessBuilder(
"systemd-run", "--user", "--scope", "--quiet", "--unit=" + unit,
"sh", "-c", "setsid sleep 60 & sleep 60")
.redirectError(Redirect.INHERIT)
.start();
List<ProcessHandle> descendants = List.of();
try {
if (process.waitFor(1, TimeUnit.SECONDS)) {
System.out.println("exit=" + process.exitValue()); // systemd-run의 실패도 여기서 드러남
} else {
System.out.println("cgroup: " + Files.readString(Path.of("/proc/" + process.pid() + "/cgroup")).trim());
descendants = process.descendants().toList(); // 결과 확인용 스냅샷
}
} finally {
int stopExit = new ProcessBuilder("systemctl", "--user", "stop", unit)
.redirectError(Redirect.INHERIT)
.start()
.waitFor();
System.out.println("systemctl stop exit=" + stopExit);
if (!process.waitFor(10, TimeUnit.SECONDS)) {
process.destroyForcibly().waitFor();
}
}
List<String> left = descendants.stream()
.filter(ProcessHandle::isAlive)
.map(p -> p.info().commandLine().orElse("?"))
.toList();
System.out.println("descendants=" + descendants.size() + ", left=" + left);cgroup: 0::/user.slice/user-1000.slice/user@1000.service/app.slice/job-0fbacb17-d0c0-47de-a65d-db30d90ecfb1.scope
systemctl stop exit=0
descendants=2, left=[]--scope로 실행하면 systemd-run은 scope 단위의 시작을 기다린 뒤 자기 프로세스를 명령으로 바꿔 실행하므로 PID가 바뀌지 않습니다. 명령은 여전히 JVM의 직접 자식이므로 앞의 예제들처럼 Process로 출력을 읽고 종료를 기다릴 수 있습니다.
실행 결과의 cgroup 경로가 job-…scope로 끝나는 것으로 명령이 전용 cgroup에서 실행됐음을 확인할 수 있습니다. systemctl stop을 호출하자 setsid로 그룹을 벗어난 sleep까지 두 후손이 모두 끝났습니다.
systemctl stop은 SIGTERM을 먼저 보내고, 유예 시간(TimeoutStopSec) 안에 끝나지 않은 프로세스에 SIGKILL을 보냅니다. 유예 시간은 systemd-run에 -p TimeoutStopSec=5s처럼 지정할 수 있습니다.
scope는 특정 프로세스가 아니라 그 안에 프로세스가 하나라도 남아 있는 동안 유지됩니다. 셸이 먼저 끝나도 백그라운드로 띄운 후손이 있으면 scope는 활성 상태로 남으므로, 앞의 프로세스 그룹 예제처럼 finally에서 항상 단위를 멈춥니다.
systemd-run이 사용자 버스에 접속하지 못하는 등의 이유로 실패하면 오류를 표준 오류에 출력하고 0이 아닌 종료 코드로 끝나므로, 예제는 표준 오류를 부모로 넘기고 종료 코드를 출력합니다. systemctl stop도 종료 코드를 확인하고, 정리가 실패했을 때 무한정 기다리지 않도록 waitFor()에 제한 시간을 둡니다. 명령이 먼저 끝나 scope가 이미 사라졌다면 systemctl stop은 단위가 없다는 뜻의 종료 코드 5를 돌려주므로, 실제 코드에서는 이 경우를 정상으로 처리합니다.
이 방법에는 전제 조건이 있습니다.
-
--user를 쓰려면 사용자의 systemd 인스턴스가 실행 중이어야 합니다. 로그인 세션이 없는 서버의 서비스 계정이라면loginctl enable-linger로 사용자 인스턴스를 유지하거나, 권한이 있는 system 인스턴스를 써야 합니다. -
대부분의 컨테이너 안에는 systemd가 없으므로 이 방법을 쓸 수 없습니다. 이때는 작업마다 별도 컨테이너를 실행해 컨테이너 단위로 정리하는 방법을 고려할 수 있습니다.
-
systemd 없이 cgroup v2를 직접 다룰 권한을 위임받았다면, 작업용 cgroup을 만들고 그 안에서 명령을 시작한 뒤
cgroup.kill파일에1을 써서 하위 cgroup까지 모든 프로세스에 SIGKILL을 보낼 수 있습니다. 이 파일은 Linux 5.14부터 지원합니다.
어느 방법이든 대상 작업을 처음부터 해당 cgroup 안에서 시작하고, 그 밖으로 이동할 권한과 종료 정책을 함께 관리해야 합니다.
정리하면 실행하는 명령을 직접 통제하고 그 명령이 데몬이 되지 않는다면 프로세스 그룹 방식으로 충분합니다. 임의의 스크립트나 외부에서 받은 명령을 실행한다면 cgroup 단위로 정리하는 편이 확실합니다. 다음 절의 라이브러리들도 출력 처리와 시간제한 코드를 줄여 주지만, 이런 조건까지 모두 해결해 주지는 않습니다.
zt-exec과 Apache Commons Exec의 활용
앞 절에서 본 출력 파이프, 표준 입력의 EOF, 시간제한, 종료 정책을 모두 챙긴 코드를 직접 작성하기는 쉽지 않습니다. 원리를 잘 이해한다고 해도 이 코드를 프로젝트마다 다시 구현하는 일은 번거롭습니다. 이런 처리가 반영된 라이브러리를 사용하는 편이 실무에서는 실용적입니다.
이 분야의 대표적인 라이브러리가 zt-exec과 Apache Commons Exec입니다.
두 라이브러리 모두 별도의 스레드로 출력 파이프를 비우고, 입력을 지정하지 않으면 PumpStreamHandler라는 클래스가 자식 프로세스의 표준 입력을 닫아서 자식이 EOF를 받게 합니다.
zt-exec의 PumpStreamHandler 클래스는 소스 파일 상단에 "This file originates from the Apache Commons Exec package"라고 적혀 있을 만큼 Commons Exec의 코드를 가져온 것입니다. 이 글에서 비교할 주요 차이는 API의 형태와 기본값입니다.
zt-exec
zt-exec은 JRebel을 만든 ZeroTurnaround가 사내 여러 프로젝트에 흩어져 있던 프로세스 실행 코드를 하나로 합쳐서 2013년에 공개한 라이브러리입니다.
정식 이름은 README의 제목대로 ZT Process Executor이지만, GitHub 저장소와 Maven artifactId가 zt-exec이어서 보통 zt-exec으로 부릅니다. 이 글에서도 zt-exec으로 씁니다.
README는 ProcessExecutor 클래스 하나로 ProcessBuilder와 Commons Exec의 기능을 모두 제공하는 것이 목표라고 설명합니다.
의존성은 slf4j-api 하나이고 최소 Java 버전은 8입니다.
<dependency>
<groupId>org.zeroturnaround</groupId>
<artifactId>zt-exec</artifactId>
<version>1.13.0</version>
</dependency>zt-exec의 장점은 다음과 같습니다.
-
기본값이 안전합니다. 아무 설정 없이
execute()만 부르면 표준 오류를 표준 출력에 합치고 그 출력을 버립니다. 파이프를 읽지 않아서 생기는 교착이 기본값에서는 일어나지 않습니다. 출력이 필요하면readOutput(true)를 켜고 결과의outputUTF8()로 문자열을 받거나,redirectOutput()에 줄 단위로 문자열을 처리하는 함수를 람다 표현식으로 넘깁니다. -
시간제한이 예외 타입으로 구분됩니다.
execute()의 대기가timeout()으로 지정한 시간을 넘기면 호출자는TimeoutException을 받고, 작업 스레드는 stopper로 종료를 시도합니다. 종료 코드가 잘못된 경우와 시간 초과를 예외 타입만으로 구분할 수 있습니다. 다만 예외를 잡은 시점에 stopper의 종료 처리가 완료됐다고 보장되지는 않습니다. 기본 stopper는destroy()만 호출하므로 Linux에서 SIGTERM을 무시하는 프로세스까지 강제 종료하지는 않습니다. 종료 방식은stopper()로 바꿀 수 있습니다.ProcessStopper인터페이스를 구현해서destroy()뒤에 유예 시간을 두고destroyForcibly()를 부르는 정책을 넣으면 됩니다. -
종료 코드 검사를 선언합니다. 기본값은 모든 종료 코드를 허용하고,
exitValueNormal()이나exitValues(0, 1)로 허용 범위를 지정하면 그 밖의 값에서InvalidExitValueException이 발생합니다. 예외 객체의getResult()로 그때까지의 출력도 볼 수 있어서 오류 메시지를 로그에 남기기 좋습니다. -
부수 기능을 간단히 설정합니다.
start().getFuture()로 비동기로 실행할 수 있습니다. 다만start()는timeout()설정을 무시하므로,Future.get(timeout, unit)등으로 대기를 제한하고 시간 초과 때 취소·종료 처리를 따로 해야 합니다.get()의 시간 초과만으로 프로세스가 종료되지는 않습니다.destroyOnExit()로는 JVM의 shutdown hook에서 자식 프로세스에 종료를 요청합니다.redirectOutputAsInfo()로 SLF4J 로거에 출력을 전달할 수도 있지만, 이 메서드는 deprecated이며redirectOutput(Slf4jStream.of(logger).asInfo())가 권장 API입니다.
앞 절의 네 명령을 zt-exec으로 실행한 예제입니다.
static void captureOutput() throws IOException, InterruptedException, TimeoutException {
ProcessResult result = new ProcessExecutor()
.command("echo", "hello")
.readOutput(true)
.exitValueNormal()
.execute();
System.out.println("output=" + result.outputUTF8().trim() + ", exit=" + result.getExitValue());
}
static void largeOutput() throws IOException, InterruptedException, TimeoutException {
AtomicLong lines = new AtomicLong();
ProcessResult result = new ProcessExecutor()
.command("seq", "1", "100000")
.redirectOutput(line -> lines.incrementAndGet())
.timeout(3, TimeUnit.SECONDS)
.execute();
System.out.println("seq lines=" + lines.get() + ", exit=" + result.getExitValue());
}
static void timeout() throws IOException, InterruptedException {
try {
new ProcessExecutor()
.command("sleep", "60")
.timeout(1, TimeUnit.SECONDS)
.execute();
} catch (TimeoutException e) {
System.out.println("timeout: " + e.getMessage());
}
}
static void exitValue() throws IOException, InterruptedException, TimeoutException {
try {
new ProcessExecutor()
.command("ls", "/no-such-dir")
.readOutput(true)
.exitValueNormal()
.execute();
} catch (InvalidExitValueException e) {
System.out.println("exit=" + e.getExitValue() + ", output=" + e.getResult().outputUTF8().trim());
}
}다음은 실행 결과입니다. TimeoutException의 메시지에 실행한 명령과 제한 시간이 들어 있고, ls의 오류 메시지는 표준 오류가 표준 출력에 합쳐지는 기본값 덕분에 outputUTF8()로 읽힙니다. 시간 초과 뒤에 sleep 프로세스가 남아 있지 않은 것도 확인했습니다.
output=hello, exit=0
seq lines=100000, exit=0
timeout: Timed out waiting for Process[pid=294823, exitValue="not exited"] to finish, timeout: 1 second, executed command [sleep, 60]
exit=2, output=ls: cannot access '/no-such-dir': No such file or directory주의할 점도 있습니다. readOutput(true)는 출력 파이프를 읽는 스레드가 읽은 바이트를 전부 ByteArrayOutputStream에 저장합니다. 결과를 만들 때 toByteArray()로 한 번 더 복사하고, outputUTF8()을 부르면 문자열도 만듭니다. ByteArrayOutputStream은 버퍼가 차면 크기를 두 배로 늘리므로 내부 버퍼만으로도 출력 크기보다 커질 수 있고, 한글처럼 Latin-1 밖의 문자가 섞인 문자열은 글자당 2바이트를 씁니다. 그래서 최대 메모리 사용량이 출력 크기의 두 배를 넘을 수 있습니다.
전체 출력을 보관할 필요가 없다면 위 예제의 largeOutput()처럼 readOutput을 켜지 않고 redirectOutput()에 줄 단위 처리 함수를 넘길 수 있습니다. 이 방식의 버퍼 크기는 총 출력량보다는 가장 긴 줄의 크기에 좌우됩니다. 줄바꿈 없는 거대한 출력에는 여전히 메모리가 많이 들고, 처리 함수가 느리면 자식 프로세스의 출력도 밀립니다. 그런 출력은 파일이나 고정 크기 버퍼로 처리하는 OutputStream으로 보내는 편이 낫습니다.
이 예제는 SLF4J API 2.0.17을 사용했으므로 구현체가 없을 때 초기화 과정에서 "No SLF4J providers were found"를 포함한 경고가 세 줄 나왔습니다. zt-exec 1.13.0의 POM이 선언한 의존성은 SLF4J API 1.7.32이며, 이 버전의 경고 문구는 다릅니다. 로그가 필요 없다면 사용 중인 SLF4J API에 맞는 slf4j-nop을 추가해 경고를 없앨 수 있습니다.
Apache Commons Exec
Apache Commons Exec은 명령 실행, 출력 스트림 처리, 시간제한을 각각 DefaultExecutor, PumpStreamHandler, ExecuteWatchdog로 구성하는 라이브러리입니다. 이 글에서 사용하는 1.6.0은 Java 8 이상에서 실행되며 외부 의존성이 없습니다. DefaultExecutor와 ExecuteWatchdog는 builder API로 만들고, 시간제한은 Duration으로 지정합니다. 기존 생성자는 deprecated로 표시되어 있습니다.
<dependency>
<groupId>org.apache.commons</groupId>
<artifactId>commons-exec</artifactId>
<version>1.6.0</version>
</dependency>같은 네 명령을 1.6.0으로 실행한 예제입니다. 스트림 처리를 맡는 PumpStreamHandler 클래스는 기본으로 System.out과 System.err에 출력하므로, 출력을 모으려면 아래처럼 OutputStream을 직접 넘깁니다.
static void run(String... command) throws IOException {
CommandLine cmdLine = new CommandLine(command[0]);
cmdLine.addArguments(Arrays.copyOfRange(command, 1, command.length), false);
ByteArrayOutputStream stdout = new ByteArrayOutputStream();
ByteArrayOutputStream stderr = new ByteArrayOutputStream();
ExecuteWatchdog watchdog = ExecuteWatchdog.builder().setTimeout(Duration.ofSeconds(1)).get();
DefaultExecutor executor = DefaultExecutor.builder().get();
executor.setStreamHandler(new PumpStreamHandler(stdout, stderr));
executor.setWatchdog(watchdog);
try {
int exitValue = executor.execute(cmdLine);
System.out.println(command[0] + ": exit=" + exitValue + ", stdout bytes=" + stdout.size());
} catch (ExecuteException e) {
System.out.println(command[0] + ": exit=" + e.getExitValue()
+ ", killed by watchdog=" + watchdog.killedProcess()
+ ", stderr=" + stderr.toString().trim());
}
}echo: exit=0, stdout bytes=6
seq: exit=0, stdout bytes=588895
sleep: exit=143, killed by watchdog=true, stderr=
ls: exit=2, killed by watchdog=false, stderr=ls: cannot access '/no-such-dir': No such file or directoryDefaultExecutor는 Linux에서 기본적으로 0이 아닌 종료 코드에 ExecuteException을 던집니다.
에러로 처리하지 않을 종료 코드는 setExitValue()나 setExitValues()로 바꿀 수 있고, setExitValues(null)로 검사를 끌 수도 있습니다.
위 결과의 sleep은 watchdog이 보낸 SIGTERM으로 끝나서 종료 코드가 143입니다.
이 예제에서는 예외를 잡은 뒤 watchdog.killedProcess()로 watchdog의 개입 여부를 구분합니다.
다만 이 메서드는 destroy() 호출 여부를 나타내며 실제 종료를 보장하지 않습니다.
1.6.0의 ExecuteWatchdog는 시간 초과 때 destroy()만 호출하고 강제 종료로 넘어가는 API가 없습니다.
강제 종료가 필요하면 시간 초과 뒤 남은 프로세스를 ProcessHandle로 찾아 destroyForcibly()를 부르는 코드를 따로 두어야 합니다.
명령이 SIGTERM을 무시하면 execute()가 계속 기다릴 수 있습니다. 반대로 SIGTERM을 받아 종료 처리를 한 명령이 허용된 코드로 끝나면 시간 초과 뒤에도 예외 없이 반환될 수 있습니다. 그래서 정상 반환 경로에서도 killedProcess()를 확인해야 합니다.
유지보수 현황과 선택
다음은 Maven Central의 버전 목록과 각 프로젝트의 변경 기록으로 2026-09-06에 확인한 두 라이브러리의 현황입니다.
| 항목 | zt-exec | Apache Commons Exec |
|---|---|---|
최신 버전 |
1.13.0 (2026-07-10) |
1.6.0 (2025-11-25) |
그 이전 릴리스 |
1.12 (2020-09-02), 1.11 (2019-07-05) |
1.5.0 (2025-05-16), 1.4.0 (2024-01-01), 1.3 (2014-11-02) |
최근 5년간 릴리스 수 |
1회 |
3회 |
최소 Java 버전 |
8 |
8 |
의존성 |
slf4j-api |
없음 |
기본 출력 처리 |
버림 (표준 오류는 표준 출력에 합침) |
|
시간 초과 알림 |
|
|
0이 아닌 종료 코드 |
기본 허용, |
기본 |
시간 초과 시 종료 방식 |
|
|
둘 중에서 저는 zt-exec을 더 추천합니다.
API 설계에서 세 가지 장점이 있기 때문입니다.
시간 초과와 종료 코드 오류를 예외 타입으로 구분하고, 출력을 문자열로 받는 데 메서드 호출 하나면 되고, 기본 설정에서 출력 파이프를 읽지 않아 생기는 교착을 피할 수 있습니다.
두 라이브러리 모두 기본 종료 요청은 destroy()입니다. zt-exec은 stopper()로 강제 종료 정책을 넣을 수 있지만 Commons Exec은 별도 코드가 필요합니다.
Linux에서의 프로세스 생성과 운영
현재 Linux에서 JDK 25를 쓰는 Java 개발자는 jdk.lang.Process.launchMechanism 옵션을 별도로 지정하지 않고 기본값인 POSIX_SPAWN을 유지하면 됩니다. JDK 13부터 이 방식이 기본입니다.
이 장에서는 그 이유를 확인하기 위해 Linux가 제공하는 세 가지 프로세스 생성 방식과 JDK 기본값의 변천을 먼저 정리하고, POSIX_SPAWN의 동작, 대안인 FORK의 메모리 비용과 실행 지연, 마지막으로 JVM을 업그레이드할 때 정리해야 할 VFORK 설정을 차례로 살펴봅니다.
프로세스 생성 방식 세 가지와 JDK 기본값의 변천
애플리케이션의 외부 프로세스 실행 코드는 JVM을 거쳐 커널의 시스템 콜이나 C 라이브러리의 함수 호출로 이어집니다.
어떤 함수 호출로 자식 프로세스를 만드는지가 중요한 이유는 이 선택이 과거에 실제 장애로 이어졌기 때문입니다. 힙을 크게 잡은 JVM이 외부 명령 하나를 실행하려다 메모리 할당에 실패하는 문제가 대표적입니다. 2015년 NAVER D2의 Java에서 외부 프로세스를 실행할 때는 힙을 크게 설정한 Tomcat 서버에서 외부 프로세스 실행이 Cannot allocate memory 예외로 실패하는 사례를 소개합니다. OpenJDK 이슈에도 그 이력이 남아 있습니다. JDK 7에 반영된 JDK-6868160의 제목은 "(process) Use vfork, not fork, on Linux to avoid swap exhaustion"입니다. 자식 프로세스를 만드는 호출을 바꾼 것이 스왑 고갈을 피하려는 조치였다는 뜻입니다. 지금 기본값을 그대로 두면 되는 것도 이런 문제들이 차례로 해결된 결과입니다.
Linux에서 다른 프로그램을 실행하려면 자식 프로세스를 만드는 호출과 그 자식을 다른 프로그램으로 바꾸는 시스템 콜인 execve()를 짝지어야 합니다. 선택의 여지가 있는 쪽은 앞의 절반, 즉 자식을 만드는 방법입니다. 후보는 세 가지입니다.
-
fork(): 부모의 주소 공간을 복제한 자식을 만드는 시스템 콜입니다. -
vfork(): 주소 공간을 복제하지 않고 부모와 공유하는 자식을 만드는 시스템 콜입니다. -
posix_spawn(): 자식 생성과execve()를 한 묶음으로 제공하는 C 라이브러리 함수입니다.
Linux 커널은 fork(), vfork(), clone() 시스템 콜을 모두 같은 함수인 kernel_clone()으로 처리하고, 부모와 무엇을 공유할지는 플래그로 정합니다. 이 글의 환경인 x86-64의 glibc 2.39에서 fork() 함수는 clone() 시스템 콜을 호출하고, vfork() 함수는 별도의 vfork() 시스템 콜을 그대로 호출합니다. 같은 glibc 2.39라도 AArch64의 vfork 구현은 clone() 시스템 콜을 사용하므로 아키텍처에 따라 호출 경로가 다릅니다. vfork(2) 매뉴얼은 vfork()를 CLONE_VM | CLONE_VFORK | SIGCHLD 플래그를 준 clone()과 같다고 설명합니다. 뒤에 나올 strace 결과에 이 플래그가 나옵니다.
posix_spawn()만 계층이 다릅니다. POSIX가 명세하고 C 라이브러리가 구현한 함수여서 대응하는 시스템 콜이 없고, 내부에서는 앞의 두 방식 중 하나나 vfork()와 같은 플래그를 준 clone()을 골라 씁니다.
세 방식 모두 JDK가 직접 구현하지 않고 glibc의 함수를 호출합니다.
JVM의 프로세스 생성 코드가 들어 있는 libjava.so의 동적 심볼에서 이를 확인할 수 있습니다.
$ nm -D $JAVA_HOME/lib/libjava.so | grep -E 'posix_spawn|fork'
U fork@GLIBC_2.2.5
00000000000125c0 T Java_java_lang_ProcessImpl_forkAndExec
U posix_spawn@GLIBC_2.15
U vfork@GLIBC_2.2.5T는 이 파일이 정의한 심볼, U는 정의하지 않고 실행 시점에 다른 라이브러리에서 찾는 심볼입니다.
OpenJDK가 만든 것은 네이티브 메서드인 forkAndExec 이고, 세 실행 방식에 해당하는 함수는 모두 @GLIBC_ 버전 태그가 붙은 glibc 심볼로 연결되어 있습니다.
그래서 같은 POSIX_SPAWN 설정이라도 libc와 그 버전에 따라 실제 동작이 달라집니다.
glibc가 아닌 musl에 링크된 JDK라면 같은 자리에 musl의 구현이 들어갑니다.
세 방식의 장단점은 다음과 같습니다.
| 방식 | 장점 | 단점 |
|---|---|---|
|
자식의 주소 공간이 분리되어 부모 메모리를 훼손하지 않고 파일 디스크립터 정리나 작업 디렉터리 변경 같은 준비 작업을 할 수 있음 |
쓰기 시 복사(copy-on-write)로 페이지 복사는 미루지만 페이지 테이블은 복사하므로 힙이 클수록 생성 비용이 커지고, 커널의 overcommit 판정 대상이 됨 |
|
페이지 테이블을 복사하지 않아 생성 비용이 부모의 힙 크기와 거의 무관함 |
자식이 |
|
준비 작업을 라이브러리가 정한 방식으로 처리하고, glibc 2.24부터는 |
자식이 할 수 있는 준비 작업이 라이브러리가 지원하는 항목으로 제한되고, 내부 구현이 libc와 그 버전에 따라 다름 |
다만 fork()도 자식이 execve() 전에 임의의 함수를 호출해도 된다는 뜻은 아닙니다. fork(2) 매뉴얼은 멀티스레드 프로그램에서 fork()한 자식이 execve()까지 안전하게 호출할 수 있는 함수를 async-signal-safe 함수로 제한합니다. 다른 스레드는 자식에 복제되지 않지만 그 스레드가 잡고 있던 잠금 상태는 남을 수 있기 때문입니다.
vfork(2) 매뉴얼은 fork()의 비용을 "부모의 페이지 테이블을 복제하고 고유한 task 구조체를 만드는 시간과 메모리"라고 적었습니다.
이 비용은 부모의 힙이 클수록 커집니다. 뒤의 측정에서 FORK 방식으로 명령 하나를 실행하는 시간은 256MB 힙에서 16~20ms였지만 8GB 힙에서는 230~240ms로 늘었습니다.
vfork()의 제약은 vfork(2) 매뉴얼에 더 강하게 적혀 있습니다. 반환값을 담을 pid_t 변수 외의 데이터를 고치거나, vfork()를 호출한 함수에서 반환하거나, _exit()와 execve() 외의 함수를 부르면 동작이 정의되지 않습니다(undefined behavior). 자식이 부모와 공유하는 메모리와 스택을 고치므로, 부모가 재개된 뒤의 결과를 예측할 수 없기 때문입니다.
OpenJDK는 이 세 방식을 차례로 거쳤습니다. 처음에는 fork()를 썼지만 큰 힙에서 생성 비용이 문제가 되자 JDK 7에서 vfork()를 기본값으로 바꿨습니다. 그런데 JDK는 vfork()와 execve() 사이에서 파일 디스크립터를 닫고 작업 디렉터리를 바꾸는 준비 작업을 했고, 이는 방금 본 vfork()의 제약을 어기는 것이었습니다. 실행 비용은 줄였지만 안전성을 희생한 선택이었습니다. JDK 13에서 기본값이 된 POSIX_SPAWN은 이 준비 작업을 부모와 메모리를 공유하지 않는 별도 프로세스로 옮겨서, fork()의 복사 비용과 vfork()의 제약 위반을 함께 피합니다.
세 방식은 구현 전용 시스템 속성인 jdk.lang.Process.launchMechanism에 각각 FORK, VFORK, POSIX_SPAWN으로 대응합니다.
JDK 25의 ProcessImpl.java에 이 세 값이 선언되어 있고, Linux에서는 셋 다 지정할 수 있되 VFORK에는 경고가 따릅니다.
기본값의 변천은 아래와 같습니다. JDK 27 항목은 정식 출시 결과가 아니라 2026-09-06 현재 개발 버전에 반영된 내용입니다.
| JDK | Linux에서의 변화 |
|---|---|
6 |
|
7 |
|
12 |
|
13 |
|
25 |
|
27 |
개발 버전에서 |
VFORK가 없어진 사정과 남은 설정의 정리는 이 장의 마지막 절에서 다룹니다.
JDK 13부터 기본값인 POSIX_SPAWN이 준비 작업을 별도 프로세스로 옮기는 구조는 다음 절에서 살펴봅니다.
POSIX_SPAWN의 동작
posix_spawn()은 자식 생성과 execve(), 그 사이의 준비 작업을 한 묶음으로 제공합니다.
Windows의 CreateProcess()와 유사합니다.
JDK는 이 함수로 jspawnhelper라는 작은 실행 파일을 먼저 띄우고, jspawnhelper가 파이프로 넘겨받은 설정에 따라 파일 디스크립터와 작업 디렉터리를 정리한 뒤 실제 명령을 다시 execve()합니다. 이 구조는 JDK 25 소스의 ProcessImpl_md.c 상단 주석에 설명되어 있습니다.
helper를 한 번 더 거치는 이유는 앞 절에서 본 안전 문제 때문입니다.
파일 디스크립터 닫기와 작업 디렉터리 변경 같은 준비 작업을 첫 번째 execve()로 실행된 jspawnhelper, 즉 부모와 메모리를 공유하지 않는 별도 프로세스 안에서 하면 vfork()의 제약을 어기지 않습니다.
같은 주석은 이를 "준비 작업을 첫 exec 뒤로 옮겨 취약한 시간 창을 줄인다"고 설명합니다.
프로그램이 호출하는 시스템 콜을 순서대로 기록하는 도구인 strace로 보면 execve가 두 번 나옵니다.
아래는 echo hello를 실행하는 ProcessRunner.java를 기본 설정으로 실행했을 때의 시스템 콜 중 프로세스 생성과 관련된 부분입니다. 경로는 줄였습니다.
$ strace -f -e trace=clone,clone3,vfork,execve -o trace.txt java ProcessRunner
$ grep -v CLONE_THREAD trace.txt | grep -E 'clone|vfork|execve'
285583 clone3({flags=CLONE_VM|CLONE_VFORK|CLONE_CLEAR_SIGHAND, exit_signal=SIGCHLD, stack=..., stack_size=0x9000}, 88 <unfinished ...>
285603 execve("$JAVA_HOME/lib/jspawnhelper", ["$JAVA_HOME/lib/jspawnhelper", "25+36-LTS", "10:11:13"], ...) = 0
285603 execve("/usr/bin/echo", ["echo", "hello"], ...) = 0이 실행에서는 vfork() 시스템 콜이 나오지 않았습니다.
glibc 2.39의 posix_spawn()이 clone3 시스템 콜에 CLONE_VM과 CLONE_VFORK 플래그를 주어 자식을 생성했습니다.
환경에 따라 clone() 시스템 콜을 쓸 수도 있습니다. glibc 2.39의 posix_spawn 구현은 clone3 호출이 ENOSYS나 EINVAL로 실패하면 clone()으로 대체합니다.
CLONE_VM은 자식이 부모의 주소 공간을 그대로 공유한다는 뜻이므로, 힙 매핑과 페이지 테이블을 복사하지 않습니다.
CLONE_VFORK는 자식이 execve()하거나 끝날 때까지 부모의 호출 스레드를 멈춥니다.
CLONE_VM 덕분에 생성 비용은 힙 크기와 거의 무관합니다.
뒤의 측정에서 이를 확인합니다. 같은 프로그램을 -Djdk.lang.Process.launchMechanism=FORK로 실행하면 CLONE_VM 플래그 없이 clone 시스템 콜을 불러 주소 공간을 복제하고, jspawnhelper 없이 곧바로 /usr/bin/echo를 execve합니다.
posix_spawn(3) 매뉴얼에 따르면 glibc 2.24부터 posix_spawn()은 CLONE_VM과 CLONE_VFORK 플래그로 clone()을 호출합니다.
자식 프로세스에 별도 스택을 주고, 생성 과정에서 시그널을 차단하고 자식의 핸들러를 정리해 부모 스택과 시그널 처리에 관한 위험을 줄입니다.
JDK 25 소스의 주석도 이 이유로 glibc 2.24 이상의 방식을 가장 좋은 선택으로 설명하며, musl 역시 이 clone() 방식을 사용해 왔다고 적었습니다.
vfork() 함수 자체가 glibc에서 없어진 것은 아닙니다.
jspawnhelper가 별도 실행 파일이라는 점은 JDK를 갱신할 때 문제가 될 수 있습니다.
실행 중인 JVM이 사용하는 JDK 경로의 파일을 덮어쓰면, 메모리에 적재된 JVM 코드와 디스크의 helper 버전이 달라져 외부 명령 실행이 실패할 수 있습니다.
JDK-8325621은 자동 업데이트로 생긴 이런 불일치를 배경으로 helper의 버전 검사를 보강했습니다.
JDK를 갱신할 때는 실행 중인 JVM이 쓰는 디렉터리를 덮어쓰지 말고 새 디렉터리에 설치한 뒤, JVM을 재시작하면서 새 경로로 전환하는 편이 좋습니다.
helper 실행 오류에는 권한이나 설치 문제 같은 다른 원인도 있으므로 오류 메시지와 설치 상태를 먼저 확인해야 합니다.
JDK-8357090의 CSR은 posix_spawn()의 예기치 않은 문제를 우회할 수 있도록 FORK를 대안으로 둔다고 설명합니다.
jspawnhelper 관련 오류가 반복되는데 원인을 바로 찾기 어렵다면 JVM 시작 옵션에 -Djdk.lang.Process.launchMechanism=FORK를 주어 임시 회피할 수 있습니다.
다음 절에서 살펴볼 overcommit 정책에 따른 메모리 부담과 실행 지연을 감수하는 선택이며, 실행 중인 JVM에 즉시 적용하는 설정은 아닙니다.
FORK의 메모리 비용과 실행 지연
FORK를 선택하면 부모 JVM의 주소 공간 복제 비용을 고려해야 합니다.
fork()는 부모의 가상 주소 공간을 그대로 복제한 자식 프로세스를 만드는데, Linux는 쓰기 시 복사(copy-on-write)로 실제 페이지 복사는 미루지만 페이지 테이블은 복사합니다.
커널의 메모리 overcommit 정책에 따라 자식이 쓸지도 모르는 메모리를 미리 계산해서 생성을 거절할 수도 있습니다.
자식이 곧바로 execve()로 작은 프로그램으로 바뀌더라도 이 검사를 거칩니다.
/proc/sys/vm/overcommit_memory 파일로 노출되는 Linux 커널 설정 vm.overcommit_memory의 기본값 0은 "명백한 overcommit만 거절하는" 모드입니다.
커널 5.1의 코드는 이 판정에 여유 메모리, 페이지 캐시, 스왑 여유분 등을 반영했습니다. fork()가 힙 매핑을 복제할 때 요구하는 크기가 이 계산값을 넘으면 메모리 부족을 뜻하는 오류 코드 ENOMEM으로 거절될 수 있었습니다.
커널은 이 판정이 지나치게 엄격해지지 않도록 몇 가지 규칙을 두고 있고, 버전이 올라가면서 보강되기도 했습니다. 두 가지 예를 들면 다음과 같습니다.
-
vm.overcommit_memory=2로 commit 한도를 엄격히 적용한 서버에서도fork()시점의 commit 검사는 부모의 전체 주소 공간 크기를 무조건 더하지는 않습니다. private writable 매핑처럼 커널이 commit 총량에 넣어 세는 매핑의 크기만 비용으로 계산합니다. -
커널 5.2에 들어간 mm: fix false-positive OVERCOMMIT_GUESS failures 패치는 모드 0의 판정을 "요청 크기가 전체 RAM과 스왑의 합을 넘는지"로 단순화했습니다. 여유 메모리가 적다는 이유만으로 큰 매핑의 복제를 거절하던 조건이 완화된 것입니다.
그럼에도 FORK가 항상 성공하는 것은 아닙니다. 모드 2에서는 Java 힙처럼 큰 익명 private writable 매핑이 비용에 포함되므로 남은 commit 한도를 넘으면 프로세스 생성이 실패하고, 모드 0에서도 페이지 테이블 등 커널 메모리의 실제 할당은 실패할 수 있습니다.
생성이 거절되지 않더라도 시간 비용은 남습니다.
overcommit 판정이 완화됐어도 fork()가 페이지 테이블을 복사한다는 사실은 변하지 않았습니다.
실제로 접근한 힙 영역과 페이지 크기 등에 따라 복사 비용이 달라집니다.
반면 POSIX_SPAWN은 CLONE_VM으로 주소 공간을 공유하므로 이 복사가 없습니다.
힙을 미리 할당한 상태에서 true 명령을 30번 실행하는 데 걸린 시간을 실행 방식별로 쟀습니다.
측정 코드는 SpawnBench.java이고, -Xms와 -Xmx를 같은 값으로 맞추고 -XX:+AlwaysPreTouch 옵션으로 힙을 미리 접근한 뒤 측정했습니다.
각 실행에서 5회 예열 후 30회의 start().waitFor() 평균을 구했으므로, 순수한 생성 시간뿐 아니라 명령 실행과 종료 대기도 포함합니다.
아래는 글 작성 당시 두 번 실행한 값입니다.
| 힙 크기 | POSIX_SPAWN (ms/회) | FORK (ms/회) |
|---|---|---|
256MB |
1.5, 1.2 |
15.9, 20.2 |
2GB |
1.6, 1.9 |
120.8, 140.7 |
8GB |
2.0, 2.1 |
243.5, 231.2 |
이 측정에서 POSIX_SPAWN은 약 1~2ms 범위였고, FORK는 힙이 커질수록 느려져 8GB에서는 100배 넘게 차이가 났습니다.
힙 크기에 정확히 비례하거나 모든 환경에서 이 배율이 나온다는 뜻은 아닙니다.
2026-09-06 재측정에서도 같은 경향을 확인했지만 절대 시간은 달랐습니다.
FORK 방식에서 주소 공간을 복제하는 Linux 6.17의 dup_mmap()은 부모 프로세스의 주소 공간 잠금(mmap_lock)을 쓰기 모드로 잡은 상태에서 매핑과 페이지 테이블을 복제합니다.
그동안 이 잠금이 필요한 메모리 매핑 변경을 시도하는 다른 스레드는 기다려야 합니다.
요청 처리 중 외부 명령을 동기 실행하는 웹 애플리케이션이라면 이 비용이 응답 시간에 더해질 수 있습니다.
jspawnhelper 문제를 임시로 피하는 경우가 아니라면, 지금은 이런 단점을 감수하면서 기본값을 FORK로 바꿀 만한 이유가 없습니다.
JVM 업그레이드 때 정리할 VFORK 설정
JVM 버전을 25 이상으로 업그레이드할 때 -Djdk.lang.Process.launchMechanism=VFORK 설정이 남아 있다면 제거하는 편이 좋습니다.
이 설정이 남아 있을 만한 자리는 JVM 실행 스크립트, Dockerfile의 JAVA_OPTS, 애플리케이션 서버의 기동 옵션입니다.
JDK 25에서는 경고가 나오고, JDK 27 개발 버전에 반영된 변경에서는 FORK로 대체되어 큰 힙에서 실행 지연이 커질 수 있습니다.
Linux에서는 JDK 7부터 12까지 vfork()가 기본이었으므로, JDK 13에서 기본값이 POSIX_SPAWN으로 바뀔 때 이전 동작을 유지하려고 이 속성을 명시적으로 적어 둔 경우가 있습니다.
당시 glibc가 2.24보다 오래된 환경이었더라도 이 값을 지정할 필요는 없었습니다.
JDK 13 소스의 주석에 따르면 glibc 2.4~2.23의 posix_spawn()은 호출 인자에 따라 fork()와 vfork() 중 하나를 고르는데, JDK의 호출 방식은 vfork()를 쓰는 조건에 해당합니다.
glibc 2.24부터는 앞에서 본 별도 스택과 시그널 처리를 갖춘 clone() 기반 구현으로 바뀌었습니다.
지금은 이 값을 지정할 이유가 없으므로 속성을 지우고 기본값으로 돌아가면 됩니다.
vfork()를 기본값으로 삼은 JDK 7의 선택은 당시에도 논란거리였습니다.
vfork()는 표준 함수가 아닙니다.
vfork(2) 매뉴얼의 STANDARDS 항목은 "None"이고, HISTORY 항목은 3.0BSD에서 등장한 이 함수가 POSIX.1-2001에 OBSOLETE로 표시됐다가 POSIX.1-2008에서 명세가 삭제됐다고 적습니다.
4.4BSD는 vfork()를 아예 fork()와 같은 것으로 만들었고, Linux도 2.2.0-pre6 무렵까지는 fork()와 같게 동작하다가 2.2.0-pre9부터 독립된 시스템 콜이 됐습니다.
그래도 없어진 쪽은 커널의 vfork()가 아니라 JDK의 VFORK 모드입니다.
표준에서 빠졌기 때문도 커널이 바뀌었기 때문도 아니라, 앞에서 본 대로 JDK 자신이 vfork()와 execve() 사이에서 하던 작업이 안전하지 않아서입니다.
JDK 25에서 이 옵션을 지정하면 아래 경고가 표준 오류에 출력됩니다.
$ java -Djdk.lang.Process.launchMechanism=VFORK ProcessRunner
VFORK MODE DEPRECATED
The VFORK launch mechanism has been deprecated for being dangerous.
It will be removed in a future java version. Either remove the
jdk.lang.Process.launchMechanism property (preferred) or use FORK mode
instead (-Djdk.lang.Process.launchMechanism=FORK).이 글의 예제와 측정은 JDK 25 기준입니다.
구버전 JDK에 적용할 때는 실행 방식과 API 지원 범위를 따로 확인해야 합니다.
예를 들어 OpenJDK 11u는 11.0.4부터 POSIX_SPAWN을 옵션으로 지정할 수 있지만 기본값은 vfork()이고, OpenJDK 8u의 Linux 구현은 2026-09-06 현재 이 옵션을 지원하지 않습니다.
마치며
외부 프로세스 실행 코드는 출력 처리, 시간제한, 종료 정책을 함께 설계해야 합니다. 출력을 가공할 필요가 없으면 Redirect.DISCARD나 inheritIO()를 쓰고, 표준 출력과 표준 오류를 따로 받아야 하면 두 스트림을 동시에 읽어야 합니다. 표준 입력을 읽는 명령에는 입력을 다 쓴 뒤 스트림을 닫아 EOF를 받게 해야 합니다. 시간제한 뒤에는 종료 요청뿐 아니라 강제 종료 여부와 자원 정리까지 챙겨야 합니다.
zt-exec과 Commons Exec은 이 코드를 줄여 줍니다. 출력과 종료 코드의 기본값, 시간 초과를 알리는 방식, 의존성을 비교해 프로젝트에 맞는 쪽을 고르면 됩니다. 두 라이브러리 모두 기본 destroy()만으로 강제 종료까지 보장하지는 않으며, 후손 정리에는 같은 그룹에 남은 프로세스에 시그널을 보내는 방법이나 cgroup 단위의 종료를 사용할 수 있습니다.
Linux의 JDK 25에서는 기본값인 POSIX_SPAWN을 유지하는 편이 무난합니다.
참고 자료
-
JDK 문서
-
Runtime (Java SE 25):
exec(String)계열의 deprecation 사유 -
Runtime.java (JDK 25+36):
exec()의ProcessBuilder위임 구현 -
ProcessImpl_md.c (JDK 25+36): 실행 방식별 장단점과 glibc, musl의
posix_spawn()구현을 설명한 주석
-
라이브러리
-
ZT Process Executor (zt-exec): README의 사용 예
-
ZT Process Executor CHANGELOG: 1.13.0의 변경 사항과 릴리스 날짜
-
Apache Commons Exec Changes: 1.4.0 이후의 builder API와
Duration도입
-
-
OpenJDK 이슈
-
JDK-6868160 (process) Use vfork, not fork, on Linux to avoid swap exhaustion
-
JDK-8212828 (process) Provide a way for Runtime.exec to use posix_spawn on linux
-
JDK-8213192 (process) Change the Process launch mechanism default on Linux to be posix_spawn
-
JDK-8357180 Deprecate VFORK launch mechanism from Process implementation (linux)
-
JDK-8357090 Remove VFORK launch mechanism from Process implementation (linux)
-
JDK-8357089 구현 커밋: JDK 27 개발 버전의
VFORK제거와FORK대체
-
-
Linux 매뉴얼과 커널
-
pipe(7): 파이프 용량
-
setsid(1): 그룹 리더가 아닐 때 fork 없이 실행하는 동작
-
setsid(2), kill(1) (procps-ng), kill(2): 새 세션 생성, 음수 PID로 그룹에 시그널 보내기, 시그널 0의 존재 확인
-
PR_SET_CHILD_SUBREAPER(2const): subreaper의 재부모화
-
Control Group v2: 프로세스 이동 권한과
cgroup.kill -
systemd-run(1), systemd.kill(5): scope 단위 실행과
KillMode -
posix_spawn(3): glibc 2.24 이후의 구현
-
Linux 5.2 mm/util.c:
__vm_enough_memory()의 모드 0 판정 -
Linux 6.17 mm/mmap.c:
dup_mmap()의 잠금과 페이지 테이블 복제 -
mm: fix false-positive OVERCOMMIT_GUESS failures: 커널 5.2의 휴리스틱 변경 패치
-
-
When Runtime.exec() won’t: 2000년에 나온 Michael Daconta의 글
-
Java에서 외부 프로세스를 실행할 때 (NAVER D2, 2015):
fork()의 메모리 문제와 JDK 7의vfork()도입 배경
Twitter
Facebook
Reddit
LinkedIn
Email