e-una

WebFlux 적용하기 (1) Java I/O 와 NIO(New I/O, Non-Blocking I/O)

e-una — Tue, 14 Feb 2023 19:10:40 +0900

내 프로젝트를 WebFlux 로 Async-Non Blocking 하게 만들어보자!

WebFlux 는 Reactive Programming 을 지원하는 프레임워크로, 디폴트로 Netty 라는 NIO 클라이언트 서버 프레임워크를 사용합니다.

Webflux 적용하기 첫 번째 포스팅으로 Java I/O 와 NIO 를 알아보도록 하겠습니다.

느린 Java 의 I/O

자바에 New I/O 가 추가 된 이유는 무엇일까요? 그 이유는 기존 I/O 의 속도가 느리기 때문입니다.

Java 의 I/O 가 어떤 이유로 느린지, 그리고 NIO 는 어떤 점을 개선했는지 알아봅시다.

Java I/O 의 동작 원리(파일 읽기)

[하드디스크 -> 프로세스 내부의 메모리 영역] 논리적 다이어그램

프로세스는 커널에 read() 시스템 콜을 통해 버퍼를 채우도록 요청합니다.
read() 가 호출되면 커널은 디스크에서 데이터를 가져오도록 디스크 컨트롤러에 명령을 내립니다.
디스크 컨트롤러는 메인 CPU 의 지원 없이 DMA(Direct Memory Access) 를 통해 커널의 버퍼에 직접 데이터를 기록합니다.
디스크 컨트롤러가 버퍼를 채우면 커널은 커널의 임시 버퍼에서 프로세스가 지정한 버퍼로 데이터를 복사합니다.

⤹ 간략한 OS 개념 정리

OS 는 크게 User mode, Kernel mode 두 가지로 구분해서 프로세스를 동작시킵니다.

간략하게 설명하면 Kernel 은 OS 의 핵심적인 역할을 하기 때문에 User 레벨에서 직접 접근할 수 없습니다.

그렇다면 애플리케이션(프로세스)에서 하드웨어에 접근해서 데이터를 읽고 싶을 때는 어떻게 해야할까요?

이 때 System call 이 사용됩니다. 시스템 콜은 사용자 레벨 프로세스가 OS와 상호작용하는 방법으로, 인터페이스를 통해 애플리케이션에게 OS 의 서비스를 요청할 수 있도록 합니다.

read() 시스템 콜을 통해 커널에게 I/O 수행을 요청하면 User mode 에서 Kernal mode 로 스위칭이 발생합니다.

JVM 버퍼 복사로 인한 CPU 오버헤드

C언어에서는 포인터를 통해 메모리에 직접 접근할 수 있기 때문에 시스템 콜을 직접 사용할 수 있습니다.

C 프로세스 ⇨ 시스템 콜 ⇨ 커널 ⇨ 디스크 컨트롤러 ⇨ 데이터 복사

하지만 Java 는 메모리에 직접 접근할 수 없기 때문에 커널 버퍼에서 JVM 버퍼로 데이터를 복사하는 추가적인 과정이 발생합니다.

JVM ⇨ 시스템 콜 ⇨ 커널 ⇨ 디스크 컨트롤러 ⇨ 커널 버퍼 복사 ⇨ JVM 버퍼 복사

디스크 컨트롤러는 DMA 를 통해 CPU 연산 없이 데이터를 복사합니다.

그러나 JVM 내부의 버퍼로 복사할 때는 CPU 연산이 필요하기 때문에 속도가 느려지는 원인이 됩니다.

Blocking 방식의 I/O

read() 시스템 콜을 통해 커널에게 I/O 수행을 요청하면 User mode 에서 Kernel mode 로 스위칭이 발생합니다.

디스크에서부터 JVM 내 메모리 영역에 복사하는 과정을 거친 후에 User mode 로 제어권을 넘기기 때문에, 데이터를 읽는 동안에 Blocking 이 발생하여 속도가 느려지는 원인이 됩니다.

이렇게 하나의 스레드에 하나의 클라이언트가 붙는 Blocking 방식은 다음과 같은 단점이 있습니다.

여러 스레드가 입력이나 출력 데이터가 들어오기를 기다리며 무한정 대기 상태로 유지 될 수 있습니다.
각 스레드가 스택 메모리를 할당해야하기 때문에 많은 메모리를 차지합니다.
JVM 은 동시 접속이 한계에 이르기 훨씬 전부터(약 1만개만 되어도) 컨텍스트 스위칭에 따른 오버헤드가 문제가 될 수 있습니다.

Java NIO

Java NIO 는 표준 Java I/O 및 Java Networking API 의 대안이 될 수 있는 API 입니다.

기존 I/O 와 다른 방식의 프로그래밍 모델을 제공하고, Blocking 또는 Non-Blocking 방식 모두 사용할 수 있습니다.

NIO 는 내용이 매우 매우 많기 때문에, 중요한 내용을 위주로 기재하도록 하겠습니다.

NIO Components

Java NIO 의 주요한 컴포넌트에는 채널, 버퍼, 셀렉터가 있습니다.

주요 컴포넌트에 대해서 먼저 간략하게 알아보고, 동작 방식을 통해 각 컴포넌트들이 어떻게 쓰이는지 이해해보도록 하겠습니다.

NIO Channels

단방향 데이터 전송 방식인 스트림과 다르게 채널은 양방향 데이터 전송 기능을 제공합니다.

채널은 데이터를 버퍼에서 읽고, 버퍼는 데이터를 채널에 씁니다.

채널의 타입은 다음과 같습니다.

FileChannel - 파일에서 데이터 읽기
DatagramChannel - UDP 를 통해 네트워크에서 데이터 읽고 쓰기
SocketChannel - TCP 를 통해 네트워크에서 데이터 읽고 쓰기
ServerSocketChannel - 웹 서버와 같이 들어오는 TCP 연결을 수신, 들어오는 각 연결에 대해 SocketChannel 생성

채널은 네이티브 코드를 사용해서 작업을 수행하기 때문에 I/O 서비스에 직접 액세스할 수 있습니다.

I/O 매커니즘에 액세스하기 위해 Java NIO 에서 제공하는 게이트웨이 역할을 합니다.

채널은 데이터를 읽고 쓰는데 Scatter/gather (분산/수집) 방식을 사용합니다.

Scattering 이란, 둘 이상의 버퍼에서 단일 채널로 데이터를 쓰는 쓰기 작업을 의미합니다. 여러 버퍼를 하나의 채널로 수집하려고 할 때, 매버퍼마다 비용이 비싼 시스템 콜을 호출하지 않고 프로세스에서 사용하는 버퍼의 목록을 한 번에 넘겨주는 방식입니다.

NIO Buffers

NIO 버퍼는 NIO 채널과 상호 작용할 때 사용됩니다. 앞서 말한 것처럼 데이터는 채널에서 버퍼로 읽혀지고, 버퍼에서 채널로 쓰여집니다.

버퍼는 다음과 같은 유형을 제공합니다.

버퍼는 사용하는 메모리의 위치에 따라서 Non Direct Buffer 와 Direct Buffer 로 나뉩니다.

채널을 통해 다이렉트 버퍼(e.g. ByteBuffer)를 사용하면 OS 의 메모리에 직접 접근(하는 듯)하여 다음과 같이 파일을 읽을 수 있게 됩니다.

JVM ⇨ 시스템 콜 ⇨ 커널 ⇨ 디스크 컨트롤러 ⇨ DMA 복사

디스크 컨트롤러가 DMA 를 통해 직접 운영체제 메모리에 접근하고, 응용 프로그램은 다이렉트 버퍼를 사용해서 운영체제 메모리에 직접 접근합니다. 이 때 논 다이렉트 버퍼를 사용하게 되면 채널의 대상이 되지 않아 기존 I/O 와 같이 데이터 복사의 단계를 한 번 더 거치게 됩니다.

버퍼를 사용하는 간단한 예제는 다음과 같습니다.

RandomAccessFile aFile = new RandomAccessFile("data/nio-data.txt", "rw");
FileChannel inChannel = aFile.getChannel();

//create buffer with capacity of 48 bytes
ByteBuffer buf = ByteBuffer.allocate(48);

int bytesRead = inChannel.read(buf); //read into buffer.
while (bytesRead != -1) {

  buf.flip();  //make buffer ready for read

  while(buf.hasRemaining()){
      System.out.print((char) buf.get()); // read 1 byte at a time
  }

  buf.clear(); //make buffer ready for writing
  bytesRead = inChannel.read(buf);
}
aFile.close();

NIO Selector

셀렉터는 단일 스레드를 사용해서 여러 채널을 처리하는 데 사용됩니다.

하나의 스레드로 여러 I/O 를 처리할 수 있기 때문에, 이전에 설명한 블로킹 방식의 단점들이 해결됩니다.

Non Blocking 구현의 핵심으로, 등록 된 채널들이 발생시킨 이벤트에 대해서 요청을 매핑하는 컨트롤러 역할을 합니다.

Selector 생성 및 채널 등록

채널을 셀렉터와 사용하기 위해서는 채널을 셀렉터에 등록해야합니다. 소스코드로 보면 다음과 같습니다.

// Creating a Selector
Selector selector = Selector.open();

// Registering Channels with the Selector
channel.configureBlocking(false);

SelectionKey key = channel.register(selector, SelectionKey.OP_READ);

SelectionKey

셀렉터에 채널을 등록할 때마다 셀렉션 키가 생성됩니다. 셀렉션 키는 셀렉터를 통해 모니터링되는 채널에서 수신하려는 이벤트를 의미하는 키입니다. 셀렉션 키를 기준으로 채널들이 발생시킨 이벤트에 대해 적절한 핸들러로 요청을 분기시킬 수 있습니다.

수신할 수 있는 이벤트는 4가지가 있으며, 각각은 SelectionKey 클래스의 상수로 표시됩니다.

이벤트를 발생시키는 채널은 해당 이벤트에 대해 ready 되었다고 표현합니다.

SelectionKey.OP_CONNECT: 클라이언트가 서버에 연결을 시도할 때
SelectionKey.OP_ACCEPT: 서버가 클라이언트의 연결을 수락할 때
SelectionKey.OP_READ: 데이터를 read 할 ready 된 채널
SelectionKey.OP_WRITE: 데이터를 write 할 ready 된 채널

ready 된 채널에 다음과 같이 액세스 할 수 있습니다. 전체 코드는 여기를 참고 해주세요.

