오늘도 끄적끄적

들어가기에 앞서

이 글에서 Docker와 Spring Boot, Gradle에 대한 기본적인 지식은 있다고 판단하고 설명한다.
프로젝트는 spring-boot-docker-demo 저장소에서 단계별로 브랜치를 확인해보면 된다.
이해를 돕기 위해 docker image tag 단위로 branch를 땄다.

프로젝트의 build.gradle은 아래와 같다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

plugins {
    id 'org.springframework.boot' version '2.1.4.RELEASE'
    id 'java'
}

apply plugin: 'io.spring.dependency-management'

archivesBaseName = 'demo'
group = 'com.example'
version = '0.0.1-SNAPSHOT'
sourceCompatibility = '11'

repositories {
    jcenter()
}

dependencies {
    implementation 'org.springframework.boot:spring-boot-starter-webflux'
    testImplementation 'org.springframework.boot:spring-boot-starter-test'
    testImplementation 'io.projectreactor:reactor-test'
}

기본적으로 SpringMVC에서 많이 사용하는 WAS인 Tomcat의 경우에는 기본적으로 쓰레드 풀의 갯수가 200개이고,
Jetty의 경우에는 기본적으로 minimum 8개에서 maximum 200개로 설정돼있다.
쓰레드 생성 비용은 비싸므로(오래 걸리므로) 미리 생성해서 ThreadPool에 쌓아놓는 것이다.
여기서 말하는 Thread는 Green Thread vs Native Thread에서 얘기하다 싶이 Native Thread(OS에서 관리하는 Thread)이다.
이 말은 동시에 요청을 최대 200개까지 처리 가능하단 얘기이다.

그에 반해 Webflux는 core * 2의 Thread만을 생성한다.
SpringMVC에 비해 턱없이 모자란 쓰레드 갯수이고 그럼 싱글 코어의 경우에는 동시에 2개의 요청밖에 처리하지 못할 것처럼 보인다.

SpringMVC는 어떻게 동작하는가?

1. 요청이 들어오면 ThreadPool에서 Thread를 하나 사용한다.
2. 그러다 I/O(File I/O, Network I/O 등등)가 발생하면 CPU를 block 시킨다. (idle 상태에 빠진다.)
3. 이 때 다른 요청이 들어오면 ThreadPool에서 Thread를 하나 사용한다.
4. 이런 식으로 쓰레드를 돌아가면서 요청을 처리하고 block이 풀리면 작업을 이어나간다.

Green Thread

Green Thread는 우리가 알고 있는 쓰레드를 흉내낸 짝퉁 쓰레드이다.
Green Thread는 VM(Virtual Machine)이나 Library 등등에서 관리되며 개발자가 통제할 수도 있어서 user-level 쓰레드라고도 불린다.
하지만 Green Thread는 Many to One(Many는 쓰레드, One은 CPU) 모델로 설계된 쓰레드이다.
따라서 CPU Core가 하나인 환경일 때 설계된 쓰레드이다보니 아무리 Green Thread가 많아도 Native Thread는 단 한 개 뿐이 만들어지지 않는다.
Native Thread가 하나라는 건 CPU를 하나 밖에 사용하지 못한다는 뜻이다.
따라서 CPU가 여러 개인 멀티 코어 환경에서는 그 장점을 전혀 살리지 못한다.

싱글 코어 환경에서는 동시에 여러 작업을 잘 수행하던 Green Thread는 그럼 단점만이 존재하는 걸까?
아니다.
싱글 코어 환경에서 네이티브 쓰레드를 10개 사용할 때와 그린 쓰레드를 10개 사용할 때를 비교해보자.
네이티브 쓰레드를 10개 사용하면 네이티브 쓰레드가 10개 생성된다.
그린 쓰레드를 10개 사용하면 네이티브 쓰레드는 한 개만 생성된다.
CPU 입장에서는 10개의 네이티브 쓰레드를 사용하는 것보다 한 개의 네이티브 쓰레드만 사용하는 그린 쓰레드 쪽이 성능 이슈가 훨씬 잘 나온다.
이유는 멀티 쓰레드 환경에서는 공유 자원의 동기화 문제가 매우 중요하다.
동기화가 제대로 이루어지지 않는다면 프로그램은 치명적 오류를 유발한다.
하지만 그린 쓰레드 환경에서는 네이티브 쓰레드가 1개 뿐이니 동기화할 공유 자원이 없게 된다.

