톰캣은 어떻게 수만 개의 요청을 동시에 처리할까

// BIO Connector의 동작 방식 (의사 코드)
class BIOConnector {
    ExecutorService threadPool;

    void acceptConnection() {
        while (true) {
            Socket socket = serverSocket.accept();  // 연결 수락

            // 문제: 스레드 하나가 연결 하나를 전담
            threadPool.execute(() -> {
                try {
                    // 1. 요청 대기 (Blocking!)
                    InputStream input = socket.getInputStream();
                    byte[] data = input.read();  // 데이터 올 때까지 대기

                    // 2. 요청 처리
                    processRequest(data);

                    // 3. 응답 전송
                    OutputStream output = socket.getOutputStream();
                    output.write(response);

                    // 4. 연결 유지 (HTTP Keep-Alive)
                    // 스레드가 계속 점유됨!
                } finally {
                    socket.close();
                }
            });
        }
    }
}

// 최악의 시나리오
class BIOProblem {
    public static void main(String[] args) {
        // 스레드 풀: 200개
        // 동시 연결: 1000개
        // Keep-Alive Timeout: 20초

        // 시나리오:
        // 1000명의 사용자가 접속
        // 각자 요청 1개만 보내고 Keep-Alive로 20초 대기

        // 결과:
        // - 200개 스레드 모두 점유됨
        // - 나머지 800개 연결은 대기
        // - 실제로 CPU는 거의 쉬고 있음!
    }
}

// NIO Connector의 동작 방식 (단순화)
class NIOConnector {
    Selector selector;  // 핵심!

    void run() {
        while (true) {
            // 1. Selector가 여러 연결을 동시에 감시
            int readyCount = selector.select();  // Blocking이지만 여러 채널을 감시

            // 2. 준비된 채널만 처리
            Set<SelectionKey> keys = selector.selectedKeys();
            for (SelectionKey key : keys) {
                if (key.isAcceptable()) {
                    // 새 연결 수락
                    acceptConnection(key);
                } else if (key.isReadable()) {
                    // 데이터 읽기 준비됨 → 이때만 워커 스레드 할당!
                    handleRead(key);
                } else if (key.isWritable()) {
                    // 데이터 쓰기 준비됨
                    handleWrite(key);
                }
            }
        }
    }
}

# 테스트 환경
spring:
  application:
    name: benchmark-test
server:
  tomcat:
    threads:
      max: 200

// 느린 API (의도적으로 3초 대기)
@RestController
class SlowController {

    @GetMapping("/slow")
    public String slowApi() throws InterruptedException {
        Thread.sleep(3000);  // DB 조회나 외부 API 호출 시뮬레이션
        return "Done";
    }
}

동시 사용자: 1000명
요청: GET /slow

결과:
- 처음 200개: 3초 후 응답
- 201~400번: 6초 후 응답
- 401~600번: 9초 후 응답
- 801~1000번: 15초 후 응답

평균 응답 시간: 9초

동시 사용자: 1000명
요청: GET /slow

결과:
- 1000개 모두 약 3~4초 후 응답
- Poller가 1000개 연결을 모두 관리
- 워커 스레드는 실제 처리 시에만 할당

평균 응답 시간: 3.2초

BIO:
연결 수 > 스레드 수 → 큐에서 대기 → 순차 처리

NIO:
연결 수와 무관 → Poller가 모두 감시 → 준비된 것만 워커 스레드 할당

// Acceptor의 역할 (의사 코드)
class Acceptor implements Runnable {
    ServerSocketChannel serverSocket;

    @Override
    public void run() {
        while (running) {
            // 1. 3-way handshake 완료된 연결 수락
            SocketChannel socket = serverSocket.accept();  // Blocking

            // 2. Non-blocking 모드로 설정
            socket.configureBlocking(false);

            // 3. Poller에게 넘김
            PollerEvent event = new PollerEvent(socket, OP_READ);
            poller.register(event);
        }
    }
}

// accept()는 빠르다
class AcceptorPerformance {
    void benchmark() {
        long start = System.nanoTime();
        SocketChannel socket = serverSocket.accept();
        long end = System.nanoTime();

        System.out.println("Accept time: " + (end - start) / 1000 + "μs");
        // 출력: Accept time: 50μs (0.05ms)

        // 초당 처리 가능: 1,000,000 / 50 = 20,000 connections/sec
        // 실제로는 TCP 백로그 큐에서 꺼내기만 하므로 매우 빠름
    }
}