// Server 에서 사용 예시
while (true) {
    selector.select();
    Set<SelectionKey> selectedKeys = selector.selectedKeys();
    Iterator<SelectionKey> iter = selectedKeys.iterator();
    while (iter.hasNext()) {

        SelectionKey key = iter.next();

        if (key.isAcceptable()) {
            register(selector, serverSocket);
        }

        if (key.isReadable()) {
            answerWithEcho(buffer, key);
        }
        iter.remove();
    }
}

NIO Server Architecture

NIO 서버가 어떻게 데이터를 주고받는지 동작 순서를 알아보겠습니다.

ready 된 채널들이 셀렉터에 등록됩니다.
셀렉터는 단일 스레드지만 동시에 여러 이벤트를 처리할 수 있는 멀티 스레드처럼 동작합니다.
클라이언트에게 요청이 오면 셀렉터는 셀렉션 키를 보고 적절한 채널을 찾아 매핑합니다.
채널은 버퍼를 통해 클라이언트가 요청한 이벤트를 수행합니다.
새로운 커넥션이 생성되면 셀렉터에 등록하고, 동일한 처리를 반복합니다.

NIO Virtual Memory

Java I/O 가 느린 이유 중 하나는 메모리에 직접 접근할 수 없어서 JVM 내부에 데이터를 한번 더 복사해야한다는 것입니다.

그 점을 NIO 에서는 가상 메모리를 통해 개선했습니다. 가상 메모리를 사용해서 커널 버퍼와 프로세스의 버퍼가 같은 물리적 메모리 공간을 바라보게하면, 마치 프로세스 내의 버퍼가 커널 버퍼에 직접 접근하는 것처럼 동작이 가능합니다.

마치며

Netty 에 대해 알아보기 전에 기존 I/O 의 문제점과 NIO 를 알아보았습니다.

NIO 는 다소 복잡하지만 가상 메모리를 사용함으로써 컨텍스트 스위칭 비용이 적고 Non Blocking 방식이 가능하다는 장점이 있습니다.

하지만, 커넥션되는 클라이언트 수가 적고 대용량의 데이터를 전송하는 경우에는 기존 I/O 방식이 더 유리할 수 있기 때문에 용도에 맞게 선택해야합니다.

다음 포스팅은 Netty 에 대해서 알아보도록 하겠습니다.

Reference

[Spring Boot] Tomcat 알아보기 (3) Tomcat Thread Pool

e-una — Mon, 30 Jan 2023 16:09:48 +0900

스프링은 어떻게 동시에 수많은 요청을 처리할까요?

지난 포스팅에서는 Servlet Container 와 Java Thread Pool 에 대해 알아보았습니다.

[Spring Boot] Tomcat 알아보기 (2) Java Thread Pool

이번 포스팅에서는 동시 요청을 처리하는 Tomcat 의 Thread Pool 에 대해 알아보겠습니다.

Tomcat 의 Thread Pool

지난 포스팅에서 알아본 것처럼, Spring 에서 클라이언트의 요청은 Tomcat 과 같은 Servlet Container 가 처리합니다.

Tomcat 의 Thread Pool 의 구조는 Java Thread Pool 과 유사하기 때문에 설정 방법과 효율적인 사용법에 대해 알아보도록 하겠습니다.

톰캣은 Spring Boot 의 내장 Servlet Container 중 하나로, application.yml 또는 application.properties 와 같은 애플리케이션 속성 파일로 Tomcat 의 Thread Pool 을 설정할 수 있습니다.

Properties

server:
  tomcat:
    threads:
      max: 200
      min-spare: 10
    max-connections: 8192
    accept-count: 100 # Task queue size
    connection-timeout: 20000

- server.tomcat.threads.max

Thread Pool 에서 사용할 최대 스레드 개수

Request 에 비해 스레드 개수를 너무 많게 설정하면, idle 스레드가 많아져 비효율이 발생하고

또 너무 적게 설정하면 동시에 처리할 수 있는 요청 수가 줄어들어 평균 응답 시간이 늘어나기 때문에 적절한 설정이 필요합니다.

- server.tomcat.threads.min-spare

Thread Pool 에서 최소한으로 유지할 Thread 개수

이 값을 많이 설정하게 된다면 Thread Pool 이 항상 유지해야 할 Thread 수가 많아지기 때문에 메모리를 많이 차지하게 됩니다.

- server.tomcat.accept-count

모든 요청 처리 스레드가 사용 중일 때 들어오는 커넥션 request 에 대한 최대 대기열 길이

즉, 작업 큐 사이즈를 의미합니다.

너무 크게 설정하면 대기열이 커지면서 메모리 문제를 유발할 수 있고, 너무 작게 설정하면 요청이 몰렸을 때 장애를 발생시킬 수 있습니다.

이 설정을 통해 부적절하거나 잘못된 요청이 한 번에 너무 많이 들어와서 서버에 장애를 발생시키는 것을 방지할 수 있습니다.

- server.tomcat.threads.max-connections

톰캣이 동시에 처리할 수 있는 최대 Connection 의 개수

톰캣은 accept-count 속성을 기반으로 연결을 수락할 수 있습니다.

예를 들어, max-connections(최대 연결 수) 가 3, max(최대 스레드 개수) 가 2, accept-count(대기열) 가 1 이라고 가정해보겠습니다. 이런 경우 최대 스레드 개수가 2개지만 작업 큐에 커넥션(Task)을 1개 넣을 수 있으므로, 연결을 수락할 수 있습니다.

Tomcat5 이후 지원하는 NIO 커넥터는 BIO 커넥터에 비해 스레드를 효율적으로 사용하지만, 두 방식 모두 대기열 큐가 가득차게 되면 연결 거절 오류를 리턴할 수 있습니다.

Thread Pool 을 설정하는 이유와 한계

앞에서 알아본 것과 같이 Thread Pool 의 세부 사항을 설정하는 이유는 무엇일까요?

이유는 여러가지가 있겠지만, 그 중 하나는 한정 된 서버 자원 내에서 클라이언트의 요청을 효율적으로 처리해주기 위해서입니다.

서버실이나 IDC 에 비싼 장비를 사두고 그 자원 내에서 최대한 많은 클라이언트의 요청을 받아야했을 때는 세부 설정이 중요했지만 현재 많은 기업은 AWS 를 통해 서비스하고 있습니다. 그렇기 때문에 서버의 리소스가 부족하다면 스레드를 줄이고 늘리며 요청을 처리하는 것보다 더 안정적인 AWS 의 인스턴스를 늘리는 방향으로도 문제를 해결할 수 있습니다.

또 Thread Pool 모델에는 더 근본적인 한계가 있습니다. Request 마다 하나의 Thread 를 할당해주는 Thread per request 라는 점입니다. 전세계 트래픽의 15% 를 차지한다고 알려진 넷플릭스와 같은 엄청난 서비스들이 등장하면서 하나의 요청에 하나의 스레드를 할당하는 전통적인 Spring MVC 모델은 한계를 가지게 되었습니다. 이러한 문제로 인해 요즘은 Reactive Progamming, Spring webflux 를 많이 사용한다고 하는데요. 다음 포스팅은 webflux 에 대해 알아보도록 하겠습니다.

Reference

[Spring Boot] Tomcat 알아보기 (2) Java Thread Pool

e-una — Thu, 19 Jan 2023 22:47:36 +0900

스프링은 어떻게 동시에 수많은 요청을 처리할까요?

지난 포스팅에서는 동시 요청 처리에 대해 알아보기 전에 Tomcat 의 Servlet Container 역할을 살펴보았습니다.

이번 포스팅에서는 Thread Pool 의 개념과 Tomcat 에서 유사하게 사용되는 Java 의 Thread Pool 클래스에 대해 알아보도록 하겠습니다.

Tomcat 알아보기 두 번째 포스팅 Java Thread Pool 입니다.

Thread Pool

Java 에서 유저 수준 스레드는 커널 수준 스레드에 매핑됩니다. (참고) [Java] JVM 알아보기 - (6) Thread, Java Thread Model

그렇기 때문에 제어할 수 없이 스레드를 많이 생성하면 리소스가 빠르게 고갈될 수 있습니다. 또한 스레드가 늘어날수록 컨텍스트 스위칭 비용도 늘어나게 됩니다. 이러한 문제를 해결하기 위해 Thread Pool 패턴이 도입되었습니다.

동작 과정

Thread Pool 의 동작 과정은 다음과 같습니다.

Thread pool 에 미리 설정한 사이즈 만큼의 스레드를 생성합니다.
Task(Connection, 소켓 객체 등) 처리 요청이 오면 Task Queue 에 Task 를 넣어둡니다.
idle 상태인 스레드가 있다면, Task 큐에서 Task 를 꺼내 해당 스레드에 할당합니다.
1. 만약 idle 상태인 스레드가 없다면, 작업은 Task Queue 에서 대기합니다.
2. 그 상태가 지속되어 Task Queue 가 꽉 차면 스레드를 새로 생성합니다.
3. 이 과정을 반복하다가 스레드 최대 사이즈에 도달하고 작업큐도 꽉 차게 되면, 추가 요청에 대해서 connection-refused 오류를 리턴합니다.
Task 가 완료되면 스레드는 다시 idle 상태로 돌아갑니다.
1. Task Queue 가 비어있고 core size 이상의 스레드가 생성되어 있다면 스레드를 destory 합니다.

정리

스레드 풀은 일정량의 스레드를 미리 만들어두고 Task Queue 를 이용해 Task 를 처리하는 패턴입니다.

스레드를 미리 만들어두고 사용하기 때문에 새로운 스레드를 생성하는 비용을 줄일 수 있고,

사용할 스레드의 개수를 제한하기 때문에 CPU 오버헤드를 방지할 수 있습니다.

즉, 스레드 풀을 사용하면 여러 개의 작업을 동시에 안정적으로 처리할 수 있게 됩니다.

Java 의 Thread Pool

Tomcat 은 Java 기반이기 때문에 Java 의 Thread Pool 클래스와 매우 유사한 Thread Pool 구현체를 가지고 있습니다.

Java 의 Thread Pool 사용법에 대해 간략하게 알아보겠습니다.

기본 용어 정리

corePoolSize & maximumPoolSize

새로운 task 가 submit 될 때 스레드 풀에서 corePoolSize 미만의 스레드가 실행 중인 경우, 다른 스레드가 idle 상태인 경우에도 요청을 처리하기 위해 새 스레드가 생성됩니다. 실행 중인 스레드가 corePoolSize 보다는 크고 maximumPoolSize 보다 작은 경우, task 큐가 가득 찬 경우에만 새 스레드가 생성됩니다.