따라서 그린 쓰레드가 싱글 쓰레드 환경에서는 더 좋은 성능을 발휘하게 된다.
하지만 자바 환경에서는 멀티 코어 환경에서 그 강점을 발휘하지 못하기 때문에 자바 3부터 Native Thread로 전부 바뀌었다.

synchronized 키워드를 사용하는 이유를 살펴보기 전에 쓰레드를 왜 여러 개 사용하는지부터 알아보자.

쓰레드를 여러 개(멀티 쓰레딩) 사용하는 이유

1. CPU가 I/O(파일, 네트워크 등등) 작업에 의해 Blocking 돼서 놀고 있을 때
   만약 DB를 호출하는 작업(네트워크 I/O)이 있다고 치자.
   I/O가 발생하면 기본적으로 CPU는 Block된다. (idle 상태에 빠져 놀고 있다.)
   이렇게 CPU가 놀고 있을 때 다른 쓰레드가 CPU를 점유한다면 CPU는 더 이상 놀지 않게 된다.
   이렇게 CPU의 병목을 줄이다보면 성능을 개선할 수 있다.
2. 시분할 다중화를 통해 동시에 여러 작업이 처리되게 끔 보이게 할 때
   문서 작성을 하면서 동시에 웹 브라우저에서 파일을 다운로드 받을 수 있는 행위는 바로 CPU에서 쓰레드를 돌아가며 작업을 처리하기 때문이다.
   만약 파일 다운로드가 다 끝나야지만 문서 작성을 할 수 있다고 하면 얼마나 불편하겠는가?
   물론 그렇다고 해서 진짜 동시에 여러 작업이 수행되는 게 아니라 사람이 체감 못할 정도로 시간을 쪼개서 작업을 수행하는 것이다.

멀티 쓰레드 프로그래밍을 할 때 생기는 문제

이번 아이템은 모든 객체의 부모 클래스인 Object 클래스에 있는 메서드가 아니다.
아예 동떨어진 믹스인 인터페이스인 Comparable와 해당 인터페이스의 유일한 메서드인 compareTo에 대한 내용이다.
그럼에도 불구하고 이번 챕터인 ‘모든 객체의 공통 메서드’에 넣은 이유는 모든 객체에 유용하게 쓰일 수 있는 메서드이고
자바 플랫폼 라이브러리의 모든 값 클래스와 Enum에서 해당 인터페이스를 구현했기 때문이 아닐까 싶다.
또한 compareTo 메서드를 쓰는 자바 API들(Arrays, Collections, TreeSet, TreeMap 등등)이 있기 때문에
compareTo 메서드를 잘만 쓰면 좁살만한 노력으로 코끼리만 한 큰 효과를 누린다고 책에서 얘기하고 있으니 이 장을 주의 깊게 봐야한다.

Comparable

Comparable은 믹스인 인터페이스이다.
그럼 이 믹스인 인터페이스가 제공하는 선택적 기능은 무엇일까?
바로 인스턴스 사이에 순서를 비교해주는 기능을 제공해준다.

규약