// Poller의 역할 (의사 코드)
class Poller implements Runnable {
    Selector selector;
    Queue<PollerEvent> events;

    @Override
    public void run() {
        while (running) {
            // 1. 새로 등록된 소켓을 Selector에 등록
            processEvents();

            // 2. Selector로 준비된 채널 감지
            int count = selector.select(1000);  // 최대 1초 대기

            if (count > 0) {
                // 3. 준비된 채널 처리
                Iterator<SelectionKey> iterator = selector.selectedKeys().iterator();
                while (iterator.hasNext()) {
                    SelectionKey key = iterator.next();
                    iterator.remove();

                    if (key.isReadable()) {
                        // 데이터 읽기 준비됨!
                        // Executor에게 넘김
                        executor.execute(new SocketProcessor(key));
                    }
                }
            }
        }
    }

    void processEvents() {
        PollerEvent event;
        while ((event = events.poll()) != null) {
            // Acceptor가 넘긴 소켓을 Selector에 등록
            event.socket.register(selector, SelectionKey.OP_READ);
        }
    }
}

// Before (BIO): 1000개 연결 = 1000개 스레드 필요
// 메모리: 1000 × 1MB = 1GB

// After (NIO): 1000개 연결 = Poller 1~2개 + 필요할 때만 워커 스레드
// 메모리: 2MB (Poller) + 동적 할당

// Executor의 역할
class SocketProcessor implements Runnable {
    SelectionKey key;

    @Override
    public void run() {
        try {
            // 1. 소켓에서 데이터 읽기
            SocketChannel channel = (SocketChannel) key.channel();
            ByteBuffer buffer = ByteBuffer.allocate(8192);
            int read = channel.read(buffer);

            // 2. HTTP 요청 파싱
            HttpRequest request = parseHttpRequest(buffer);

            // 3. 서블릿 컨테이너에 전달
            servlet.service(request, response);

            // 4. 응답 전송
            channel.write(responseBuffer);

        } finally {
            // 5. 워커 스레드 즉시 반환!
            // Keep-Alive 연결은 다시 Poller로
            key.interestOps(SelectionKey.OP_READ);
        }
    }
}

BIO:
스레드 할당 → 데이터 대기 (2초) → 처리 (0.1초) → 대기 (Keep-Alive 20초)
스레드 점유 시간: 22.1초

NIO:
Poller 감시 (2초) → 스레드 할당 → 처리 (0.1초) → 스레드 반환 → Poller 감시 (20초)
스레드 점유 시간: 0.1초

// Java Selector의 내부 동작 (Linux)
class EPollSelectorImpl extends SelectorImpl {

    int poll(long timeout) {
        // JNI를 통해 리눅스 epoll_wait 시스템 콜 호출
        return EPoll.wait(pollArrayAddress, NUM_EPOLLEVENTS, timeout, epfd);
    }
}

// 리눅스 커널 수준
// 1. epoll 인스턴스 생성
int epfd = epoll_create1(0);

// 2. 감시할 소켓 등록
struct epoll_event ev;
ev.events = EPOLLIN;  // 읽기 이벤트
ev.data.fd = socket_fd;
epoll_ctl(epfd, EPOLL_CTL_ADD, socket_fd, &ev);

// 3. 이벤트 대기 (Blocking이지만 여러 소켓 동시 감시!)
struct epoll_event events[1000];
int nfds = epoll_wait(epfd, events, 1000, timeout);

// 4. 준비된 소켓만 순회
for (int i = 0; i < nfds; i++) {
    if (events[i].events & EPOLLIN) {
        // 이 소켓은 읽을 데이터가 있음!
        handle_read(events[i].data.fd);
    }
}

// select (옛날 방식)
fd_set readfds;
FD_ZERO(&readfds);
FD_SET(socket1, &readfds);
FD_SET(socket2, &readfds);
// ... 1000개 등록 ...

select(max_fd, &readfds, NULL, NULL, &timeout);

// 문제: 1000개를 매번 순회하며 확인
for (int i = 0; i < 1000; i++) {
    if (FD_ISSET(sockets[i], &readfds)) {
        // 준비됨
    }
}
// 시간 복잡도: O(N)

// epoll (새로운 방식)
int nfds = epoll_wait(epfd, events, 1000, timeout);
// 커널이 준비된 것만 events 배열에 채워줌!

for (int i = 0; i < nfds; i++) {
    // 이미 준비된 것만 순회
}
// 시간 복잡도: O(준비된 개수)

