Java NIO Selector 내부 구조 — epoll 위에 세운 자바 비동기 IO
한 스레드가 수천 개의 소켓을 들고 있을 수 있는 이유는 무엇일까요. Netty, Reactor Netty, Spring WebFlux, 심지어 JDK 13 이후의 평범한 java.net.Socket까지, JVM 위 거의 모든 IO가 결국 같은 한 가지 기둥 위에 서 있습니다. 그 기둥의 이름은 Selector입니다. 이 글은 자바 Selector API가
Search for a command to run...
Articles tagged with #jvm
한 스레드가 수천 개의 소켓을 들고 있을 수 있는 이유는 무엇일까요. Netty, Reactor Netty, Spring WebFlux, 심지어 JDK 13 이후의 평범한 java.net.Socket까지, JVM 위 거의 모든 IO가 결국 같은 한 가지 기둥 위에 서 있습니다. 그 기둥의 이름은 Selector입니다. 이 글은 자바 Selector API가
java.lang.String을 직접 만들어 rt.jar의 String을 갈아치울 수 없는 이유, Tomcat 위에 올린 웹앱이 컨테이너의 라이브러리를 무시하고 자신의 버전을 우선 쓰는 이유, JDBC DriverManager가 어떻게 클래스패스 어디에 있는지도 모르는 드라이버를 발견해서 로드하는지를 설명하는 한 가지 메커니즘이 있습니다. JVM의 Clas
JVM 진영에서 AI 에이전트를 진지하게 만들려고 하면 곧 두 이름과 마주칩니다. JetBrains가 만든 Koog와 Spring 팀이 만든 Spring AI입니다. 둘 다 "JVM에서 LLM을 잘 다루자"는 목표를 공유하지만, 출발점과 강조점이 매우 다릅니다. 이 글은 두 프레임워크의 핵심 추상화, 코드 스타일, 운영 기능, 적합한 사용처를 같은 다이어그
이 글은 Java 21에서 정식으로 도입된 Virtual Threads(JEP 444)와 Java 24에서 핀닝 문제를 정리한 JEP 491의 내부 동작을 들여다봅니다. Thread-per-request 모델로 수십만 동시 요청을 처리할 수 있게 된 배경과, 그 아래에서 Continuation과 Carrier thread가 어떻게 협력하는지를 설명합니다. 왜 Virtual Threads가 필요했나 Java 1.0부터 java.lang.Thre...
Java가 약속한 것 중 하나는 "메모리는 내가 관리할게"였다. C/C++ 개발자들이 malloc과 free로 메모리와 씨름하던 시절, Java는 Garbage Collector(GC)라는 자동 메모리 관리자를 들고 나왔다. 개발자는 객체를 만들기만 하면 되고, 치우는 건 GC가 알아서 한다. 하지만 "알아서"라는 말에는 대가가 있었다. GC가 동작하는 동안 애플리케이션이 멈추는 것이다. 이 멈춤을 Stop-The-World(STW) 일시 정지...