Object 클래스는 인스턴스가 생성 가능한 Concrete class이지만 기본적으로 상속해서 사용하도록 설계됐다고 한다.
(그 이유는 모르겠지만… 그걸 찾으려면 또 이 장의 범위를 넘어서니 나중에 찾아보자.)
따라서 final이 아닌 메서드(equals, hashCode, toString, clone, finalize는)는 모두 메서드 오버라이딩을 염두하고 설계된 메서드이다.
따라서 해당 메서드를 오버라이딩 할 때는 각 메서드마다 지켜야할 규칙들이 존재한다.
이 규칙을 지키지 않았을 때 뻑나는 경우가 있다.
일반적인 클래스들(Collection Framework 등등)은 이러한 규칙들은 지켰겠지~ 하고 작성된 코드들이 많다.
따라서 위와 같은 규칙을 지키지 않은 채 오버라이딩을 한 클래스를 사용하면 제대로 동작하지 않을 가능성이 존재한다.

믹스인 인터페이스

Cloneable이 믹스인 인터페이스라고 책에서 소개하고 있는데 그럼 믹스인 인터페이스는 뭔지부터 살펴보도록 하자.
아이템 20: 추상 클래스 보다는 인터페이스를 우선하라(130P)를 보면 다음과 같이 정의하고 있다.

믹스인이란 클래스가 구현할 수 있는 타입을 말한다.
믹스인을 구현한 클래스에 원래의 ‘주된 타입’ 외에도 특정 선택적 행위를 제공한다고 선언하는 효과를 준다.

Object 클래스는 인스턴스가 생성 가능한 Concrete class이지만 기본적으로 상속해서 사용하도록 설계됐다고 한다.
(그 이유는 모르겠지만… 그걸 찾으려면 또 이 장의 범위를 넘어서니 나중에 찾아보자.)
따라서 final이 아닌 메서드(equals, hashCode, toString, clone, finalize는)는 모두 메서드 오버라이딩을 염두하고 설계된 메서드이다.
따라서 해당 메서드를 오버라이딩 할 때는 각 메서드마다 지켜야할 규칙들이 존재한다.
이 규칙을 지키지 않았을 때 뻑나는 경우가 있다.
일반적인 클래스들(Collection Framework 등등)은 이러한 규칙들은 지켰겠지~ 하고 작성된 코드들이 많다.
따라서 위와 같은 규칙을 지키지 않은 채 오버라이딩을 한 클래스를 사용하면 제대로 동작하지 않을 가능성이 존재한다.

들어가기에 앞서…

equals 메서드와 마찬가지로 hashCode를 오버라이딩 할 경우는 거의 없다.
대부분 hashCode를 쓰는 쪽은 HashMap, HashSet 등등이다.
이 마저도 키에다가 equals를 오버라이딩 한 클래스를 사용할 때이다.
실무에서 대부분 키로 String, Integer를 쓰지, 해당 클래스를 써본 적은 한 번도 없다.
(물론 특수한 경우에는 존재할 수도 있지만, 아주 특수할 것이다.)
따라서 이런 아주 특수한 경우를 제외하고는 딱히 hashCode를 오버라이딩 할 이유가 없으니 이 글도 딱히 읽을 필요도 없다.
그래도 혹여나 실무에서 당장 hashCode를 오버라이딩 하려면 세 가지 방법이 존재한다.
내가 당신의 시간을 아껴주겠다.
그래도 공부 측면 등등에서 꼭 알아야하는 내용임에는 틀림이 없는 것 같다.

1. 구글에서 만든 AutoValue 사용하기. (권장)
   아주 사용하기가 간단하다.
   바로 클래스 위에 @AutoValue 어노테이션만 달아주면 끝이다.
   (물론 equals, hashCode, toString 메서드까지 다 오버라이딩 해준다.)
   클래스가 변경돼도 hashCode 쪽 소스코드를 수정할 필요가 없다.
   얘는 자바 6부터 지원한다.
2. IDEA가 생성해준 소스 코드 사용하기.
   여러가지 규칙을 직접 찾아보며 구현하기 귀찮으니까 생성해주는 코드를 사용하면 된다.
   인텔리제이 IDEA가 생성한 코드니 신뢰하고 써도 될 것이다.
   단점으로 클래스가 변경될 때마다 hashCode 쪽 소스도 넣어줘야해서 귀찮다.