연결 1000개 중 10개만 준비된 경우:

select: 1000번 체크 → 10ms
epoll:  10번만 체크 → 0.1ms

100배 차이!

server:
  tomcat:
    threads:
      max: 200              # maxThreads
    max-connections: 8192   # maxConnections
    accept-count: 100       # acceptCount

// maxThreads = 200이면?
class WorkerThreadPool {
    ExecutorService executor = Executors.newFixedThreadPool(200);

    void handleRequest(HttpRequest request) {
        if (executor.getActiveCount() < 200) {
            // 처리 가능
            executor.submit(() -> processRequest(request));
        } else {
            // 대기 (연결은 유지됨!)
            // Poller가 계속 감시
        }
    }
}

# 시나리오 1: CPU 바운드 작업 (계산 위주)
# 평균 처리 시간: 100ms
# CPU 코어: 8개
# 권장: threads.max = 8~16

# 시나리오 2: I/O 바운드 작업 (DB, 외부 API 호출 위주)
# 평균 처리 시간: 500ms (그 중 450ms는 I/O 대기)
# CPU 코어: 8개
# 권장: threads.max = 100~200

# 시나리오 3: 혼합
# 평균 처리 시간: 200ms (그 중 150ms는 I/O 대기)
# CPU 코어: 8개
# 권장: threads.max = 50~100

// NIO에서 maxConnections의 의미
class NIOEndpoint {
    Semaphore connectionLimitLatch;  // 연결 수 제한

    void setMaxConnections(int max) {
        this.connectionLimitLatch = new Semaphore(max);
    }

    void acceptConnection(SocketChannel socket) {
        if (connectionLimitLatch.tryAcquire()) {
            // 연결 수락
            poller.register(socket);
        } else {
            // 더 이상 연결 받을 수 없음
            // OS accept queue로 이동 (acceptCount)
        }
    }

    void closeConnection(SocketChannel socket) {
        socket.close();
        connectionLimitLatch.release();  // 슬롯 반환
    }
}

메모리 계산:
- 연결 하나당 메모리: 약 50~100KB (TCP 버퍼, 소켓 메타데이터)
- 8192개 연결: 400MB~800MB

CPU 계산:
- Poller의 epoll_wait: O(준비된 개수)
- 8192개 중 100개 준비: 1ms 미만

대부분의 경우 충분!

# 잘못된 상황
server:
  tomcat:
    max-connections: 10000
    threads:
      max: 200

# 문제: 10000개 연결이 들어오면?
# - 200개만 처리 중
# - 9800개는 대기
# - 메모리만 낭비!

# 올바른 설정
server:
  tomcat:
    max-connections: 500   # threads.max의 2~3배 정도
    threads:
      max: 200

// ServerSocket 생성 시
ServerSocket serverSocket = new ServerSocket(port, acceptCount);

// 리눅스에서 실제 동작
// listen(sockfd, backlog)
listen(server_fd, 100);  // acceptCount = 100

시나리오:
maxConnections = 10
acceptCount = 5
현재 연결: 10개 (가득 참)

새 연결 요청:
1. Tomcat: "maxConnections 가득 참, accept 안 함"
2. OS: "그럼 내가 받아서 큐에 넣어둘게" (최대 5개)
3. 클라이언트: "연결 성공!" (사실은 대기 중)

만약 acceptCount도 가득 차면:
4. OS: "더 이상 못 받음"
5. 클라이언트: "Connection refused" 에러

# Netflix의 설정 (추정)
server:
  tomcat:
    threads:
      max: 300
    max-connections: 400
    accept-count: 10    # 매우 작게!

큰 acceptCount (예: 1000):
- 연결은 성공하지만 30초 동안 대기
- 사용자: "왜 이렇게 느려?" (나쁜 UX)

작은 acceptCount (예: 10):
- 빠르게 "Connection refused" 반환
- 클라이언트: 재시도 또는 다른 서버로 라우팅 (빠른 실패)

# 내가 현재 작업하고 있는 사이드 스트리밍 서비스 (I/O 위주)
server:
  tomcat:
    threads:
      max: 200
      min-spare: 50
    max-connections: 500
    accept-count: 20
    connection-timeout: 20000

# API 서버 (빠른 응답)
server:
  tomcat:
    threads:
      max: 100
      min-spare: 20
    max-connections: 200
    accept-count: 10
    connection-timeout: 5000

