Java NIO 의 Selector

이전 포스팅에서 Java NIO 를 사용할 때

Java NIO 가 동기 non-blocking 방식이라

busy-wait 이 발생하였다.

 

busy-wait 에 대해 잠시 복습하고 진행하겠다.

busy-wait 은 동기 non-blocking 구조에서 자주 보이는 현상으로..

non-blocking 이라 caller 는 callee 작업으로 부터 자유로운데

동기 방식이라 callee 의 작업이 끝났는지(결과를 받을 수 있는지)

주기적 확인이 필요한 상황이다.

 

그래서..

주기를 늘리면 실시간성이 떨어지게 되고..

주기를 좁히면 그만큼 blocking 과 다를 바가 없고 CPU 자원이 낭비 되는 것이다.

 

문제는 서버에서는 여러 이벤트를 동시에 다루고 여러 요청을 다룰 수 있어야한다.

위와 같은 방식에서는 accept, read 등의 이벤트를 여러개의 스레드가 확인 해야한다면

그만큼 스레드 낭비가 발생한다. 어느 하나의 스레드가 모든 이벤트를 추적(준비 완료 확인)할 수 있으면

효율적으로 될 수 있을 것 같다.

 

이를 해결하는 것이 바로 Java NIO 의 Selector 이다.

 

Selector 의 IO Multiplexing

Java NIO 를 사용하면서, Selector 를 사용하지 않을 때...

busy-wait 이 발생하는 메서드는 accept, read 가 있었다.

이러한 메서드들을 호출 해놓고 Selector 가 주기적으로 확인하면서

accept, read 등 이 준비 완료(각 connection 완료, read 준비 완료) 되면

해당 준비 완료 이벤트를 처리하는 EventHandler 를 호출할 수 있다.

한마디로, 여러 채널으로 전달되는 이벤트를 Selector 가 모아서 처리할 수 있다.

머리를 좀 굴려보면 EventHandler 의 역할은 Selector 가 없는 상황(busy-wait)에서 사용하지 못한.. callback 동작이다.

 

참고,

동기 코드라는 것은 결국 callback 을 사용할 수 없는 상황이라는 뜻

busy-wait 은 callback 을 사용하지 못해서 생기는 현상인 것..

 

참고,

코드는..

어떤 채널(ServerSocketChannel, SocketChannel) 에

특정 작업(accept, read) 과 해당 작업이 완료되면 발생되는 이벤트를 받을 selector 를 등록할 수 있도록 작성이 된다.

-> 채널.register(selector, 작업)

 

참고,

이쯤에서 알 수 있는 것이..

Selector 때문에, Java NIO 는 Java IO 와 다르게

소켓에 Channel 이라는 이름이 추가되었다고 생각해 볼 수 있다.