keepAliveTime

풀에 현재 corePoolSize 보다 많은 스레드가 있는 경우, keepAliveTime 보다 더 오래 idle 상태인 경우 초과 스레드가 종료됩니다.

Executors, Executor 및 ExecutorService

복잡한 애플리케이션에서 직접 Thread 를 만들고 관리하는 것은 매우 어려운 일이기 때문에 Java5 는 스레드 관리를 추상화하는 Executor 를 도입했습니다. Executor 는 개발자 대신 스레드의 라이프 사이클, 사용 및 스케줄링 등을 관리합니다.

Executor 의 상속 관계는 다음과 같습니다.

Executors 라는 유틸 클래스는 Execute, ExecutorService, ScheduledExecutorService 등의 인스턴스 또는 스레드 풀을 생성하는 여러 메서드를 제공합니다. 사용자가 세부 설정을 할 필요가 없는 경우 사용합니다.

Executor

Executor 인터페이스에는 Runnable 인스턴스를 submit 하는 단일 실행 메서드가 있습니다.

Task 를 처리하는 단일 작업자 스레드로, 어떠한 이유로 인해 스레드가 죽으면 교체합니다.

그렇기 때문에 10개의 작업이 있는 대기열이 있다면, 작업은 순서에 따라 차례대로 실행됩니다.

다음은 간단하게 "Hello World" 를 출력하는 단일 작업을 실행하는 예제입니다.

Executor executor = Executors.newSingleThreadExecutor();
executor.execute(() -> System.out.println("Hello World"));

ExecutorService

ExecutorService 에는 Task 진행을 컨트롤하고 서비스의 종료를 관리하는 여러 메서드가 포함되어 있습니다.

이 인터페이스를 사용하여 실행할 작업을 제출하고 반환된 Future 인스턴스를 사용하여 실행을 제어할 수 있습니다.

다음과 같이 executorService 를 사용해서 task 를 submit 하고, task 의 리턴 값을 get() 으로 받아올 수 있습니다.

ExecutorService executorService = Executors.newFixedThreadPool(10);
Future<String> future = executorService.submit(() -> "Hello World");
// some operations
String result = future.get();

ThreadPoolExecutor

세부 설정이 가능한, 많은 매개 변수가 있는 스레드풀 구현 클래스입니다. 가장 일반적인 구성은 Executors 에 정의되어 있습니다.

Executors.newFixedThreadPool()

public static ExecutorService newFixedThreadPool(int nThreads) {
    return new ThreadPoolExecutor(nThreads, nThreads,
                                  0L, TimeUnit.MILLISECONDS,
                                  new LinkedBlockingQueue<Runnable>());
}

이 타입의 풀에는 항상 지정된 수의 스레드가 실행됩니다. 풀의 스레드가 종료되면, 자동으로 새 스레드로 대체됩니다.

동시에 실행되는 task 의 수가 지정한 스레드 수보다 작거나 같으면 즉시 실행되지만, 그렇지 않으면 대기열에 놓이게 됩니다.

Executors.newCachedThreadPool()

public static ExecutorService newCachedThreadPool() {
    return new ThreadPoolExecutor(0, Integer.MAX_VALUE,
                                  60L, TimeUnit.SECONDS,
                                  new SynchronousQueue<Runnable>());
}

사용 가능한 경우 이전에 생성된 스레드를 재사용하는 스레드 풀을 생성합니다.

corePoolSize 를 0 으로 지정하고, maximumPoolSize 를 Interger 최대 값으로 생성합니다. keepAliveTime 은 60초 입니다.

이러한 매개변수 값은 캐시된 스레드 풀이 submit 된 task 를 수용하기 위해서 제한 없이 커질 수 있음을 의미합니다.

그러나 스레드가 60초 동안 활동이 없으면 destroy 되기 때문에, 애플리케이션에 수명이 짧은 작업이 많은 경우 사용합니다.

ScheduledThreadPoolExecutor

일정한 딜레이 후에 실행하거나 주기적으로 실행할 명령을 예약할 수 있는 클래스입니다.

schedule()

public ScheduledFuture<?> schedule(Runnable command,long delay, TimeUnit unit);

public <V> ScheduledFuture<V> schedule(Callable<V> callable, long delay, TimeUnit unit);

지정된 delay 후에 작업을 한 번 실행할 수 있습니다.

scheduleAtFixedRate()

public ScheduledFuture<?> scheduleAtFixedRate(Runnable command,
                                                  long initialDelay,
                                                  long period,
                                                  TimeUnit unit);

지정된 initialDelay 후에 작업을 실행하고, 일정 기간 동안 주기적으로 실행할 수 있습니다.

period 매개 변수는 연속 실행 사이의 기간을 나타냅니다.

scheduleWithFixedDelay()

public ScheduledFuture<?> scheduleWithFixedDelay(Runnable command,
                                                     long initialDelay,
                                                     long delay,
                                                     TimeUnit unit);

주어진 작업을 반복적으로 실행한다는 점에서 scheduleAtFixedRate 와 유사하지만, initialDelay 후에 작업을 시작하고 실행이 종료 된 후에 delay 만큼의 지연이 발생합니다.

마치며

이번 포스팅에서는 선수 지식으로 Thread Pool 의 동작 과정과 구현 클래스들에 대해서 알아보았습니다.

다음 포스팅은 드디어 Tomcat 의 Thread Pool 을 알아볼 수 있게 되었습니다.

Reference

[Spring Boot] Tomcat 알아보기 (1) Servlet 과 Servlet Container

e-una — Tue, 17 Jan 2023 13:46:20 +0900

스프링 부트는 어떻게 동시에 수많은 요청을 처리할까요?

Tomcat 알아보기 첫 번째 포스팅으로 Servlet 과 Servlet Container 에 대해 알아보겠습니다.

Servlet

자바 docs 에서 정의하는 서블릿은 다음과 같습니다.

A servlet is a small Java program that runs within a Web server. Servlets receive and respond to requests from Web clients, usually across HTTP, the HyperText Transfer Protocol.

서블릿은 웹 서버 내에서 실행되는 작은 자바 프로그램입니다. 서블릿은 일반적으로 HTTP 를 통해 웹 클라이언트의 요청을 수신하고 응답합니다.

우리는 웹 페이지를 사용할 때 서버로부터 정적인 리소스를 받기도 하지만, 대부분은 우리가 입력하는 데이터에 따라 변경되는 동적인 리소스를 응답 받습니다. 서블릿을 사용하면 사용자로부터 입력을 받고, 그 데이터에 맞는 웹페이지를 동적으로 생성할 수 있습니다.

'그냥 스프링의 컨트롤러 아냐?' 라고 생각할 수도 있지만,

사실 우리가 구현하는 컨트롤러는 HTTP 를 통해 client 와 request/response 를 주고받지 않습니다.

그 기능은 스프링의 DispatcherServlet 이 하고 있죠.

DispatcherServlet 클래스의 상속 관계를 보면, Servlet API 의 구현체인 HttpServlet 을 확인 수 있습니다.

스프링은 사용자의 요청이 오면 DispatcherServlet(Front Controller) 라는 서블릿을 통해 요청을 받고 적합한 컨트롤러를 찾아 위임해주기 때문에, 개발자들은 컨트롤러에서 간편하게 클라이언트의 요청을 처리할 수 있게 됩니다.

서블릿 인터페이스는 다음과 같습니다.

package javax.servlet;

import java.io.IOException;

public interface Servlet {
    void init(ServletConfig var1) throws ServletException;

    ServletConfig getServletConfig();

    void service(ServletRequest var1, ServletResponse var2) throws ServletException, IOException;

    String getServletInfo();

    void destroy();
}

init(), service(), destory() 메서드를 확인하고 이어서 서블릿의 라이프 사이클에 대해 살펴보겠습니다.

Servlet Container 와 LifeCycle

우리가 자바 코드에서 new 키워드를 사용하면 JVM 이 객체의 인스턴스를 생성합니다.

그렇다면 서블릿 클래스의 인스턴스를 생성하고 관리하는 것은 무엇일까요?

그것 또한 별도의 JVM 위에서 동작하는 자바 프로그램입니다. 이를 Servlet Container 라고 부릅니다.

그리고 Servlet Container 를 포함하고 있는 것이 바로 Tomcat, Jetty 등의 WAS(Web Application Server) 입니다.

Tomcat 에서 동작하는 서블릿의 LifeCycle 을 알아봅시다.

Client 가 request 를 합니다.
톰캣이 가지고 있는 Connector 중 하나를 통해서 request 를 전달받습니다.
톰캣은 해당 요청을 처리하기 위해 적절한 Engine 을 거쳐 적절한 Servlet 에 매핑합니다.
요청이 서블릿에 매핑되면, 톰캣은 힙 메모리에 해당 서블릿의 인스턴스가 존재하는지 확인합니다. 존재하지 않는다면, 인스턴스를 생성하고 인스턴스의 init() 메서드를 호출하여 인스턴스를 초기화합니다.
서블릿이 초기화되면 톰캣은 여러 스레드를 생성하여 여러 요청을 처리합니다.
톰캣은 각 스레드의 단일 서블릿 인스턴스의 service() 메서드를 호출해서 HTTP 요청을 처리합니다. HTTP request method 에 따라 doGet, doPost 등의 메서드를 적절하게 호출합니다.
서블릿이 살아있는 동안, 다양한 상태 변화를 모니터링할 수 있는 listener 클래스를 사용할 수 있습니다. 톰캣은 다양한 방식으로 상태 변화를 저장 및 조회할 수 있고 다른 서블릿들도 해당 데이터에 접근할 수 있습니다.
사용하지 않는 서블릿은 destroy() 메서드를 호출하여 DB Connection 을 닫고, GC 의 대상이 되도록 합니다.

Servlet 의 필요성

Servlet 의 필요성을 두 가지로 정리해 보겠습니다.

Java 스레드를 통한 요청 처리

서블릿이 생기기 이전에는 CGI(Common Gateway Interface) 를 사용해서 외부와 데이터를 주고받았습니다.

CGI 는 C 또는 C++ 로 CGI 프로그램을 만들어서 request 마다 프로세스를 생성하여 동적인 컨텐츠를 만드는 방법입니다.

매 요청마다 프로세스를 생성했기 때문에 클라이언트 수가 증가할수록 많은 비용이 들었습니다.

이러한 CGI 의 단점을 극복하기 위해 Java 기반의 서블릿이 등장했습니다.

서블릿의 장점은 다음과 같습니다.