# 내부 관리 도구 (트래픽 적음)
server:
  tomcat:
    threads:
      max: 50
      min-spare: 10
    max-connections: 100
    accept-count: 10

// DispatcherServlet의 핵심 메서드 (단순화)
public class DispatcherServlet extends HttpServlet {

    private List<HandlerMapping> handlerMappings;
    private List<HandlerAdapter> handlerAdapters;
    private List<ViewResolver> viewResolvers;

    @Override
    protected void doDispatch(HttpServletRequest request,
                             HttpServletResponse response) {

        // 1. HandlerMapping으로 컨트롤러 찾기
        HandlerExecutionChain handler = getHandler(request);
        if (handler == null) {
            response.sendError(404);
            return;
        }

        // 2. HandlerAdapter 찾기
        HandlerAdapter adapter = getHandlerAdapter(handler.getHandler());

        // 3. Interceptor - preHandle
        if (!handler.applyPreHandle(request, response)) {
            return;
        }

        // 4. 실제 컨트롤러 실행
        ModelAndView mv = adapter.handle(request, response, handler.getHandler());

        // 5. Interceptor - postHandle
        handler.applyPostHandle(request, response, mv);

        // 6. View 렌더링 (REST API는 생략)
        if (mv != null) {
            render(mv, request, response);
        }

        // 7. Interceptor - afterCompletion
        handler.triggerAfterCompletion(request, response, null);
    }
}

// HandlerMapping의 역할
@RestController
@RequestMapping("/api/streams")
class StreamController {

    @GetMapping("/{id}")  // 이 매핑 정보를 HandlerMapping이 관리
    public StreamDto getStream(@PathVariable Long id) {
        return streamService.findById(id);
    }
}

// HandlerMapping이 관리하는 맵 (단순화)
class RequestMappingHandlerMapping {

    Map<RequestMappingInfo, HandlerMethod> mappings = new HashMap<>();

    void registerMapping() {
        // 애플리케이션 시작 시 등록
        RequestMappingInfo info = new RequestMappingInfo(
            "/api/streams/{id}",
            RequestMethod.GET
        );

        HandlerMethod method = new HandlerMethod(
            streamController,          // 빈
            "getStream",               // 메서드 이름
            Long.class                 // 파라미터 타입
        );

        mappings.put(info, method);
    }

    HandlerMethod getHandler(HttpServletRequest request) {
        String uri = request.getRequestURI();      // "/api/streams/123"
        String method = request.getMethod();        // "GET"

        // 매핑 찾기
        for (Entry<RequestMappingInfo, HandlerMethod> entry : mappings.entrySet()) {
            if (entry.getKey().matches(uri, method)) {
                return entry.getValue();  // StreamController.getStream
            }
        }

        return null;  // 404
    }
}

// Spring은 여러 HandlerMapping을 순서대로 시도
List<HandlerMapping> handlerMappings = Arrays.asList(
    new RequestMappingHandlerMapping(),  // @RequestMapping
    new BeanNameUrlHandlerMapping(),      // 빈 이름으로 매핑
    new SimpleUrlHandlerMapping()         // 직접 URL 매핑
);

HandlerExecutionChain getHandler(HttpServletRequest request) {
    for (HandlerMapping mapping : handlerMappings) {
        HandlerExecutionChain handler = mapping.getHandler(request);
        if (handler != null) {
            return handler;
        }
    }
    return null;
}

// 형태 1: @Controller 애너테이션
@RestController
class ModernController {
    @GetMapping("/api/users")
    public List<User> getUsers() {
        return userService.findAll();
    }
}

// 형태 2: Controller 인터페이스 구현 (옛날 방식)
class OldSchoolController implements Controller {
    @Override
    public ModelAndView handleRequest(HttpServletRequest req,
                                     HttpServletResponse res) {
        // ...
    }
}

// 형태 3: HttpRequestHandler
class SimpleController implements HttpRequestHandler {
    @Override
    public void handleRequest(HttpServletRequest req,
                             HttpServletResponse res) {
        // ...
    }
}

// HandlerAdapter 인터페이스
interface HandlerAdapter {
    boolean supports(Object handler);  // 이 핸들러 처리 가능?
    ModelAndView handle(HttpServletRequest req,
                       HttpServletResponse res,
                       Object handler);
}

// 예시: RequestMappingHandlerAdapter
class RequestMappingHandlerAdapter implements HandlerAdapter {

    @Override
    public boolean supports(Object handler) {
        return handler instanceof HandlerMethod;  // @RequestMapping 메서드
    }

