이 문서를 통해 아래 질문들에 답할 수 있게 됩니다.
Process와 Thread 차이에서 붙잡아야 할 핵심 판단 기준은 무엇인가?주소 공간과 공유 자원으로 구분한다라는 기준은 어떤 JVM/OS 신호로 확인되는가?- Java/Spring 코드에서
Process와 Thread 차이판단 기준은 어떤 장애 신호로 드러나는가?
개요
이 문서의 주제는 Process와 Thread 차이이다. Process와 thread의 memory, file descriptor, crash 영향, 요청 처리상의 차이를 정리한다.
먼저 붙잡을 기준은 다음 문장이다. 주소 공간과 공유 자원으로 구분한다. 이 문서는 이 기준을 Java/Spring 실행 흐름, JVM/OS 관찰 지표, 장애 판단 순서로 연결한다.
핵심 모델
- 판단 기준: process는 자원 경계이고 thread는 그 안의 실행 흐름이다.
- Process는 PID, 주소 공간, file descriptor table, signal, resource limit을 가진 운영 단위다.
- Thread는 같은 process 안에서 heap과 FD를 공유하지만 stack과 실행 위치는 각자 가진다.
- Java process 하나가 죽으면 그 안의 모든 request thread, scheduler, pool이 함께 사라진다.
- Thread leak은 process 재시작 전까지 누적되며 stack memory와 scheduling 비용을 늘린다.
문서별 핵심 구분
- process는 독립 주소 공간과 file descriptor table을 갖는다.
- thread는 같은 process 안에서 heap과 열린 자원을 공유한다.
- 하나의 thread 문제가 process 전체 응답 지연으로 번질 수 있다.
원리
Process는 독립된 실행 컨테이너다. 주소 공간, file descriptor table, environment, current working directory, signal, OS limit이 process 단위로 붙는다. Java 서버 하나가 PID 하나로 떠 있다면 그 안의 모든 요청 thread는 같은 process 자원을 공유한다.
Thread는 같은 process 안에서 실행되는 흐름이다. 각 thread는 자기 stack과 register 상태를 갖지만 heap, static 객체, connection pool, 열린 socket과 file descriptor는 process 안에서 공유한다.
이 차이는 장애 영향 범위를 바꾼다. thread 하나가 BLOCKED 상태가 되어도 process가 즉시 죽지는 않지만, 같은 pool의 worker thread가 모두 막히면 API 전체가 멈춘다. 반대로 process가 OOM kill되거나 crash하면 그 안의 모든 thread와 in-memory state가 함께 사라진다.
Process와 Thread 차이 관점에서 중요한 점은 공유 자원과 격리 범위를 구분하는 것이다. thread leak은 thread 개수 증가로 보이지만 process RSS와 native stack memory도 함께 밀어 올릴 수 있고, file descriptor leak은 특정 thread가 열어도 process 단위 한계로 터진다.
Java/Spring 연결
- Spring Boot 애플리케이션은 보통 하나의 JVM process이고, Tomcat worker와 scheduler thread는 그 process 안에서 움직인다.
systemd, container runtime,/proc/<pid>/limits는 process 경계의 실행 조건을 보여 준다.- Thread dump는 process 내부 실행 흐름을 보여 주지만 process limit, FD, RSS는 OS에서 확인해야 한다.
- Graceful shutdown은 process 종료와 thread 작업 완료 사이의 계약이다.
- Process restart는 모든 thread 상태와 heap 증거를 지우므로 재시작 전 필요한 dump를 먼저 남긴다.
코드와 설정 예시
Java process PID 1234
heap: all request threads share service objects and caches
fd table: accepted sockets, DB sockets, log files
thread http-nio-1: own stack, shared heap access
thread http-nio-2: own stack, shared heap access예시는 process와 thread의 소유 범위를 나누기 위한 것이다. thread마다 stack은 따로 있지만 heap과 file descriptor table은 process 안에서 공유되므로, 한 요청 경로의 누수가 process 전체 한계로 드러날 수 있다.
관찰 명령
ps -ef | grep java
cat /proc/<pid>/status
ls /proc/<pid>/task | wc -l
ls /proc/<pid>/fd | wc -lProcess와 Thread 차이 관찰 명령은 결론이 아니라 가설 확인 도구다. 운영 중에는 반복 간격, 대상 PID, 수집 시각을 함께 남기고 출력이 큰 명령은 범위를 제한한다.
지표 해석
| 신호 | 먼저 의심할 것 | 다음 확인 |
|---|---|---|
| RUNNABLE thread가 core보다 많음 | CPU 경합 또는 native I/O 대기 | top -H, stack trace, load average |
| BLOCKED가 특정 lock에 몰림 | synchronized/monitor 경합 | lock owner와 기다리는 thread |
| WAITING/TIMED_WAITING이 pool에 몰림 | queue 대기, connection 대기, sleep/retry | executor, Hikari, timeout 지표 |
| thread 수가 계속 증가 | unbounded executor 또는 thread leak | thread name 분포와 생성 위치 |
Process와 Thread 차이에서는 핵심 신호와 보조 지표를 같은 시간축에서 맞춘다. 먼저 변한 신호와 뒤따라 포화된 신호를 분리해야 원인과 결과를 구분할 수 있다.
장애 상황에서 보는 순서
- PID가 실제 서비스 process인지
ps와 service manager에서 확인한다. - process RSS, FD 수, thread 수를 같은 시각에 남긴다.
- thread dump로 어떤 thread 그룹이 증가했는지 본다.
- 최근 restart, OOM kill, signal 종료 기록을
journalctl에서 확인한다. - process limit과 JVM option이 현재 실행값에 반영되어 있는지 확인한다.
이 순서는 process 경계 문제와 thread 내부 문제를 섞지 않기 위한 루틴이다.
실전 팁
/proc/<pid>/task로 thread 수를 확인한다.- thread 증가는 stack memory 증가로도 이어진다.
- process restart는 모든 thread와 in-memory state를 함께 잃는 조치다.
- FD 누수는 process 단위 한계로 나타난다.
- thread name 규칙을 정하면 dump 분석 시간이 줄어든다.
주니어 팁
Process와 Thread 차이주제는 용어 암기보다 정상 상태와 장애 상태에서 어떤 증거가 달라지는지 연결해 익힌다.- 처음에는
Process와 Thread 차이를 재현 가능한 기본 명령과 Actuator 지표로 확인하는 습관부터 만든다. Process와 Thread 차이숫자는 크기 자체보다 평소 기준선에서 얼마나 벗어났는지로 판단한다.
시니어 팁
Process와 Thread 차이주제의 영향이 pool, queue, retry, timeout으로 번지는 경로를 설계 리뷰에 포함한다.Process와 Thread 차이runbook에는 실행 명령, 정상 범위, 해석 기준, 금지할 대응을 같이 둔다.Process와 Thread 차이판단이 container, LB, 다중 인스턴스 환경에서도 같은 의미인지 확인한다.
Guru급 팁
Process와 Thread 차이주제는 단일 snapshot보다 변화 방향이 중요하다. 같은 명령을 간격을 두고 실행해 상태가 증가, 유지, 회복 중 어디인지 본다.- 고급 도구는
Process와 Thread 차이가설을 좁힐 때만 사용하고 기본 지표와 모순되는지 먼저 확인한다. Process와 Thread 차이조치 후에는 CPU, memory, socket, disk, pool 중 다음 포화 지점이 어디로 이동했는지 확인한다.
위험 신호!
- process와 thread를 단순 용어 차이로만 기억한다.
- thread leak을 heap leak과 별개로 보지 않는다.
- 한 thread의 무한 루프가 CPU 전체를 압박하는 상황을 놓친다.
- process limit과 JVM 설정을 분리해 보지 않는다.
- restart로 thread 문제 증거를 잃는다.
확인 질문
확인 질문
Process와 Thread 차이주제를 장애 중 확인할 때 Application 로그만으로 부족한 이유는 무엇인가?
- 로그는 코드 경로를 보여 주지만
Process와 Thread 차이의 JVM/OS 자원 상태, 대기 위치, 포화 방향은 별도 지표로 확인해야 하기 때문이다.Process와 Thread 차이관련 설정이나 pool 크기를 바꾸기 전에 확인할 것은 무엇인가?
- 먼저 변한 신호, 하위 자원 capacity, 변경이 완화인지 증폭인지 판단할 기준을
Process와 Thread 차이지표로 확인해야 한다.Process와 Thread 차이재발을 막기 위해 장애 기록에 무엇을 남겨야 하는가?
- 발생 시간, 영향 범위, 사용한 명령,
Process와 Thread 차이핵심 지표, 원인 판단, 완화 조치, 근본 수정, 남은 리스크를 남긴다.