실제로 우리가 간단하게 서버를 배포하는 시나리오를 생각해보자.
만약 서버가 뜨는데 30초가 걸린다고 하면 최소 30+@초만큼 다운타임(유저에게 서비스가 불가능한 시간)이 발생한다.
현대의 어플리케이션이라면 유저에게 최상의 경험을 제공해주기위해 이런 다운타임이 없는 무중단 배포를 지원해야한다.
이 글에서 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
21plugins {
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개의 요청밖에 처리하지 못할 것처럼 보인다.
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 키워드를 사용하는 이유를 살펴보기 전에 쓰레드를 왜 여러 개 사용하는지부터 알아보자.
이번 아이템은 모든 객체의 부모 클래스인 Object 클래스에 있는 메서드가 아니다.
아예 동떨어진 믹스인 인터페이스인 Comparable와 해당 인터페이스의 유일한 메서드인 compareTo에 대한 내용이다.
그럼에도 불구하고 이번 챕터인 ‘모든 객체의 공통 메서드’에 넣은 이유는 모든 객체에 유용하게 쓰일 수 있는 메서드이고
자바 플랫폼 라이브러리의 모든 값 클래스와 Enum에서 해당 인터페이스를 구현했기 때문이 아닐까 싶다.
또한 compareTo 메서드를 쓰는 자바 API들(Arrays, Collections, TreeSet, TreeMap 등등)이 있기 때문에
compareTo 메서드를 잘만 쓰면 좁살만한 노력으로 코끼리만 한 큰 효과를 누린다고 책에서 얘기하고 있으니 이 장을 주의 깊게 봐야한다.
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를 오버라이딩 하려면 세 가지 방법이 존재한다.내가 당신의 시간을 아껴주겠다.
그래도 공부 측면 등등에서 꼭 알아야하는 내용임에는 틀림이 없는 것 같다.
@AutoValue 어노테이션만 달아주면 끝이다.
Object 클래스는 인스턴스가 생성 가능한 Concrete class이지만 기본적으로 상속해서 사용하도록 설계됐다고 한다.
(그 이유는 모르겠지만… 그걸 찾으려면 또 이 장의 범위를 넘어서니 나중에 찾아보자.)
따라서 final이 아닌 메서드(equals, hashCode, toString, clone, finalize는)는 모두 메서드 오버라이딩을 염두하고 설계된 메서드이다.
따라서 해당 메서드를 오버라이딩 할 때는 각 메서드마다 지켜야할 규칙들이 존재한다.
이 규칙을 지키지 않았을 때 뻑나는 경우가 있다.
일반적인 클래스들(Collection Framework 등등)은 이러한 규칙들은 지켰겠지~ 하고 작성된 코드들이 많다.
따라서 위와 같은 규칙을 지키지 않은 채 오버라이딩을 한 클래스를 사용하면 제대로 동작하지 않을 가능성이 존재한다.
equals 메서드를 오버라이딩 할 경우는 거의 없다.
대부분 핵심 필드의 값이 일치하는지 파악하기 위해서 오버라이딩 할 것이다.
그런 경우를 제외하고는 대부분 기본적인 레퍼런스 값 비교만으로도 충분히 비교가 가능하기 때문이다.
equals 메서드를 오버라이딩 하는 건 그렇게 어렵지 않지만 몇가지 원칙이 있고, 글의 길이가 짧은 편도 아니고 얻는 수확이 크지 않다. (애초에 오버라이딩 할 일이 거의 없으니…)
그래서 지금 당장 오버라이딩을 해야한다! 싶을 때는 두 가지 방법이 있다.내가 당신의 시간을 아껴주겠다.
그래도 공부 측면 등등에서 꼭 알아야하는 내용임에는 틀림이 없는 것 같다.
@AutoValue 어노테이션만 달아주면 끝이다.
부끄럽게도 Java8에 나온 날짜와 시간 API를 제대로 모르고 계속해서 사용해왔다.
늦었지만 지금이라도 정리를 해봤다.
먼저 날짜와 시간 API는 JSR-310이라고도 불린다.
이걸 풀어서 설명하면 JCP(Java Community Process)에서 관리하는 JSR(Java Specification Requests)의 310번 째 Request(?)로
Date and Time API이다.
이 API는 현재 표준으로 자리잡았고, 날짜와 시간 관련 라이브러리인 Joda-Time의 창시자인 Joda도 이 API를 만드는데 동참했다.