프로세스가 아닌 각 요청에 대해 스레드를 생성하기 때문에 비용이 낮습니다.
JVM 에 의해 관리되기 때문에 메모리 릭, GC 등을 걱정하지 않아도 됩니다.
Java EE Platform 의 표준으로 동일한 컨테이너와 동일한 서블릿을 사용하기 때문에 확장성이 있습니다.

SRP(Single Responsibility Principle) 원칙을 따른 설계

서블릿 컨테이너에서 Socket Connection, Thread 등의 관리를 하기 때문에 서블릿은 제공하고자 하는 서비스에만 집중할 수 있습니다.

또한 서블릿은 서블릿 컨테이너의 책임에 대한 의존성이 없어서, 다른 환경에서도 쉽게 재사용할 수 있게 됩니다.

Thread Pool 의 등장

Tomcat 3.2 이전 버전에서는 유저의 요청이 들어올 때 마다 Thread 를 하나씩 생성하고, 사용이 끝나면 destory 했습니다.

이러한 방식은 다음과 같은 단점이 있습니다.

모든 요청에 대해 스레드를 생성하고 소멸하는 것은 OS 와 JVM 에게 필요없는 부하를 일으킵니다.
동시에 다수의 요청이 들어올 경우 CPU 또는 메모리 리소스 소모에 대한 제한이 어렵습니다. 결국 순간적으로 서버가 다운되거나 동시 처리에 문제가 생길 수 있습니다.

문제에 대한 해결책으로 Tomcat 3.2 부터는 디폴트로 Thread Pool 을 사용합니다.

다음 포스팅에서는 Tomcat Thread Pool 에 대해 알아보도록 하겠습니다.

Reference

포스팅 내 이미지를 클릭하면 출처로 이동합니다.

[Spring Boot] DTO 는 왜, 언제 사용할까?

e-una — Tue, 3 Jan 2023 23:19:51 +0900

오늘은 Spring Boot 프로젝트를 시작할 때마다 고민의 대상이 되는 DTO 에 대해 알아보도록 하겠습니다.

매번 DTO 의 필요성에 대해 깊이 고민하지 않고 사용해서 그 기준을 잡기가 어려웠는데요.

이번 포스팅을 통해 DTO 의 책임과 역할을 이해하고 저만의 사용 가이드라인을 만들어보도록 하겠습니다.

DTO (Data Transfer Object)

우선, DTO 의 정의를 간략하게 알아보겠습니다.

DTO는 프로세스 간에 데이터를 전달하는 용도의 객체입니다. 비즈니스 로직을 포함하지 않는 데이터를 전달하기 위한 단순한 객체 를 뜻합니다.

MVC 패턴에서는 주로 Client 와 Controller 사이에서 DTO 가 사용됩니다.

저는 보통 Controller 에서는 DTO 로 데이터를 전달받고, 애플리케이션 내부에서는 Domain(또는 Entity 또는 Model) 을 통해 데이터를 전달합니다.

예를 들면 Controller, Service, Repository, DataBase 는 서로 User 라는 도메인 객체를 통해 데이터를 전달하고,

Controller 에서 Client 로 리턴할 때는 UserDTO 에 매핑하여 리턴하는 것입니다.

소스 코드로 구현하면 아래와 같습니다. 코드는 baeldung 의 예제를 가져왔습니다.

DTO 를 통해 원하는 정보만 보여주기

public class User {

    private String id;
    private String name;
    private String email;
    private String password;

    public User(String name, String email, String password) {
        this.name = Objects.requireNonNull(name);
        this.email = Objects.requireNonNull(email);
        this.password = this.encrypt(password);
    }

    // Getters and Setters

   String encrypt(String password) {
       // encryption logic
   }
}

User 객체는 id, name, email, password 의 값을 가지고 있습니다.

password 라는 공개할 수 없는 값을 가지고 있기 때문에 User 객체 그대로 Client 에게 전달할 수 없습니다.

그렇기 때문에 Client 에게 노출해도 되는 필드로만 이루어진 UserDTO 가 필요합니다.

public class UserDTO {
    private String name;
    private String email;
    
    // standard getters and setters
}

Service, Repository 에서는 User 객체로 데이터를 전달하고

Controller 에서 DTO 객체로 매핑해서 Client 에게 리턴합니다.

@RestController
@RequestMapping("/users")
class UserController {

    private UserService userService;
    private Mapper mapper;

    // Constructor

    @GetMapping
    @ResponseBody
    public List<UserDTO> getUsers() {
        return userService.getAll()
          .stream()
          .map(mapper::toDto)
          .collect(toList());
    }
}

@Component
class Mapper {
    public UserDTO toDto(User user) {
        String name = user.getName();
        String email = user.getEmail();

        return new UserDTO(name, email);
    }
}

이처럼 DTO 를 사용하면 Client 에게 password 와 같은 값을 노출하지 않고 원하는 값만 리턴할 수 있습니다.

그런데 막상 DTO 를 사용하려고하면 이런 의문들이 생깁니다.

그렇다면 클라이언트에게 노출해도 되는 값만 가진 도메인 객체라면 그대로 리턴해도 되는걸까?
매번 Controller 에서 도메인 객체를 DTO 객체로 변환하는 비용을 치르더라도 DTO 를 사용해야만 할까?

이제부터 두 가지 의문에 대한 답을 찾아보도록 하겠습니다.

DTO 와 Domain 을 분리하는 이유

그렇다면 클라이언트에게 노출해도 되는 값만 가진 도메인 객체라면 그대로 리턴해도 되는걸까?

관심사의 분리(Separation of Concerns, SoC)

우리가 Spring Boot 와 같은 프레임 워크에서 MVC 패턴을 사용하는 이유는 무엇일까요?

모델1 방식을 사용해보신 분들은 아시겠지만, Model-Controller-View 가 각자의 역할을 수행하여 유지보수가 편리하기 때문입니다.

Controller 는 중간 다리의 역할로 client 와 request/response 하는 책임이 있고, Model 은 DataBase 에서 받아온 데이터를 다루는 책임이 있습니다.

우리가 사는 세상에서도 복잡하고 큰 기업일수록 팀이 철저하게 구분되고 다른 팀이 무엇을 하는지조차 모르는 경우가 있는 것처럼

OOP 세상에서는 관심사의 분리를 통해 복잡한 시스템을 효율적으로 작동하게 합니다.

그런데 '관심사' 라는 말이 잘 와닿지 않습니다. 네이버 영어사전에 concern 을 검색해보았더니 "영향을 미치다" 라는 의미가 나왔습니다.

그렇다면 concerns 를 분리한다는 것은 "애플리케이션에 같은 영향을 미치는 코드들끼리 분리한다"는 것이라고 이해할 수 있습니다.

관심사의 수평적 분리

관심사의 수평적 분리는 애플리케이션 내에서 동일한 역할을 수행하는 논리적 계층으로 애플리케이션을 나눈 것입니다.

프로세스에 따라 MVC 패턴을 녹이면 다음 그림과 같습니다.

Presentation Layer: 애플리케이션의 기능과 데이터를 사용자에게 제공
Business Layer: 애플리케이션의 핵심 비즈니스 로직 및 나머지 두 계층 간에 전달되는 데이터 처리
Data Access Layer: 데이터베이스와 상호 작용하는 역할

여기까지 멀리 돌아왔는데요.. DTO 와 Domain 을 분리해야하는 이유가 바로 여기에서 나옵니다.

DTO 는 오직 데이터를 전달하는 목적으로 Presentation Layer 에 속합니다.

그리고 Domain 은 비즈니스 로직을 담는 Business Layer 에서 역할을 수행합니다.

두 객체를 분리하지 않는다면 Presentation, Business 가 혼합된 god class 가 탄생하게 됩니다.

IT 대기업에서 영업과 개발을 함께하는 그저 god team 을 만들어 버리는 거랄까요.

이렇게 god class 를 만든다면 변경이 있을 때 두 레이어에 영향을 미치게 됩니다.

좋은 객체지향 설계를 위해서는 하나의 객체에는 하나의 책임만 존재해야 합니다. 변경이 있을 때 파급 효과를 최소한으로 하기 위해서죠.

마틴 파울러의 DTO 패턴

매번 Controller 에서 도메인 객체를 DTO 객체로 변환하는 비용을 치르더라도 DTO 를 사용해야만 할까?

마틴 파울러는 저서 Patterns of Enterprise Application Architecture(P of EAA) 에서 DTO 를 소개하며

DTO 의 주요 목적에 대해 아래와 같이 말했습니다.

The main reason for using a Data Transfer Object is to batch up what would be multiple remote calls into a single call

마틴 파울러가 말하는 DTO 의 주요 목적은 한 번의 호출로 여러 매개 변수를 일괄 처리해서 서버의 왕복을 줄이는 것입니다.

해당 호출에 관련 된 모든 데이터를 가지고 있는 DTO 객체를 만들어서 네트워크 비용을 줄인다는 의미입니다.

OKKY 에 이해하기 좋은 댓글이 있어서 첨부하도록 하겠습니다.

대표적으로 유저 테이블이 있다고 가정하면, 이 유저라는 정보는 광범위하게 사용될 것 입니다.
또 게시판이 있을 수 있고, 상품 판매 화면이 있을 수 있고, 결제가 있을 수 있고, Q&A 게시판이 있을 수 있습니다.

그렇다면 예를 들어, 상품정보와 Q&A는 서로 다른 테이블에 구현이 되겠는데
특정 상품 소개 페이지 안에 해당 상품과 관련은 없어도 연관성은 있는
질문들의 Q&A 만 뽑아서 보여주고 싶다면? 거기에 구매한 몇몇 유저들의 정보까지 포함시키고 싶다면?

상품소개 API 1개
Q&A API 1개
유저 API 1개

이렇게 3개의 API를 호출하실건가요? 네 이것도 틀린 방법은 아닙니다. 잘못된 방법도 아닙니다.
충분히 유효한 방법입니다.

그런데 그렇다면 모든 불필요한 정보까지 전부 반환이 될 것이고

결국 통신도 3회 이루어졌는데, 이걸 1회로 줄일 수 있다면?

방법은 간단하겠죠. 서비스 3개는 존재할테고, 이를 부르는 컨트롤러 하나에서
DTO를 준비하고, 여기에 필요한 필드를 미리 구성해놓은 다음에
서비스 3개에서 리턴된 오브젝트에서 뽑아서 매핑시켜주면 됩니다.

그러면 컨트롤러 1개가 불필요한 정보 없이 API 1개만으로 원하는 응답을 모두 해줬습니다.