    @Override
    public ModelAndView handle(HttpServletRequest req,
                              HttpServletResponse res,
                              Object handler) {
        HandlerMethod method = (HandlerMethod) handler;

        // 1. 파라미터 리졸빙
        Object[] args = resolveArguments(method, req);
        // @PathVariable, @RequestBody 등 처리

        // 2. 메서드 실행
        Object result = method.invoke(args);

        // 3. 반환값 처리
        if (method.isAnnotatedWith(ResponseBody.class)) {
            // MessageConverter로 JSON 변환
            writeJson(res, result);
            return null;
        }

        return new ModelAndView("viewName", result);
    }
}

@RestController
class PerformanceController {

    @GetMapping("/api/benchmark")
    public String benchmark() {
        // 각 단계별 시간 측정
        return "OK";
    }
}

// 느린 Controller
@GetMapping("/api/slow")
public List<UserDto> getUsers() {
    // 1. DB 조회: 100ms
    List<User> users = userRepository.findAll();

    // 2. N+1 문제: 500ms
    for (User user : users) {
        user.getOrders().size();  // Lazy Loading
    }

    // 3. DTO 변환: 50ms
    return users.stream()
        .map(UserDto::from)
        .collect(Collectors.toList());
}

// 총 시간: 650ms
// Spring MVC 오버헤드: 2.5ms (0.4%)
// 실제 로직: 650ms (99.6%)

// 문제가 있던 코드 (단순화)
@Configuration
class UserGradeBatchConfig {

    @Bean
    fun updateUserGradeJob(): Job {
        return jobBuilderFactory.get("updateUserGrade")
            .start(updateGradeStep())
            .build()
    }

    @Bean
    fun updateGradeStep(): Step {
        return stepBuilderFactory.get("updateGrade")
            .<User, User>chunk(1000)
            .reader(userReader())
            .processor(gradeProcessor())  // 문제!
            .writer(userWriter())
            .build()
    }
}

// Processor: 외부 API 호출
class GradeProcessor : ItemProcessor<User, User> {
    override fun process(user: User): User {
        // 외부 API 호출: 150ms
        val point = externalApi.getUserPoint(user.id)  // Blocking!
        user.grade = calculateGrade(point)
        return user
    }
}

Chunk 크기: 1,000
외부 API 응답 시간: 150ms
총 레코드: 50,000개

처리 과정:
1. 1,000개 읽기
2. 1,000개 처리 (각 150ms) = 150,000ms (2.5분)
3. 1,000개 쓰기
4. 다음 청크...

총 시간: 50 chunks × 2.5분 = 125분 (2시간)

class ParallelGradeProcessor : ItemProcessor<User, User> {

    override fun process(user: User): User {
        // RxKotlin으로 병렬 처리
        return Observable.just(user)
            .flatMap { u ->
                Observable.fromCallable {
                    externalApi.getUserPoint(u.id)
                }
                .subscribeOn(Schedulers.io())  // 병렬 실행!
            }
            .map { point ->
                user.grade = calculateGrade(point)
                user
            }
            .blockingFirst()
    }
}

// 문제: 단건 업데이트 1,000번
UPDATE users SET grade = 'GOLD' WHERE id = 1;
UPDATE users SET grade = 'GOLD' WHERE id = 2;
// ... 1,000번 반복

// 해결: 등급별로 그룹화하여 IN UPDATE
UPDATE users SET grade = 'GOLD' WHERE id IN (1, 2, 3, ..., 500);
UPDATE users SET grade = 'SILVER' WHERE id IN (501, 502, ..., 800);
UPDATE users SET grade = 'BRONZE' WHERE id IN (801, 802, ..., 1000);

// 1,000번 → 3번!

# 기존 설정
server:
  tomcat:
    threads:
      max: 200

2025-01-10 14:23:15 WARN  o.a.tomcat.util.threads.ThreadPoolExecutor
- Pool exhausted with 200 threads, queue is full

2025-01-10 14:23:16 ERROR o.s.web.servlet.DispatcherServlet
- Handler dispatch failed: java.util.concurrent.RejectedExecutionException

// 문제가 있던 API
@GetMapping("/api/streams/live")
public List<StreamDto> getLiveStreams() {
    // 1. DB 조회 (느린 쿼리): 5초
    List<Stream> streams = streamRepository.findAllLive();

    // 2. N+1 문제: 10초
    for (Stream stream : streams) {
        stream.getUser().getNickname();  // Lazy Loading
        stream.getTags().size();          // Lazy Loading
    }

    return streams.stream()
        .map(StreamDto::from)
        .collect(Collectors.toList());
}

