mvc api 호출 시 thread 상태에 대해서 궁금한 점이 있습니다..

- 기존 답변이 잘못 되어 댓글에 추가로 답변 남겨놓았습니다. 굉장히 흥미있는 내용이라 다음 환경에서 시도해봤습니다. 1. 8080 포트에서 실행 중인 Spring MVC 클라이언트 2. 8081 포트에서 실행 중인 Spring MVC 서버 3. M1 macOS 14.1 테스트 결과는 작성자님과 동일합니다. Park 상태에서 Runnable 상태로 변화하는 이유는, JVM에서 관리하는 User Thread는 실행 가능한 상태가 맞기 때문입니다. 대신 Blocking 상태에 있는 것은 OS Kernel Thread 입니다. 혼동이 오는 이유는 Runnable에 대한 정의가 제대로 되지 않아서 그런 것 같습니다. 오라클 공식 문서에 따르면 Runnable은 다음처럼 정의되어 있습니다. “실행 중인 Thread의 상태이다. 이 상태는 JVM에서 실행 중이지만, 운영 체제의 프로세서처럼 외부 자원을 기다리고 있을 수 있다.” 코드로 남겨놓은 로그를 보시면 SocketDispatcher.read0 같은 메소드를 호출하시는 것을 확인할 수 있습니다. 이는 운영체제 네트워크 I/O 시스템 콜을 호출한 겁니다. 이런 네이티브 메소드는 JVM 바깥에서 실행됩니다. Kernel Thread의 네트워크 작업이 끝날 때까지, User Thread는 Runnable 상태로 대기합니다. 그렇다면 왜 User Thread는 Kernel Thread처럼 동일하게 Blocking이 아니라 Runnable로 관리하는지 의문이 생길 수 있습니다. 이런 저런 자료를 찾아보며 추측한 내용은 다음과 같습니다. 1. 운영 체제와의 독립성 확보: 언어마다 Thread 관리 방법이 다른 것처럼, OS도 방법이 서로 다르다. 따라서 JVM에서 Kernel Thread 상태와 Tight Coupling 하게 구성한다면, JVM 철학과 정반대의 구현이다. JVM을 사용하는 개발자도 OS에 따라 Kernel Thread를 명확히 알아야하므로 이식성이 떨어진다. 2. 성능 최적화: Kernel Thread 작업이 끝나자마자 바로 작업을 처리할 수 있도록 우선순위를 높여둔다. OS별 Kernel Thread 상태를 신경 안 써도 돼서 스케쥴링이 간단해진다. 정리하자면 JVM 철학, 그리고 자원 투자 대비 성능이 안나와서 그런 것 같다는 생각입니다. Kernel Thread 같은 외부 자원을 기다리는 동안 내부적으로 무엇을 하고 있는지, 상태는 어떤지 정확히 관리하면서 싱크 맞추는 건 효율이 별로라는 거죠. 가능한지도 모르겠네요..? 사실상 2개 트랙이면서 별개 내용이라고 생각하시는게 편하실 겁니다. **park 상태는 그냥 HTTP 요청 이벤트를 기다리게끔 LockSupport로 설정해놓은거라 그런 겁니다. 참고자료 오라클 공식 문서: https://docs.oracle.com/javase/7/docs/api/java/lang/Thread.State.html

1"http-nio-8080-exec-10" #50 [38147] daemon prio=5 os_prio=31 cpu=3.58ms elapsed=442.25s tid=0x0000000144b75a00 nid=38147 runnable  [0x0000000174d27000]
2   java.lang.Thread.State: RUNNABLE
3        at sun.nio.ch.SocketDispatcher.read0(java.base@19.0.2/Native Method)
4        at sun.nio.ch.SocketDispatcher.read(java.base@19.0.2/SocketDispatcher.java:47)
5        at sun.nio.ch.NioSocketImpl.tryRead(java.base@19.0.2/NioSocketImpl.java:251)