병렬성(parallelism)의 문제  1) CPU마다 갖는 캐시를 서로 다르기 때문에 동기화가 어렵다는 문제가 있음(서로 로컬 캐시 이기 때문)2) L3 캐시를 사용하더라도 사로 다른 코어가 동시에 접근할 수 없음(lock)    - 보통의 경우 먼저 선점한 코어가 빠져나오기까지 block 됨.    - 이럴 거면 멀티 코어를 쓰는 의미가 없어짐 위와 같이 비동기(순서가 서로 다른), 병렬성에 따른 문제가 있었고 이를 해결하기 위해 프로그래밍 언어 레벨에서 해결하려는 노력들(RxJava, 콜백)이 있었다. 이러한 노력에도 단점들이 있는데, 콜백을 사용할 경우 콜백 정의부가 메소드 내부 인자로 들어감에 따라 코드 depth가 커지고 가독성이 나빠질 수 있으며 RxJava를 사용할 때엔 항상 스트림을 사용..

컨셉  - JetBrains 사에서 만든 언어- JVM 기반 언어    - .java에서 컴파일된 .class 파일을 동일하게 코틀린에서도 사용    - 자바에서 소스파일을 .java로 사용하듯 코틀린에서 같은 레벨에 .kt 파일로 정의됨- 코틀린이 자바와 100% 호환될 수 있는 이유: 코틀린도 .class 파일로 컴파일되기 때문. 따라서 import를 통해 코틀린 소스코드 내에서 자바 라이브러리, 스프링 등을 참조할 수 있음(import 시 이미 컴파일된 class를 참조하기 때문)- 2016년 코틀린 1.0 릴리즈, 스프링 프레임워크 5.0부터 코틀린 공식 지원, gradle의 경우 Groovy에 더해 Kotlin DSL 지원- JetBrains 사에서 코틀린 기반의 백엔드 애플리케이션 프레임워크 ..