// 총 처리 시간: 15초
// maxThreads = 200
// 초당 요청: 20개

// 15초 × 20 req/s = 300개 스레드 필요!
// 하지만 200개만 있음 → 고갈!

// Fetch Join으로 N+1 해결
@Query("""
    SELECT s FROM Stream s
    JOIN FETCH s.user
    JOIN FETCH s.tags
    WHERE s.status = 'LIVE'
""")
List<Stream> findAllLiveWithFetch();

// 처리 시간: 15초 → 0.5초
// 필요 스레드: 0.5초 × 20 req/s = 10개

@Cacheable("liveStreams")
@GetMapping("/api/streams/live")
public List<StreamDto> getLiveStreams() {
    // 캐시 히트: 10ms
    // 캐시 미스: 500ms (쿼리 최적화 후)
    return streamService.findAllLive();
}

// 필요 스레드: 거의 없음 (대부분 캐시 히트)

server:
  tomcat:
    threads:
      max: 200
    max-connections: 10000  # 너무 크다!

동시 연결: 10,000개
워커 스레드: 200개

상황:
- 10,000개 연결 모두 Poller가 관리
- 하지만 200개만 동시 처리 가능
- 9,800개는 대기만 함
- 메모리: 10,000 × 100KB = 1GB 낭비!

server:
  tomcat:
    threads:
      max: 200
    max-connections: 500   # threads.max의 2~3배
    accept-count: 20       # 빠른 실패

maxConnections = threads.max × (처리 시간 / 평균 Keep-Alive 시간)

예시:
- 평균 처리 시간: 100ms
- Keep-Alive timeout: 20초 (20,000ms)
- 비율: 100 / 20,000 = 0.005

maxConnections = 200 × (1 + 버퍼) = 400~500

버퍼를 고려해 2~3배 정도가 적절

// BIO Connector behavior (pseudocode)
class BIOConnector {
    ExecutorService threadPool;

    void acceptConnection() {
        while (true) {
            Socket socket = serverSocket.accept();  // Accept connection

            // Problem: one thread is dedicated to one connection
            threadPool.execute(() -> {
                try {
                    // 1. Wait for request (Blocking!)
                    InputStream input = socket.getInputStream();
                    byte[] data = input.read();  // Wait until data arrives

                    // 2. Process request
                    processRequest(data);

                    // 3. Send response
                    OutputStream output = socket.getOutputStream();
                    output.write(response);

                    // 4. Keep connection alive (HTTP Keep-Alive)
                    // Thread remains occupied!
                } finally {
                    socket.close();
                }
            });
        }
    }
}

// Worst-case scenario
class BIOProblem {
    public static void main(String[] args) {
        // Thread pool: 200 threads
        // Concurrent connections: 1000
        // Keep-Alive Timeout: 20 seconds

        // Scenario:
        // 1000 users connected
        // Each sends just 1 request, then waits on Keep-Alive for 20 seconds

        // Result:
        // - All 200 threads occupied
        // - Remaining 800 connections wait
        // - CPU is barely doing anything!
    }
}

// NIO Connector behavior (simplified)
class NIOConnector {
    Selector selector;  // The key!

    void run() {
        while (true) {
            // 1. Selector monitors multiple connections simultaneously
            int readyCount = selector.select();  // Blocking, but monitors multiple channels

            // 2. Process only the ready channels
            Set<SelectionKey> keys = selector.selectedKeys();
            for (SelectionKey key : keys) {
                if (key.isAcceptable()) {
                    // Accept new connection
                    acceptConnection(key);
                } else if (key.isReadable()) {
                    // Data ready to read → assign worker thread only now!
                    handleRead(key);
                } else if (key.isWritable()) {
                    // Data ready to write
                    handleWrite(key);
                }
            }
        }
    }
}

# Test environment
spring:
  application:
    name: benchmark-test
server:
  tomcat:
    threads:
      max: 200

// Slow API (intentionally waits 3 seconds)
@RestController
class SlowController {

    @GetMapping("/slow")
    public String slowApi() throws InterruptedException {
        Thread.sleep(3000);  // Simulates DB query or external API call
        return "Done";
    }
}

Concurrent users: 1000
Request: GET /slow

Result:
- First 200: respond after 3 seconds
- 201~400: respond after 6 seconds
- 401~600: respond after 9 seconds
- 801~1000: respond after 15 seconds