출처: [OKKY] 카카오콘 님, https://okky.kr/articles/1293573

추가로 인프런에 김영한 님이 답변하신 글도 참고하면 좋을 것 같아 첨부하겠습니다.

항상 유지보수에서 가장 문제가 되는 것이 바로 애매한 것입니다.
특히 같은 필드인데, 어떤 경우에는 null이고 어떤 경우에는 값이 있고 이렇게 모호하면 정말 유지보수가 어려워집니다.
그래서 API 응답 스펙이 정해지면 그 필드에 값은 항상 같은 원칙으로 반환되도록 명확하게 설계하는 것이 중요합니다.
클래스를 여러개 만들더라도, 코드가 중복되는 것 처럼 보일지라도, 명확한 것이 훨씬 더 나은 선택이라는 것이지요.

다만 API를 제공할 때 또 모든 케이스에 대응해서 만들면 API 자체가 너무 많아집니다.
그래서 null 값 대신에 실제 값을 채워서 반환하는 API를 제공하는 것이 좋습니다.
예를 들어서 username, age 둘다 제공하는 공통 API 하나를 여러곳에서 사용하도록 제공하는 것이지요.
실무에서 API를 설계할 때 진짜 고민은, 생각보다 너무 복잡하다는 것입니다.

어떻게 보면 제공 단위를 크게 만들어서 모든 데이터를 다 반환하는 API 하나를 만들면 될 것 같지만, 이렇게 너무 공통화해도 유지보수가 어렵고, 성능 이슈가 있습니다. 반대로 너무 각각의 케이스를 대응하도록 만들어도 API 자체가 많아져서 유지보수가 어렵습니다.
이 사이에서 적절한 단위로 API를 설계하고 제공하는 것이 묘미이지요^^!

제가 선호하는 방법은 기본 공통 API를 제공하고, 이 기본 공통 API로 해결이 안되는 특수한 경우에 한해서 별도의 API를 제공하는 방법을 선호합니다.

출처: [인프런] 김영한 님, https://www.inflearn.com/questions/72423/dto

여러 의견을 종합해 본 저의 결론은 다음과 같습니다.

DTO 를 사용하는 주요 목적은 한 번의 호출로 해당 호출에 관련 된 모든 데이터를 담은 객체를 리턴 받아 사용하는 것입니다.
네트워크 비용 > 컨트롤러에서 매번 변환하는 비용 이라고 판단한 것입니다.
이 때, 같은 필드인데 어떤 경우에는 null 이고 어떤 경우에는 값이 있다면 유지보수가 어려워집니다.
그렇기 때문에 null 없이 모든 필드에 값이 있는 공통 DTO 를 사용합니다.
공통 DTO 가 커져서 성능에 이슈가 생기거나, 특수한 경우에만 별도의 DTO 를 사용합니다.

마치며

이번 포스팅에서는 제가 DTO 에 대해 가지고 있던 의문을 다뤄보았습니다.

아직 DTO 를 공통으로 사용하는 것에 대한 의문이 조금 있지만, 사용하다가 개선하게 되면 업데이트 하도록 하겠습니다. :)

Reference

역할, 책임, 협력 - 조영호, 객체지향의 사실과 오해, 위키북스, p.114-115
MVC Layering Architecture: DTO 와 Domain Model 을 분리해야 하는 이유
[Spring] 엔티티(Entity) 또는 도메인 객체(Domain Object)와 DTO를 분리해야 하는 이유
MVC 창시자가 말하는, MVC의 본질
Entitiy 와 DTO 의 분리
The Art of Separation of Concerns

[Spring Boot] Maven Multi Module

e-una — Fri, 16 Dec 2022 01:41:38 +0900

안녕하세요. 이번 포스팅에서는 메이븐으로 멀티 모듈 프로젝트를 구성하는 방법에 대해 알아보겠습니다.

먼저 Maven과 Multi Module이 무엇인지 알아보고, 그 후에 인텔리제이 IDE 를 사용하여 프로젝트를 구성해보겠습니다.

Apache Maven

우리는 소스 코드를 작성하고 코드를 실행하기 위해 JAR 나 WAR 등의 파일을 만든다.

이처럼 소스 코드 파일 및 리소스를 컴퓨터에서 실행 가능한 산출물(Artifact)로 만드는 일련의 과정을 Build 라고 한다.

빌드는 전처리, 컴파일, 패키징, 테스팅, 배포 등의 여러 과정으로 이루어지지만

개발자들은 Maven 과 같은 Build Tool 을 사용하여 한 번의 클릭으로 실행 파일을 얻을 수 있다.

Project Object Model (POM)

메이븐은 POM 을 통해 프로젝트를 설명하고 종속성을 관리한다. 또한 멀티 모듈 프로젝트의 모듈 간 관계를 정의한다.

POM 은 루트 디렉토리에 pom.xml 파일로 생성된다. 일반적인 pom.xml 의 구조를 살펴보자.

<project>
    <modelVersion>4.0.0</modelVersion>
    <groupId>com.una</groupId> // 프로젝트를 생성한 회사 또는 그룹의 고유한 기본 이름
    <artifactId>una</artifactId> // 프로젝트의 고유한 이름
    <packaging>jar</packaging> // 패키징 방법 (e.g. war, jar, zip ...)
    <version>1.0-SNAPSHOT</version>
    <name>com.una</name>
    
    <properties> // 사용자가 지정하는 속성
    	<spring.version>5.3.16</spring.version>
    </properties>

    <dependencies> // 프로젝트에서 사용하는 라이브러리 관리
        <dependency>
            <groupId>org.junit.jupiter</groupId>
            <artifactId>junit-jupiter-api</artifactId>
            <version>5.8.2</version>
            <scope>test</scope>
        </dependency>
        <dependency>
        <groupId>org.springframework</groupId>
        <artifactId>spring-core</artifactId>
        <version>${spring.version}</version>
    </dependency>
    </dependencies>
    <build> 
        <plugins> // 빌드에 사용하는 플러그인 관리
            <plugin>
            //...
            </plugin>
        </plugins>
    </build>
</project>

groupId: 프로젝트를 생성한 회사 또는 그룹의 고유한 기본 이름
artifactId: 프로젝트의 고유한 이름
packaging: 패키징 방법 (e.g. war, jar, zip ...)
properties: pom.xml 파일 내에서 ${name} 표기법을 사용해서 변수처럼 사용할 수 있다.
- 버전을 변경할 때 properties 내에 있는 숫자만 변경하면 해당 속성을 사용하는 모든 종속성이 업데이트되기 때문에 편리하다.
dependency: 프로젝트와 의존 관계에 있는 라이브러리 관리 (종속성 관리)
- Maven 은 중앙 리포지토리에서 해당 라이브러리를 자동으로 다운로드하기 때문에 로컬에 저장하지 않아도 된다.
- 외부 라이브러리에 대한 종속성을 선언하기 위해서는 groupId, artifactId, version 을 명시해야한다.

Maven 의 장점과 단점

장점

프로젝트의 종속성을 파일 하나로 관리할 수 있다.
중앙 리포지토리에서 라이브러리를 다운로드하기 때문에 스토리지 사용량이 적다.

단점

메이븐을 통해 라이브러리를 다운받기 위해서는 메이븐을 설치해야한다.
- Maven Wrapper 를 통해 메이븐을 설치하지 않고 사용하는 방법이 있다.

Multi Module

모듈은 독립적으로 운영될 수 있는 구성요소의 단위다. 예로는 우리가 pom.xml 에 명시하는 외부 라이브러리들이 있다.

그렇다면 하나의 프로젝트를 멀티 모듈로 구성하는 이유가 무엇일까?

그 이유에는 여러 가지가 있을 것이다.

FrontEnd, BackEnd 를 한 번에 빌드하기 위해

여러 프로젝트에서 동일한 도메인을 사용하기 위해

여러 프로젝트에서 동일한 버전의 라이브러리를 사용하기 위해

결국 멀티 모듈을 구성하면 하나의 비즈니스를 여러 프로젝트로 역할과 책임을 나누어 관리하기 용이해진다.

실습 프로젝트 구성

이번 실습에서는 종속성을 루트 프로젝트에서 관리하기 위해 멀티 모듈을 구성해보도록 하겠다.

루트 프로젝트는 모든 프로젝트에서 공통적으로 사용하는 라이브러리들을 관리하는 용도로 사용한다.

먼저 루트 프로젝트를 maven 으로 생성한다.

다음과 같이 루트 프로젝트가 생성되었다.

루트 프로젝트는 pom 의 역할을 하기 때문에 패키징을 pom 으로 추가한다.

그리고 spring-boot-starter-parent 를 선언한다.

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>
    <packaging>pom</packaging>

    <parent>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-parent</artifactId>
        <version>2.7.2</version>
    </parent>

    <groupId>org.example</groupId>
    <artifactId>parent-project</artifactId>
    <version>1.0-SNAPSHOT</version>
</project>

spring-boot-starter-parent 는 부모인 spring-boot-dependencies 를 살펴보면 다음과 같다.

스프링 부트를 사용하면서 필요한 여러 dependency 들이 선언되어 있다.

spring-boot-starter-parent 를 사용하는 이유는 다음과 같다.

개발자가 직접 dependency 를 하나하나 추가하지 않아도 된다.
사용하는 스프링 버전에 맞는 dependency 들의 버전 관리가 편리하다.

이제 Spring Boot 자식 모듈을 생성해보자.

Dependency 는 Spring Web 만 추가해주었다.

동일하게 하나의 자식 모듈을 더 생성했다. 이제 프로젝트 구조는 다음과 같다.

parent-project 밑에 core, service 모듈을 생성했다.

루트 프로젝트의 pom.xml 에 자식 모듈을 추가한다.

<modules>
    <module>core</module>
    <module>service</module>
</modules>

자식 모듈의 pom.xml 을 보면 parent 로 spring-boot-starter-parent 를 바라보고 있을 것이다.

<!-- 변경 전 -->
<parent>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-parent</artifactId>
    <version>3.0.0</version>
    <relativePath/> <!-- lookup parent from repository -->
</parent>

다음과 같이 변경하여 루트 프로젝트를 바라보도록 하자.

<parent>
    <groupId>org.example</groupId>
    <artifactId>parent-project</artifactId>
    <version>1.0-SNAPSHOT</version>
</parent>

이제 자식 모듈에서 종속성을 관리해보자. pom.xml 에 라이브러리를 추가한다.