이번 포스팅에서는 반응형(Reactive) 모델이 최근 떠오르고 있는 이유와 이에 대한 장단점, 반응형 프로그래밍을 표준화하기 위한 과정들, Spring에서 기존 서블릿을 대체하는 반응형 네트워크 엔진 등에 대해 알아본다. Blocking I/O와 Non-Blocking I/O의 동작 원리 반응형(Reactive) 프로그래밍을 이해하기 위해선 Non-Blocking I/O의 동작 원리와 Blocking I/O와 비교했을 때 어떤 장단점이 있는지를 명확하게 이해해야 한다. 위 그림과 같이 Non-Blokcing I/O 모델은 I/O가 발생하더라도 block되지 않기 때문에 다른 요청을 처리할 수 있게 된다. 따라서 더 적은 양의 쓰레드와 CPU로 다수의 요청을 동시에(Parallel의 의미가 아니라 Con..

Netty에서 제공되는 I/O는 모두 Non-Blocking 기반이다. 예를 들어, Bootstrap에 대한 connect, bind 또는 writeAndFlush 등의 I/O 메소드는 모두 Non-blocking I/O 기반으로 동작한다. Non-Blocking I/O Non-Blocking I/O는 쓰레드가 실행 중에 I/O 연산을 마주했을 때 system call을 하고 바로 빠져나와(Non-Blocking I/O) 다음 작업을 처리하는 방식이다. 따라서 Non-blocking I/O기반의 작업은 I/O가 완료되기 전까지 다른 작업을 수행할 수 있다는 게 핵심이다. 이러한 개념에 비추어 봤을 때, I/O 시간이 오래걸리는 것에 대해서 Non-blocking을 기반으로 하는 것이 좋다. I/O 시간이..

최종 연산과 중간 연산 스트림이란 일련의 데이터의 흐름이다. 실질적으로는 스트림은 인스턴스로 존재하고 여러 개의 파이프를 통과함으로써 알련의 작업이 처리된다. 여기서 파이프는 메소드 호출을 통해 이루어진다. 최종 연산을 담당하는 파이프는 가장 마지막에 위치해야 한다. 최종 연산이 아닌 그 외 연산은 모두 중간 연산이라고 부른다. - 최종 연산(Terminal Operation) : 스트림을 연산하기 위한 파이프 중 가장 마지막의 연산을 담당하는 파이프 - 중간 연산(Intermediate Operation) : 최종 연산이 아닌 파이프에서 처리되는 연산들 예를 들어 홀수만 찾아내고 이들의 합을 구하는 연산이 있다고 가정하면 총 2가지 연산(홀수 찾기, 더하기)이 존재하고 이들 간의 순서는 홀수를 찾는 것..

이 글에서 말하는 Stream I/O는 일반적으로 자바에서 말하는, 필더링, 리덕션 등의 고차 함수를 이용하는 Stream과 다르다. I/O라는 용어가 붙었기 때문에 file, device, socket I/O 등 운영체제의 도움을 받아 처리되는 데이터의 입출력을 말하는 것이다. Stream I/O 추상적으로 Stream은 '데이터의 흐름'이다. 좀 더 이해를 쉽게 하자면 '데이터가 이동하는 통로'라고 생각해도 좋다. 자바에서 Stream(java.io)은 단방향 통신만을 지원하기 때문에 InputStream과 OutputStream을 따로 둘 수밖에 없었다. 또한 Stream은 Blocking I/O 만을 지원하기 때문에 모든 I/O 작업이 완료되기 전까지 자바 프로세스가 다른 작업을 수행할 수 없다...

스프링 프레임워크와 스프링 부트의 차이점 중 하나는 AutoConfiguration의 기능으로 알고 있었지만, 이 기능이 어떤 방식으로 동작하는지 궁금했고 이번 기회에 스프링 부트의 AutoConfiguration의 동작 과정에 대해 포스팅해보았다. 본론으로 들어가기 앞서 Spring과 Spring Boot의 차이점에 대해 알아보자. Spring과 Spring Boot의 가장 큰 차이점은 '의존성의 버전 관리'와 '간편한 자동 설정'이다. Spring - 필요한 dependency를 모두 직접 빌드 툴에 등록해줘야 한다. - Dependency의 버전을 직접 명시해줘야 한다. - 필요한 설정 파일을 작성하고 빈으로 등록해야 한다. Spring Boot - 필요한 dependency의 묶음을 제공하고 추가..

기본적으로 톰캣은 쓰레드 풀에 200개의 쓰레드를 두고 요청 당 할당한다고 알고 있었지만 여기서 의문점이 생겼다. 그렇다면 동시에 최대 200개의 요청만 처리할 수 있는 것일까? 이번을 기회로 지금까지 스프링 부트 개발을 하면서 사용해왔던 톰캣의 기능과 톰캣이 요청을 받아 서블릿 컨테이너로 위임하는 과정 / 톰캣의 I/O 방식을 주제로 작성했다. Tomcat이란? 톰캣은 아파치 재단에서 관리되며 Java 표준 인터페이스인 서블릿을 지원하기 위한 미들웨어이다. 톰캣은 OS로부터 네트워크 요청 정보를 받아와 자바 객체로 만들고 이를 서블릿 컨테이너로 위임한다. 톰캣은 웹 애플리케이션의 다양한 스펙 사항(서블릿 스펙, JSP스펙, '웹소켓' 스펙 등)을 준수하며 개발되었다. 링크(https://tomcat.a..

아파치 Tomcat의 BIO Connector / NIO Connector 개념 1) BIO Connector - Response를 보내고 끝내는 것이 아니라 TCP Connection이 만료될 때까지 Thread가 활성 상태로 남아있으며 소켓이 닫히면 Pool로 반환되는 구조 - Connection이 만료되기 전까지 Thread가 활성상태로 남아 있기 때문에 Idle Thread 발생 - '최대 동시접속 클라이언트 수'와 '쓰레드 풀의 쓰레드 수'가 같음 2) NIO Connector - Java의 I/O 라이브러리인 NIO를 활용하여 Tomcat에서 만들어진 Connector - Poller라는 단일 쓰레드가 Selector를 이용하여 처리가 가능한 순간에만 Thread를 활성화시킴으로써 Idle T..

최근 MockMvc 기반으로 컨트롤러 단의 테스트 코드를 작성하다가 핸들러가 호출되지 않는 문제를 마주했고 이를 해결하기 위해 컨트롤러까지 요청이 들어오기까지 어떤 과정을 거치는지 알아야 할 필요성을 느껴 포스팅을 준비했다. 서블릿이란 과거에는 거의 동적인 컨텐츠만 다루는 웹 시스템이었으나 동적인 컨텐츠를 다루면서 웹 서버에 프로그램을 붙여 동적인 페이지를 제공하도록 변화했다. 그래서 등장한 것이 서블릿과 WAS이고 서블릿은 자바 Interface로 정의된 명세사항(specification)이다. (servlet은 javax 패키지에 정의된, 자바에서 정의한 스펙 사항이며 다른 플랫폼에서는 사용되지 않는다) 서블릿의 스펙사항을 기반으로 만들어진, 서블릿을 관리하는 서블릿 컨테이너가 WAS에서 구동된다. ..