Average response time: 9 seconds

Concurrent users: 1000
Request: GET /slow

Result:
- All 1000 respond after about 3~4 seconds
- Poller manages all 1000 connections
- Worker threads are assigned only during actual processing

Average response time: 3.2 seconds

BIO:
connections > threads → queued → processed sequentially

NIO:
independent of connection count → Poller monitors all → worker threads assigned only to ready ones

// Acceptor's role (pseudocode)
class Acceptor implements Runnable {
    ServerSocketChannel serverSocket;

    @Override
    public void run() {
        while (running) {
            // 1. Accept connections that completed the 3-way handshake
            SocketChannel socket = serverSocket.accept();  // Blocking

            // 2. Set to non-blocking mode
            socket.configureBlocking(false);

            // 3. Hand off to Poller
            PollerEvent event = new PollerEvent(socket, OP_READ);
            poller.register(event);
        }
    }
}

// accept() is fast
class AcceptorPerformance {
    void benchmark() {
        long start = System.nanoTime();
        SocketChannel socket = serverSocket.accept();
        long end = System.nanoTime();

        System.out.println("Accept time: " + (end - start) / 1000 + "μs");
        // Output: Accept time: 50μs (0.05ms)

        // Throughput: 1,000,000 / 50 = 20,000 connections/sec
        // It's just pulling from the TCP backlog queue, so it's very fast
    }
}

// Poller's role (pseudocode)
class Poller implements Runnable {
    Selector selector;
    Queue<PollerEvent> events;

    @Override
    public void run() {
        while (running) {
            // 1. Register newly added sockets with the Selector
            processEvents();

            // 2. Detect ready channels with the Selector
            int count = selector.select(1000);  // Wait up to 1 second

            if (count > 0) {
                // 3. Process ready channels
                Iterator<SelectionKey> iterator = selector.selectedKeys().iterator();
                while (iterator.hasNext()) {
                    SelectionKey key = iterator.next();
                    iterator.remove();

                    if (key.isReadable()) {
                        // Data ready to read!
                        // Hand off to Executor
                        executor.execute(new SocketProcessor(key));
                    }
                }
            }
        }
    }

    void processEvents() {
        PollerEvent event;
        while ((event = events.poll()) != null) {
            // Register sockets from Acceptor with the Selector
            event.socket.register(selector, SelectionKey.OP_READ);
        }
    }
}

// Before (BIO): 1000 connections = 1000 threads needed
// Memory: 1000 × 1MB = 1GB

// After (NIO): 1000 connections = 1~2 Pollers + worker threads only when needed
// Memory: 2MB (Poller) + dynamically allocated

// Executor's role
class SocketProcessor implements Runnable {
    SelectionKey key;

    @Override
    public void run() {
        try {
            // 1. Read data from socket
            SocketChannel channel = (SocketChannel) key.channel();
            ByteBuffer buffer = ByteBuffer.allocate(8192);
            int read = channel.read(buffer);

            // 2. Parse HTTP request
            HttpRequest request = parseHttpRequest(buffer);

            // 3. Pass to servlet container
            servlet.service(request, response);

            // 4. Send response
            channel.write(responseBuffer);

        } finally {
            // 5. Return worker thread immediately!
            // Keep-Alive connections go back to Poller
            key.interestOps(SelectionKey.OP_READ);
        }
    }
}

BIO:
Thread assigned → wait for data (2s) → process (0.1s) → wait (Keep-Alive 20s)
Thread occupied: 22.1 seconds

NIO:
Poller monitors (2s) → thread assigned → process (0.1s) → thread returned → Poller monitors (20s)
Thread occupied: 0.1 seconds

// Java Selector internals (Linux)
class EPollSelectorImpl extends SelectorImpl {

    int poll(long timeout) {
        // Calls the Linux epoll_wait system call via JNI
        return EPoll.wait(pollArrayAddress, NUM_EPOLLEVENTS, timeout, epfd);
    }
}

// Linux kernel level
// 1. Create epoll instance
int epfd = epoll_create1(0);

// 2. Register sockets to monitor
struct epoll_event ev;
ev.events = EPOLLIN;  // Read events
ev.data.fd = socket_fd;
epoll_ctl(epfd, EPOLL_CTL_ADD, socket_fd, &ev);

// 3. Wait for events (blocking, but monitors multiple sockets!)
struct epoll_event events[1000];
int nfds = epoll_wait(epfd, events, 1000, timeout);