3. 직접 구현하기
   이 글을 보고 직접 구현해보면 될 것 같다.

Object 클래스는 인스턴스가 생성 가능한 Concrete class이지만 기본적으로 상속해서 사용하도록 설계됐다고 한다.
(그 이유는 모르겠지만… 그걸 찾으려면 또 이 장의 범위를 넘어서니 나중에 찾아보자.)
따라서 final이 아닌 메서드(equals, hashCode, toString, clone, finalize는)는 모두 메서드 오버라이딩을 염두하고 설계된 메서드이다.
따라서 해당 메서드를 오버라이딩 할 때는 각 메서드마다 지켜야할 규칙들이 존재한다.
이 규칙을 지키지 않았을 때 뻑나는 경우가 있다.
일반적인 클래스들(Collection Framework 등등)은 이러한 규칙들은 지켰겠지~ 하고 작성된 코드들이 많다.
따라서 위와 같은 규칙을 지키지 않은 채 오버라이딩을 한 클래스를 사용하면 제대로 동작하지 않을 가능성이 존재한다.

들어가기에 앞서…

equals 메서드를 오버라이딩 할 경우는 거의 없다.
대부분 핵심 필드의 값이 일치하는지 파악하기 위해서 오버라이딩 할 것이다.
그런 경우를 제외하고는 대부분 기본적인 레퍼런스 값 비교만으로도 충분히 비교가 가능하기 때문이다.
equals 메서드를 오버라이딩 하는 건 그렇게 어렵지 않지만 몇가지 원칙이 있고, 글의 길이가 짧은 편도 아니고 얻는 수확이 크지 않다. (애초에 오버라이딩 할 일이 거의 없으니…)
그래서 지금 당장 오버라이딩을 해야한다! 싶을 때는 두 가지 방법이 있다.
내가 당신의 시간을 아껴주겠다.
그래도 공부 측면 등등에서 꼭 알아야하는 내용임에는 틀림이 없는 것 같다.

1. 구글에서 만든 AutoValue 사용하기. (권장)
   아주 사용하기가 간단하다.
   바로 클래스 위에 @AutoValue 어노테이션만 달아주면 끝이다.
   (물론 equals, hashCode, toString 메서드까지 다 오버라이딩 해준다.)
   클래스가 변경돼도 hashCode 쪽 소스코드를 수정할 필요가 없다.
   얘는 자바 6부터 지원한다.
2. IDEA가 생성해준 소스 코드 사용하기.
   사람이라면 실수를 하게 되니 IDE의 도움을 절실히 원하게 된다.
   하지만 클래스가 변하는 경우에 equals 코드도 계속해서 변경해줘야하니 구찮다…
   또 잘 짰는지 테스트 코드도 짜야하고… 테스트 코드도 변경해야하고…

부끄럽게도 Java8에 나온 날짜와 시간 API를 제대로 모르고 계속해서 사용해왔다.
늦었지만 지금이라도 정리를 해봤다.

들어가기에 앞서

먼저 날짜와 시간 API는 JSR-310이라고도 불린다.
이걸 풀어서 설명하면 JCP(Java Community Process)에서 관리하는 JSR(Java Specification Requests)의 310번 째 Request(?)로
Date and Time API이다.

이 API는 현재 표준으로 자리잡았고, 날짜와 시간 관련 라이브러리인 Joda-Time의 창시자인 Joda도 이 API를 만드는데 동참했다.

GMT(Greenwich Mean Time) vs. UTC(Coordinated Universal Time)

세계 표준 시간 관련해서 위 두 키워드가 자주 나오길래 구글에서 검색해보았다.

There is no time difference between Greenwich Mean Time and Coordinated Universal Time.
6:13 AM Tuesday, Greenwich Mean Time (GMT) is 6:13 AM Tuesday, Coordinated Universal Time (UTC)

둘의 차이점이 없다고 한다.
그래서 다른 사이트를 뒤져보았다.