자식 모듈에서 다른 버전을 사용해야 한다면 버전을 명시하여 재정의할 수 있다.

<dependencies>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-web</artifactId>
    </dependency>

    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-test</artifactId>
    </dependency>
</dependencies>

터미널을 열어서 세 개의 모듈을 한 번에 빌드해보자. 루트 프로젝트 디렉토리에서 다음 명령어를 입력한다.

mvn package

모든 모듈이 한 번에 빌드 된 것을 확인할 수 있다.

마치며

이번 포스팅에서는 메이븐을 통해 멀티 모듈을 구성해보았습니다.

더 복잡한 멀티 모듈 프로젝트에는 Gradle 을 사용하면 최적화할 수 있으나 아직까지는 루트 프로젝트가 종속성 관리의 역할만 하고 있기 때문에, 그리고 이후 문제 발생 시 빌드 툴의 변경이 어렵지 않다고 하여 사용이 익숙한 Maven 으로 구성하였습니다.

Reference

[Java] JVM 알아보기 - (6) Thread, Java Thread Model

e-una — Mon, 5 Dec 2022 14:11:54 +0900

내가 만든 자바 코드가 어떤 과정으로 실행되는지 알아보기 위한 "JVM 알아보기" 마지막 포스팅입니다.

이번 포스팅에서는 Thread 와 Java Thread Model 에 대해 알아보겠습니다.

Thread

우리가 자바 프로그램을 실행하면 JVM 프로세스가 실행되고, JVM 프로세스 안에서 GC 를 포함한 여러 개의 스레드가 실행된다.

그리고 각 스레드마다 Java Stack, PC Register, Native Method Stack 이 존재한다.

이렇게 자바는 동일한 메모리를 읽지만 각각 작업을 수행하는 스레드들, 즉 멀티 스레드를 통해 동시에 여러 작업을 수행한다.

자바는 왜 프로세스를 여러 개 추가하지 않고 스레드라는 개념을 만든 것일까?

그 이유는 프로세스를 생성하려면 많은 시간과 자원이 필요하기 때문이다.

예를 들면, JVM 은 벤더마다 다르지만 최소 32MB 이상의 메모리가 필요하다.

그에 비해 스레드는 1MB 이내의 메모리를 점유한다. 그렇기 때문에 스레드를 경량 프로세스 라고도 부른다.

이번 포스팅에서는 스레드 모델의 변화와 그 이유를 중점으로 스레드에 대해 알아보도록 하겠다.

Multi Threading Model

스레드에는 사용자 수준 스레드(User Level Threads)와 커널 수준 스레드(Kernel Level Threads) 두 가지 유형이 있다.

먼저 두 가지 유형을 간단하게 알아보자.

사용자 수준 스레드는 사용자 라이브러리를 통해 사용자가 만든 스레드로, 스레드가 생성 된 프로세스의 주소 공간에서 해당 프로세스에 의해 실행되고 관리된다. 그리고 커널 수준 스레드는 커널에 의해 생성되고 운영체제에 의해 직접 관리된다. 사용자 수준 스레드보다 생성 및 관리 속도가 느리다.

두 유형의 차이는 누가 스레드를 제어하느냐에 있다.

사용자 수준 스레드는 스레드가 생성 된 프로세스 자체에 의해 제어되며, 커널은 프로세스 내의 사용자 스레드에 대해 알지 못한다.

커널 수준 스레드는 OS에 의해 직접 관리된다.

사용자 스레드를 실행한다고 가정해보자.

스레드를 실행하기 위해서는 커널의 CPU 스케줄러가 스레드를 CPU 에 스케줄링 해야 한다.

그런데 CPU 스케줄러는 커널의 일부이기 때문에 사용자 스레드에 대해 알지 못한다.

이러한 이유로 사용자 스레드는 커널 스레드에 매핑되어 실행하게 된다.

이 과정을 신제품 출시에 비유할 수 있다. 우리가 출시하려는 신제품은 사용자 스레드다.

이 제품을 판매하기 위해 제품의 회사를 정부에 등록해야한다. 여기서 회사는 프로세스, 정부는 커널이다.

회사는 상점에 입점을 하고, 입점을 위해서 정부의 규칙을 따라야한다. 이 상점이 커널 스레드다.

즉, 커널 스레드(상점)와 프로세스(회사)가 매핑되어 있고, 그 프로세스 내에서 사용자 스레드가 생성되기 때문에 커널에서 인식할 수 있는 것이다.

커널 스레드와 사용자 스레드를 매핑하는 이유를 알아보았으니 이제 매핑 방법에 대해 알아보도록 하겠다.

매핑 방법에는 일반적으로 세 가지가 있다.

Many-to-One Model, 다대일 모델

다대일 모델은 여러 사용자 스레드를 하나의 커널 스레드에 매핑한다. 스레드는 사용자 공간의 스레드 라이브러리에 의해 관리된다.

한 스레드가 Blocking 되는 경우에 전체 프로세스가 Block 된다.

한 번에 하나의 스레드만이 커널에 접근할 수 있기 때문에, 멀티 코어 시스템에서 병렬로 실행될 수 없다.

하지만 동기화 및 리소스 공유가 쉽기 때문에 실행 시간이 단축된다.

Java 의 초기 버전의 스레드 모델인 Green Thread 가 다대일 모델을 사용하였다.

대부분의 컴퓨터 시스템에서 멀티 코어가 표준이 되면서 그 이점을 살릴 수 없는 Green Thread 는 현재 Java 에서 사용되지 않는다.

One-to-One Model, 일대일 모델

일대일 모델은 각 사용자 스레드를 각각 하나의 커널 스레드에 매핑한다.

그렇기 때문에 하나의 스레드가 Blocking 되더라도 다른 스레드가 실행될 수 있기 때문에 병렬 실행이 용이하다.

이 모델의 단점은 사용자 스레드를 만들기 위해서는 커널 스레드를 만들어야 한다는 것이다.

많은 수의 커널 스레드는 시스템 성능에 부담을 줄 수 있기 때문에 Window 나 Linux 는 스레드 수의 증가를 제한한다.

Many-to-Many Model, 다대다 모델

다대다 모델은 여러 개의 사용자 스레드를 그보다 작은 수 혹은 같은 수의 커널 스레드로 멀티플렉스한다.

커널 스레드의 수는 응용 프로그램에 따라 다르다. 4코어 시스템보다 8코어 시스템에서 더 많은 커널 스레드를 할당받는다.

이전 두 모델의 단점을 절충한 방법으로, 개발자는 필요한 만큼 사용자 스레드를 생성하고 그에 상응하는 커널 스레드가 병렬로 수행될 수 있다. 가장 높은 정확도의 동시성 처리를 제공하는 모델로, 하나의 스레드가 Blocking 되었을 때 커널은 다른 스레드의 수행을 스케쥴할 수 있다.

또한, 다대다 모델은 two-level-model(두 수준 모델) 이라고도 불리는데

다대다 모델은 사용자 스레드가 하나의 커널 스레드에만 연결되는 일대일 모델로 동작하는 것도 허용하기 때문이다.

two level model

다대다 모델이 세 모델 중 가장 융통성있는 것 처럼 보이지만 실제로는 구현하기가 어렵다.

그리고 대부분의 시스템에서 코어 수가 증가하면서 커널 스레드를 제한하는 것의 중요성이 줄어들었다.

따라서 현재 대부분의 운영체제는 일대일 모델을 사용한다.

그렇다면 현재 자바의 스레드는 어떤 모델을 사용할까?

자바는 JDK 1.3 이후로 다대다 모델을 사용한다. 이를 Native Thread 라고 한다.

Green Thread vs. Native Thread

자바는 초기에는 Green Thread 를 사용하다가 Native Thread 로 스레드 모델을 변경하였다.

마지막으로 두 스레드 모델의 차이점을 정리하고 포스팅을 마치도록 하겠다.

마치며

그린 스레드는 커널의 개입 없이 사용자 레벨에서 관리하는 스레드 모델을 의미하고

네이티브 스레드는 현재 우리가 사용하는 스레드를 의미한다.

애플리케이션 수준에서 JVM 이 완전하게 관리하는 그린 스레드 모델은 멀티 코어 시스템이 보편화되면서 자바에서 사라졌다.

Reference

JavaTpoint, Multithreading Models in Operating system
GeeksForGeeks, Why must user threads be mapped to a kernel thread
GeeksForGeeks, Green vs Native Threads and Deprecated Methods in Java
Why not Green Threads?
What's the difference between 'green threads' and 'user threads'
Operating System Concepts (10e) 4.3 다중 스레드 모델

[Java] JVM 알아보기 - (5) JVM GC 유형, G1 GC

e-una — Tue, 29 Nov 2022 22:06:54 +0900

내가 만든 자바 코드가 어떤 과정으로 실행되는지 알아보기 위한 "JVM 알아보기" 다섯 번째 포스팅입니다.

이번 포스팅에서는 JVM GC의 여러 유형에 대해 살펴보고, 그 중 G1 GC 에 대해 자세히 알아보겠습니다.

지난 포스팅에서 이야기한 것과 같이 GC 에는 여러 유형이 있다. 그 중 몇 가지를 알아보도록 하자.

Serial GC

직렬 GC

단일 스레드로 작동하는 가장 간단한 GC 다. 따라서 다중 스레드 프로그램에서는 사용하지 않는다.

단일 스레드를 사용하면 여러 스레드 간에 통신 오버헤드가 없기 때문에 효율성이 높다.

Young 영역의 GC 는 지난 포스팅에서 설명한 방식과 같고, Old 영역의 GC 는 Mark-and-Sweep-Compact 알고리즘을 사용한다.

메모리가 적고 CPU 코어의 개수가 적은 간단한 프로그램에 적합하다.

Parallel GC

병렬 GC, Throughput(처리량) GC

Parallel GC 는 Java 8 의 default JVM 이다.

Serial GC 와 알고리즘은 같지만, 다중 스레드로 동작한다는 차이가 있다.

여러 CPU 를 사용하여 처리 속도가 높기 때문에 처리량 GC 라고도 불린다.

대량 데이터 처리, 일괄 처리와 같은 긴 프로세스를 실행하고 긴 STW(Stop-The-World) 가 허용되는 프로그램에 사용된다.

애플리케이션이 최고의 처리량을 달성해야하고, 1초 이상의 일시적인 작업 중지가 허용된다면 이 GC 를 사용한다.

G1 GC

Garbage First GC

G1 GC 는 Java 9 의 default JVM 으로, 다른 GC 들과는 Heap 의 구조가 매우 다르다.