// 4. Iterate only over ready sockets
for (int i = 0; i < nfds; i++) {
    if (events[i].events & EPOLLIN) {
        // This socket has data ready to read!
        handle_read(events[i].data.fd);
    }
}

// select (old approach)
fd_set readfds;
FD_ZERO(&readfds);
FD_SET(socket1, &readfds);
FD_SET(socket2, &readfds);
// ... register 1000 ...

select(max_fd, &readfds, NULL, NULL, &timeout);

// Problem: iterates through all 1000 every time
for (int i = 0; i < 1000; i++) {
    if (FD_ISSET(sockets[i], &readfds)) {
        // ready
    }
}
// Time complexity: O(N)

// epoll (new approach)
int nfds = epoll_wait(epfd, events, 1000, timeout);
// The kernel fills the events array with only the ready ones!

for (int i = 0; i < nfds; i++) {
    // Iterate only over the ready ones
}
// Time complexity: O(number of ready)

With 1000 connections and only 10 ready:

select: checks 1000 times → 10ms
epoll:  checks only 10 times → 0.1ms

100x difference!

server:
  tomcat:
    threads:
      max: 200              # maxThreads
    max-connections: 8192   # maxConnections
    accept-count: 100       # acceptCount

// If maxThreads = 200?
class WorkerThreadPool {
    ExecutorService executor = Executors.newFixedThreadPool(200);

    void handleRequest(HttpRequest request) {
        if (executor.getActiveCount() < 200) {
            // Can process
            executor.submit(() -> processRequest(request));
        } else {
            // Wait (connection is maintained!)
            // Poller continues monitoring
        }
    }
}

# Scenario 1: CPU-bound work (computation-heavy)
# Average processing time: 100ms
# CPU cores: 8
# Recommended: threads.max = 8~16

# Scenario 2: I/O-bound work (DB, external API calls)
# Average processing time: 500ms (450ms of which is I/O wait)
# CPU cores: 8
# Recommended: threads.max = 100~200

# Scenario 3: Mixed
# Average processing time: 200ms (150ms of which is I/O wait)
# CPU cores: 8
# Recommended: threads.max = 50~100

// Meaning of maxConnections in NIO
class NIOEndpoint {
    Semaphore connectionLimitLatch;  // Connection count limiter

    void setMaxConnections(int max) {
        this.connectionLimitLatch = new Semaphore(max);
    }

    void acceptConnection(SocketChannel socket) {
        if (connectionLimitLatch.tryAcquire()) {
            // Accept connection
            poller.register(socket);
        } else {
            // Cannot accept more connections
            // Moves to OS accept queue (acceptCount)
        }
    }

    void closeConnection(SocketChannel socket) {
        socket.close();
        connectionLimitLatch.release();  // Release slot
    }
}

Memory calculation:
- Memory per connection: ~50~100KB (TCP buffers, socket metadata)
- 8192 connections: 400MB~800MB

CPU calculation:
- Poller's epoll_wait: O(number of ready)
- 100 ready out of 8192: less than 1ms

Sufficient for most cases!

# Bad configuration
server:
  tomcat:
    max-connections: 10000
    threads:
      max: 200

# Problem: what if 10,000 connections come in?
# - Only 200 are being processed
# - 9,800 are just waiting
# - Memory wasted!

# Correct configuration
server:
  tomcat:
    max-connections: 500   # About 2~3x threads.max
    threads:
      max: 200

// When creating ServerSocket
ServerSocket serverSocket = new ServerSocket(port, acceptCount);

// Actual behavior on Linux
// listen(sockfd, backlog)
listen(server_fd, 100);  // acceptCount = 100

Scenario:
maxConnections = 10
acceptCount = 5
Current connections: 10 (full)

New connection request:
1. Tomcat: "maxConnections is full, not accepting"
2. OS: "Then I'll accept it and put it in my queue" (max 5)
3. Client: "Connection successful!" (actually waiting)

If acceptCount is also full:
4. OS: "Can't accept any more"
5. Client: "Connection refused" error

# Netflix's configuration (estimated)
server:
  tomcat:
    threads:
      max: 300
    max-connections: 400
    accept-count: 10    # Very small!

Large acceptCount (e.g., 1000):
- Connection succeeds but waits 30 seconds
- User: "Why is it so slow?" (bad UX)

Small acceptCount (e.g., 10):
- Quickly returns "Connection refused"
- Client: retries or routes to another server (fast failure)