힙을 동일한 크기의 여러 영역(Region)으로 나누고 각 영역에 객체를 할당하며, 영역 별로 GC 를 수행한다.

다른 가비지 컬렉터가 사용하던 Eden, Survivor 등의 세대 별 영역도 동일한 크기의 여러 영역을 사용한다.

Humongous Region 은 하나의 Region 의 50% 이상 크기를 가진 객체에 할당된다.

G1 은 힙 전체에서 살아있는 객체와 가비지를 식별하기 위해 Concurrent Global Marking(동시 글로벌 마킹)을 진행한다.

마킹이 완료되면 회수 가능한 객체, 즉 가비지로 가득 차 있을 가능성이 큰 힙 영역부터 Sweep 을 진행한다.

G1 GC 는 메모리 공간이 큰(힙 크기가 4GB 이상인) 다중 프로세서 시스템 용으로 설계되었다.

영역 별로 GC 를 수행하기 때문에 STW 가 짧아 튜닝이 거의 필요하지 않고, 높은 처리량을 보인다.

G1 에서 사용하는 자료구조

Remember Set(RSet)

힙에는 Region 마다 RSet 가 존재한다.

참조를 가진 객체들이 어느 영역에 있는지 추적하기 위한 자료구조다.

Collection Set(CSet)

GC 에서 수집 될 Region 의 집합이다.

G1 GC 의 프로세스

1. G1 Heap 구조

힙은 여러 Region 으로 나뉜다. 영역의 크기는 JVM 이 결정하는데, 각 영역의 크기는 최소 1MB 부터 최대 32MB 까지 다양하다.

2. G1 Heap 할당

각 Region 은 Eden, Survivor 등의 논리적 영역으로 매핑된다.

3. G1 의 Young GC

Young GC 수행

Young GC 수행 후

기존의 방식과 같이 Eden 공간이 가득차면 Survivor 공간으로 살아있는 객체를 복사하고, 일정 Age bit 가 넘어가면 Old 영역으로 promotion 된다. 하나 이상의 영역이 하나의 영역으로 복사되면서 압축된다.

Young GC 가 일어날 때는 STW 가 발생하며, 여러 스레드를 사용해서 병렬 수행된다.

4. G1 의 Old GC

G1 의 Old GC 는 다섯 가지 프로세스로 수행된다.

Initial Mark(STW): Old Region 에 있는 객체에서 참조하는 Survivor Region (Root Region) 을 찾는다.
Root Region Scanning: 이전 단계(Initial Mark)에서 마크 해두었던 Root Region 을 스캔한다.
Concurrent Marking: 전체 힙에서 살아있는 객체를 찾고 빈 Region 을 표시한다. 멀티 스레드로 동작하며, 애플리케이션과 동시에 동작한다.

Remark(STW): 힙에서 살아있는 객체에 마킹을 완료한다. 빈 Region 은 제거된다. 멀티 스레드로 동작하며 SATB(Snapshot-at-the-Beginning) 알고리즘을 사용한다.
CleanUp(STW): 가비지가 제일 많은 Region 을 정리한다. 해당 Region 은 Young GC 와 동시에 수집되는데, 이를 Mixed GC 라고 한다.

모든 Old GC 의 프로세스가 끝나면 다음과 같이 압축된 상태로 정리된다.

마치며

이번 포스팅에서는 JVM GC 의 몇 가지 유형과 Java 9 의 default GC 인 G1 GC 에 대해서 알아보았습니다.

Region 별로 GC 를 수행하여 STW 시간을 줄였고, 하나 이상의 Region 을 하나로 압축하면서 파편화를 방지하는 장점이 있습니다.

다음 포스팅에서는 JVM 의 Thread 를 다루겠습니다.

Reference

[Java] JVM 알아보기 - (4) JVM GC, Heap

e-una — Sun, 27 Nov 2022 23:51:10 +0900

내가 만든 자바 코드가 어떤 과정으로 실행되는지 알아보기 위한 "JVM 알아보기" 네 번째 포스팅입니다.

이번 포스팅에서는 JVM 의 GC 와 Heap 에 대해서 알아보겠습니다.

JVM GC(Garbage Collection)

개발자는 직접 자바의 메모리 관리를 하지 않아도 된다.

메모리 관리를 JVM 이 알아서 하기 때문인데, JVM 내에서 메모리 관리를 해주는 것을 가비지 컬렉터 라고 부른다.

가비지 컬렉터는 힙에서 사용 가능한 모든 객체를 추적하고 사용하지 않는 객체에 할당 된 메모리를 해제한다.

이 작업을 가비지 컬렉션, GC 라고 한다.

GC 의 프로세스를 알아보기 이전에, 먼저 GC 와 관련 된 개념들을 정리해보자.

UnReachable Object

유효한 참조가 없는 객체를 UnReachable Object(도달할 수 없는 객체)라고 한다.

그리고 UnReachable 하다고 간주되는 객체는 GC 의 대상이 된다.

그렇다면 유효한 참조를 판단하는 기준은 무엇일까?

앞서 JVM 의 GC 는 힙에서 사용 가능한 모든 객체를 추적한다고 했다. GC 는 객체 그래프를 순회하며 모든 객체를 식별한다.

그래프를 순회하려면 시작점이 필요한데 이 시작점을 GC의 root 라고 한다.

이 GC 루트에서 직접 또는 간접적으로 참조되는 모든 객체는 Reachable 한 객체(도달할 수 있는 객체)로 구분되어 GC 되지 않는다.

반대로 GC 루트에서 참조되지 않는 UnReachable 한 객체들은 사용하지 않는다고 간주되어 GC 의 대상이 된다.

GC root 는 주로 다음과 같다.

Class, 클래스 변수
Java Stack, 메서드 실행 시에 사용하는 지역 변수와 파라미터들
메서드 영역의 정적 변수
Native Stack, JNI(Java Native Interface) 에 의해 생성된 객체

GC 의 대상이 되는 객체

null 로 선언 된 참조 변수
재할당 된 참조 변수
메서드 내부에서 생성된 객체
고립된 섬(Island of Isolation) : 객체 A 와 B 가 서로만을 참조할 때 두 객체 모두 호출할 수 있는 방법이 없어진 경우 또는 참조되지 않는 단일 객체

Island of Isolation

Island of Isolation 의 예시를 보자.

객체를 두 개 만들어서 서로만을 참조하게 한 뒤, 두 객체를 모두 null 로 만들고 가비지 컬렉터를 호출해보자.

Java

// Main class
public class GFG {
 
    GFG i;
 
    // Method 1
    // Main driver method
    public static void main(String[] args)
    {
 
        // Creating object of class inside main() method
        GFG t1 = new GFG();
        GFG t2 = new GFG();
 
        // Object of t1 gets a copy of t2
        t1.i = t2;
 
        // Object of t2 gets a copy of t1
        t2.i = t1;
 
        // Till now no object eligible
        // for garbage collection
        t1 = null;
 
        // Now two objects are eligible for
        // garbage collection
        t2 = null;
 
        // Calling garbage collector
        System.gc();
    }
 
    // Method 2
    // overriding finalize() Method
    @Override protected void finalize() throws Throwable
    {
        // Print statement
        System.out.println("Finalize method called");
    }
}

Output

Finalize method called
Finalize method called

객체를 파괴하기 전에 가비지 컬렉터는 finalize 메서드를 호출한다.

t1 만 null 로 만들고 가비지 컬렉터를 호출하면 GC 가 동작하지 않는다. t2 라는 외부 참조가 있기 때문이다.

t1 과 t2 가 모두 null 이 되면 두 객체를 호출할 수 있는 방법이 없으므로 두 객체 모두 GC 의 대상이 된다.

stop-the-world

GC 는 root 에서부터 객체 그래프를 순회하며 객체가 참조되고 있는지 추적한다. 그리고 참조되지 않는 객체를 제거한다.

이 작업은 애플리케이션이 실행되는 중에 병행되어야 하는데, 그러기 위해서는 GC 이외의 모든 쓰레드의 작업을 중단해야한다.

GC 를 실행하기 위해 JVM 이 GC 를 실행하는 쓰레드 이외의 모든 쓰레드의 작업을 멈추는 것을 stop-the-world 라고 한다.

작업이 완료될 때까지 모든 작업이 중지되기 때문에 성능 저하의 원인이 된다.

따라서 이 stop-the-world 의 작업 시간을 줄이는 것이 GC 튜닝의 주요 목적이 된다.

JVM GC 의 알고리즘

Mark and Sweep

기본적으로 GC 는 Mark and Sweep 이라는 두 가지 프로세스로 동작한다.

Marking

Sweep

Marking 단계에서 사용 중인 메모리와 그렇지 않은 메모리를 식별하고

Sweep 단계에서 사용하지 않는다고 식별 된 메모리를 제거한다.

compacting

새 메모리 할당 시의 성능을 위해 참조되지 않는 객체를 삭제한 뒤에 빈 공간을 압축하는 방법도 있다.

GC 와 Heap

Weak Generational Hypothesis, 약한 세대 가설

GC 는 Heap 영역 내의 모든 객체들을 대상으로 동작한다. 그리고 실행 중인 애플리케이션은 시간이 지남에 따라 더 많은 객체를 생성한다.

따라서 시간이 지날수록 점점 더 객체가 많아지고 GC 작업의 시간이 증가할 것이다.

이를 해결하기 위해 JVM 은 객체의 세대를 분리했다. 다음 그래프를 보자.

객체 수명에 대한 일반적인 분포

X 축은 객체의 수명을, Y 축은 살아있는 객체 수(할당 된 총 바이트 수)를 나타낸다.

그래프의 분포를 보면 왼쪽에 수명이 짧은 객체가 엄청나게 많다. 대부분의 객체는 짧은 시간동안 사용되고 메모리가 해제되는 것이다.

이것을 weak generational hypothesis 라고 한다.

이 전제를 통해 GC 의 효율적인 수집이 가능하다. 객체의 세대를 분리하여 각각 GC 를 수행하는 것이다.

Young 영역

우선, Young 영역부터 알아보자. 이 영역에는 새로 생성한 객체의 대부분이 할당된다.

Young 영역의 GC 프로세스는 다음과 같다.

Eden 영역에 객체가 생성된다.
Eden 영역이 가득 차면 GC가 발생하여 Mark and Sweep 의 과정을 거쳐서 살아있는 객체만 Survivor 영역 중 하나로 이동되고, 다시 Eden 영역을 채운다.
이 과정을 반복하여 하나의 Survivor 영역이 가득 차게 되면 살아있는 객체만 나머지 비어있는 Survivor 영역으로 이동된다. 이때, Eden 영역에 있는 살아있는 객체들도 비어있던 Survivor 영역으로 간다. 즉, Survivor 영역의 둘 중 하나는 반드시 비어있어야 한다.

이와 같이 Young 영역에서 발생하는 GC 를 Minor GC 라고 한다.

Minor GC 는 대부분의 객체가 가비지일 것을 가정하고 최적화되어 동작한다.

일반적으로 더 작은 공간이 할당되고, 많은 객체를 검사하지 않기 때문에 속도가 빠르다.

몇 차례의 Minor GC 가 수행되고도 살아남은 객체들은 Old 영역으로 이동하게 된다. 이를 Promotion 이라고 한다.

각 객체는 Minor GC 에서 살아남은 횟수를 기록하는 age bit 를 가지고 있고, Minor GC 가 발생할 때마다 age bit 값이 1씩 증가한다.

age bit 값이 MaxTenuringThreshold 라는 설정값을 초과하게 되는 경우 객체가 이동된다.

Old 영역

Old 영역에서 수행되는 GC 는 Major GC 라고 한다. 모든 라이브 객체를 수집해야 하기 때문에 훨씬 속도가 느리며, 수행 빈도도 적다.

Old 영역의 GC 는 GC 방식에 따라 처리 프로세스가 달라진다.

GC 방식에는 여러 유형이 있다.

Serial GC
Parallel GC
Parallel Old GC (Parallel Compacting GC)
Concurrent Mark and Sweep (CMS)
G1(Garbage First) GC
그 외의 여러 유형

마치며

이번 포스팅에서는 JVM 의 GC 와 JVM Heap 의 구조에 대해 알아보았습니다.

다음 포스팅에는 GC 의 유형 별 프로세스와 장단점에 대해 다루도록 하겠습니다.

Reference

[Java] JVM 알아보기 - (3) JVM Memory Structure

e-una — Wed, 23 Nov 2022 01:23:50 +0900

내가 만든 자바 코드가 어떤 과정으로 실행되는지 알아보기 위한 "JVM 알아보기" 세 번째 포스팅입니다.

이번 포스팅에서는 JVM 메모리 구조에 대해서 알아보겠습니다.

JVM Architecture

지난 포스팅에서 이야기한 것과 같이, ClassLoader 는 ".class" 파일에서 바이너리 데이터를 생성하여 Method Area 에 저장한다.

JVM Architecture 그림을 보면 Method Area 는 Runtime Data Areas 의 한 부분이다.

JVM 은 OS 로부터 프로그램 실행 중에 사용되는 메모리 영역을 할당받는데, 이를 Runtime Data Areas 라고 한다.

앞으로 설명할 Method Area 나 Heap Area 는 JVM 의 스펙에 정의되어 있는 논리적 개념이다.

모든 JVM 에 Method Area 가 있지만, "여기가 Method Area 입니다." 라는 것이 아니라

JVM 스펙에 따라 정해진 역할을 하는 영역을 Method Area 라고 논리적 개념으로 설명하는 것이다.

(참고) Is Method area still present in Java 8?

Runtime Data Areas

Runtime Data Areas 의 공유 자원으로 Heap Area 와 Method Area 가 있다.

이는 모든 Thread 가 이 영역을 공유한다는 의미이며, 모든 Thread 가 공유하기 때문에 동기화 문제가 발생할 수 있다는 의미이다.

Heap Area

힙 영역은 JVM 에서 가장 중요한 메모리 영역이다.

실제 객체를 생성(메모리 할당) 및 저장하는 공간으로, JVM 이 시작될 때 생성된다.

다음과 같이 new 키워드를 사용해서 객체를 생성하면 JVM 이 객체의 인스턴스를 힙에 생성한다.

StringBuilder builder = new StringBuilder();

힙 영역에 생성된 객체와 배열은 스택 영역의 변수나 다른 객체의 필드에서 참조한다.

실행 중인 JVM 프로세스에는 단 하나의 Heap 영역만 있으며, GC(Garbage Collection) 의 대상이 되는 영역이다.

객체가 더 이상 사용되지 않거나 명시적으로 null 로 선언하면 의미 없는 객체가 되어 GC 의 대상이 된다.

Method Area

메서드 영역에는 클래스 코드, 클래스 이름, 부모 클래스 이름, 메서드, 생성자, 변수 정보 등 모든 클래스 수준 정보가 저장 된다.

이를 클래스와 클래스의 메타 데이터를 저장한다고 말한다.

메서드 영역에는 Runtime Constant Pool 이라는 집합이 존재한다.

리터럴(문자열, 정수 및 부동 소수점 상수) 및 필드, 메서드에 대한 심볼릭 레퍼런스*를 저장하며, 이후에 배울 Stack 의 Frame 에서 참조한다.

*심볼릭 레퍼런스란?

참조하는 대상의 이름. 사용 전에는 이름만 저장되어 있다.

클래스 접근 필요 시 클래스 로더가 Linking 하여 메모리 상의 실제 주소로 연결된다. (동적으로 로드)

이를 Resolution 이라고 부른다.

Constant Pool 을 확인하기 위해 다음과 같이 간단한 클래스를 생성해보자.

package ex;

public class Student {
    private int age = 29;

    public void study() {
        System.out.println("studying....");
    }
}

package ex;

public class School {
    public static void main(String[] args) {
        Student student = new Student();
        student.study();
    }
}

School 클래스를 역어셈블해보자.

javap -v [Class Name]

아래와 같이 Constant pool 을 포함한 클래스 파일의 여러 정보를 확인할 수 있다.

역어셈블링하여 확인한 School 클래스 파일의 Constant pool 은 다음과 같다.

Constant pool:
   #1 = Methodref          #2.#3          // java/lang/Object."<init>":()V
   #2 = Class              #4             // java/lang/Object
   #3 = NameAndType        #5:#6          // "<init>":()V
   #4 = Utf8               java/lang/Object
   #5 = Utf8               <init>
   #6 = Utf8               ()V
   #7 = Class              #8             // ex/Student
   #8 = Utf8               ex/Student
   #9 = Methodref          #7.#3          // ex/Student."<init>":()V
  #10 = Methodref          #7.#11         // ex/Student.study:()V
  #11 = NameAndType        #12:#6         // study:()V
  #12 = Utf8               study
  #13 = Class              #14            // ex/School
  #14 = Utf8               ex/School
  #15 = Utf8               Code
  #16 = Utf8               LineNumberTable
  #17 = Utf8               LocalVariableTable
  #18 = Utf8               this
  #19 = Utf8               Lex/School;
  #20 = Utf8               main
  #21 = Utf8               ([Ljava/lang/String;)V
  #22 = Utf8               args
  #23 = Utf8               [Ljava/lang/String;
  #24 = Utf8               student
  #25 = Utf8               Lex/Student;
  #26 = Utf8               SourceFile
  #27 = Utf8               School.java

#(해시) 로 참조하고 있는 상수 풀의 인덱스를 표시한다.

인덱스와 타입, 그리고 매핑하는 값을 가지고 있다.

#8 = Utf8               ex/Student

#8 을 보면 참조하는 대상의 이름을 문자열로 가지고 있다. 이를 심볼릭 레퍼런스를 저장한다고 한다.

이처럼 Constant pool 은 모든 타입, 필드, 메서드에 대한 심볼릭 레퍼런스를 저장하고 있기 때문에 자바 프로그램에서 중요한 역할을 한다.

다음으로는 Thread 마다 1개씩 존재하는 Java Stack, PC(Program Counter) Register, Native Method Stack 에 대해서 알아보자.

Thread 별로 메모리를 할당하기 때문에 동시성 문제에서 자유롭다.

Java Stack

각 Thread 에는 Thread 와 동시에 할당된 Java Stack 이 있다.

메서드 호출 시 필요한 수행 정보를 저장하는 역할로, 메서드 정보와 지역 변수, 매개변수, 연산 중 발생하는 임시 데이터를 저장한다.

기본 타입 변수는 스택 영역에 직접 값을 가지며, 참조 타입 변수는 힙 영역이나 메서드 영역의 객체 주소를 가진다.

스택 영역에서는 메서드 호출 시 필요한 정보를 저장하기 위해 Frame 을 사용한다.

메서드가 호출 될때마다 각각의 스택 프레임이 생성되는데, 각 프레임은 하나의 메서드에 대한 정보를 저장한다.

메서드를 호출할 때마다 프레임을 추가하고, 메서드가 종료되면 해당 프레임을 제거한다.

Java Stack 의 구조를 그림으로 표현하면 다음과 같다.

출처:https://8iggy.tistory.com/229

예시를 통해 확인해보자.

public class test {
    public static void main(String[] args) {
        int num1 = 1;
        int num2 = 2;
        int num3 = 3;

        num1 = num1 + num2 + num3;
    }
}

역어셈블링하여 바이트코드를 확인해보면 다음과 같다.

 0: iconst_1
 1: istore_1
 2: iconst_2
 3: istore_2
 4: iconst_3
 5: istore_3
 6: iload_1
 7: iload_2
 8: iadd
 9: iload_3
10: iadd
11: istore_1
12: return

한줄씩 설명하면 아래와 같다.

이렇게 바이트코드 0~5행까지 num1, num2, num3 을 Local Variable Array 에 저장하고

6행부터는 Local Variable Array 에서 값을 가져와서 연산을 수행한다.

메서드의 지역 변수는 Local Variables 라는 배열에 저장이 되고, 연산이 필요한 경우 Operand Stack(피연산자 스택)에 쌓아 연산 후 Local Variables 배열에 최종 값을 저장한다.

변수가 객체인 경우, Local Variables 에 Heap 에 저장된 인스턴스의 참조 값이 저장되게 된다.

PC Register

쓰레드가 각각의 메서드를 수행할 때, 각각의 명령어 주소값을 저장하는 공간이다.

쓰레드마다 PC Register 를 가지고 있으며, JVM 이 현재 수행 중인 명령어의 주소를 저장한다.

지금 실행하고 있는 메서드의 몇 번째 줄을 실행해야 하는지 나타낸다.

Native Method Stacks

Java 가 아닌 다른 언어로 작성 된 메서드를 위한 메모리 영역이다.

마치며

오늘은 JVM 의 메모리 구조 중에서도 Runtime Data Area 의 구성요소에 대해 자세하게 알아보았습니다.

다음 포스팅에는 Heap 의 구조과 GC 를 다루도록 하겠습니다.