1003 ~ 1009

1003 - DB 동시성 문제 해결 방법

동시성이란(Concurrency)?

사전적 의미는 하나의 CPU 코어에서 시간분할(Time sharing)을 통하여 여러 일을 처리하는 것 처럼 보여지게 하는 기법을 의미한다.
하지만, 대중적으로는 여러 요청이 동시에 동일한 자원(data)에 접근하고 수정하려는 것을 의미한다.

동시성 문제 해결방법

[ 비관적인 방법 ]

현재 수정하려는 데이터가 언제든 다른 요청에 의해 수정될 가능성을 고려하여 해당 데이터에 Lock을 거는 방식.
장점은 데이터의 무결성을 완벽히 지킬 수 있다. 수정할 데이터에 row level lock을 걸기 때문에 다른 요청에서 수정하려는 것은 불가능하다.
단점은 lock으로 인해 이후의 다른 요청은 대기상태로 빠진다. 기존의 lock의 transaction이 commit 또는 rollback으로 끝나면 대기하고 있떤 요청을 비로소 실행한다.
해당 방법은 서버의 성능에 따라 처리량이 결정되기 때문에 도입하기전 서비스의 최소 처리 tps에 부합하는지 확인해야한다.
이 방법은 세가지 방식으로 적용할 수 있다.

첫 번째는 DB에서 제공하는 데이터 Lock수준을 높이는 것이다. 일반적인 기본수준값인 Repeatable Read를 Serializer 이상의 수준으로 올린다. 강도 높은 락으로 완전한 일관성을 유지할 수 있다. 하지만, 이로인한 다른 요청들이 모두 취소가된다. 취소된 작업들은 재시도를 위한 처리가 반드시 필요하기 때문에 서비스에 적용하는것엔 현실성이 부족하다.

두 번째는 select for update 활용하여 명시적으로 lock을 잡을 수 있다. 하지만 lock을 잡는 구간이 길어져 성능에 심각한 영향을 준다. 극장예매와 같은 서비스가 아니라면 사용하지 않는것이 좋다.

마지막은 Data의 transaction의 write lock을 활용한다. 일반적으로 데이터를 수정할 때 write lock이 걸리고 transaction이 끝나야 lock이 풀리는 것을 이용한다. 데이터의 일관성을 유지할 수 있찌만 DB와 서버 성능에 따라서 서비스의 속도가 좌우된다.

[ 낙관적인 방법 ]

수정하려는 데이터는 나만 수정할 것이라는 낙관적인 생각의 방법이다. 테이블에 version이라는 숫자컬럼 또는 updated_at 이라는 시간컬럼을 만들어서 수정될 때마다 1씩 증가하거나, 현재시간으로 갱신하게 해준다. 값을 수정할떄 Version이 동일하면 수정이 가능해지고, 동일하지 않으면 수정에 실패한다.

장점으로는 모델에 컬럼을 하나 추가하면 구현이 비교적으로 쉽지만, 두개의 DB세션이 동일한 버전으로 수정하려고 하면 한 개의 세션에선 version conflict이 발생하여 affected row count가 0이 된다. 따라서 이 경우 요청을 재시도하도록 구현이 필요.

1004 - JAVA의 버전별 변화(JAVA SE 10 ~ 15)

[ Java SE 10 ]

2018년 3월 20일 발표된 버전. 일반 지원은 2018년 9월에 종료. var 키워드를 이용한 지역 변수 타입추론, 병렬 처리 가비지 컬렉션, 개별 스레드로 분리된 Stop-The-World, 루트 CA 목록 등이 추가. 또한 JDK의 레포지토리가 하나로 통합, JVM 힙 영역을 시스템 메모리가 아닌 다른 종류의 메모리에도 할당할 수 있게 되었다. 실험 기능으로 Java 기반의 JIT 컴파일러가 추가되었고, 이전 버전에서 Deprecated 처리된 API는 Java SE 10에서 모두 삭제되었다.

[ JAVA SE 11 ]

2018년 9월 25일에 발표된 버전. 일반 지원은 2023년 9월, 연장 지원은 2026년 9월에 종료 예정. 이클립스 재단으로 넘어간 Java EE가 JDK에서 삭제되고, JavaFX도 JDK에서 분리되어 별도의 모듈로 제공된다. Gloun이라는 업체가 JavaFX를 유지보수 중이므로 이곳에서 다운로드하면 된다. 람다 파라미터에 대한 지역 변수 문법, 엡실론 가비지 컬렉터, HTTP 클라이언트 표준화 등의 기능이 추가.

가장 커다란 변화는 바로 라이선스 부분. Java SE 11부터 Oracle JDK의 독점 기능이 오픈 소스 버전인 OpenJDK에 이식된다. 이는 다시 말해 Oracle JDK와 OpenJDK가 완전히 동일해진다는 뜻이다. Oracle JDK는 Java SE 11부터 LTS(장기 지원)버전으로 3년마다 출시되는데, 출시 후 5년 동안 오라클의 기술 지원이 제공되고 최대 3년까지 지원 기간을 연장할 수 있다. Oracle JDK는 이제 3년에 한 번 출시되니 자바의 실질적인 버전 업을 담당하는 것은 OpenJDK라 할 수 있다. OpenJDK는 기업들을 위한 기술 지원은 없고, 새로운 버전이 나오면 이전 버전에 대한 마이너 업데이트와 보안 업데이트는 중단된다.

Java 11과 함께 발표된 또 다른 소식은 Oracle JDK가 구독형 유료 모델로 전환된다는 점이다. 2019년 1월부터 오라클이 제공하는 모든 Oracle JDK는 유료화되며, 구독권을 구입하지 않으면 Oracle JDK에 접근 자체가 금지된다. 기존의 일반/연장 지원 서비스는 구독권에 포함되므로 별도의 서비스로는 제공되지 않습니다. 개인 사용자는 2021년 1월부터 비용을 지불해야 한다. 이 떄문에 많은 기업들이 Oracle JDK에서 발을 빼고 있으며, OpenJDK를 기반으로 한 다른 서드파티 JDK가 대안으로 떠오르고 있다. 대표적인 예로 Azul Systems에서 개발한 Zulu JDK는 오라클의 TCK(Technology Certification Kit) 인증을 받은 구현체이다. 개인과 기업 모두 무료로 사용 할 수 있고, 기술 지원에 한해서만 유료 서비스가 제공된다. 또 다른 대안으로는 AdoptOpenJDK가 있는데, AdoptOpenJDK는 HotStop VM대신 Eclipse OpenJ9를 탑재한 버전도 같이 제공하고 있다. 다만 아직 TCK 인증을 받지 않았기에 주의가 필요하다.

[ JAVA SE 12 ]

2019년 3월 19일 공개된 버전이다. 특징 중 하나로 문법적으로 Switch문을 확장한 것이 있다.

• AS-IS

switch (day) {  
    case MONDAY:  
    case FRIDAY:  
    case SUNDAY:  
        System.out.println(6);  
        break;    case TUESDAY:  
        System.out.println(7);  
        break;    case THURSDAY:  
    case SATURDAY:  
        System.out.println(8);  
        break;    case WEDNESDAY:  
        System.out.println(9);  
        break;
}

• TO-BE

switch (day) {  
    case MONDAY, FRIDAY, SUNDAY -> System.out.println(6);  
    case TUESDAY -> System.out.println(7);  
    case THURSDAY, SATURDAY -> System.out.println(8);  
    case WEDNESDAY -> System.out.println(9);  
}

이외에 가비지 컬렉터 개선, 마이크로 벤치마크 툴 추가, 성능 개선의 변경점이 있다.

[ JAVA SE 13 ]

2019년 9월 17일 공개된 버전이며, java 12에서의 스위치 개선을 이어 yield라는 예약어가 추가되었다.

var a = switch (day) {  
    case MONDAY, FRIDAY, SUNDAY:  
        yield 6;  
    case TUESDAY:  
        yield 7;  
    case THURSDAY, SATURDAY:  
        yield 8;  
    case WEDNESDAY:  
        yield 9;  
};

[ JAVA SE 14 ]

2020년 3월 18일 공개된 버전이다. 프리뷰 기능으로 instanceof의 패턴 매칭과 record라는 데이터 오브젝트 선언이 추가되었다. 그 외에 인큐베이터라는 패키징 툴(OS에 맞춘 실행파일 생성 기능) 추가 등이 있다.

• instanceof 패턴 매칭

if (!(obj instanceof String s)) {
	.. s.contains(..) ..
} else {
	.. s.contains(..) ..
}

• record 타입 지원

record Point(int x, int y) {}

[ JAVA SE 15 ]

2020년 9월 15일 공개된 버전.

• EdDSA 암호화 알고리즘 추가
• 패턴 매칭 (2차 미리보기, 상단 Java 14 참조)
• 스케일링 가능한 낮은 지연의 가비지 컬렉터 추가(ZGC)
• Solaris 및 SPARC 플랫폼 지원 제거
• 외부 메모리 접근 API (인큐베이팅)
• 레코드 (2차 미리보기, 상단 Java 14 참조)
• 클래스 봉인 (미리 보기)
  • 상속 가능한 클래스를 지정할 수 있는 봉인 클래스가 제공
  • 상속 가능한 대상은 상위 클래스 또는 인터페이스 패키지 내에 속해 있어야 한다

package wiki.namu.example.species;  
  
public sealed class Animal  
		Dog,  
	        wiki.namu.example.species.india.Monkey,  
            wiki.namu.example.species.sabana.Leopard  
{  
	// ...  
}

• 텍스트 블록

String html = """ 
				<html>
					<body> 
						<p>Hello, world</p>
					</body>
				</html> 
			""";

1005 - TCP와 UDP

TCP와 UDP는 TCP/IP의 전송계층에서 사용되는 프로토콜이다. 전송계층은 IP에 의해 전달되는 패킷의 오류를 검사하고 재전송 요구 등의 제어를 담당하는 계층이다.

TCP(Transmission Control Protocol)

전송을 제어하는 프로토콜
인터넷상에서 데이터를 메세지의 형태로 보내기 위해 IP와 함께 사용하는 프로토콜이다. 일반적으로 TCP와 IP를 함께 사용하는데, IP가 데이터의 배달을 처리한다면 TCP는 패킷을 추적 및 관리하게 된다. TCP는 연결형 서비스를 지원하는 프로토콜로 인터넷 환경에서 기본으로 사용한다.

[ 특징 ]

• 연결형 서비스로 가상 회선 방식을 제공한다. (패킷 전송을 위한 논리적 경로를 배정)
• 3-way handshaking과정을 통해 연결을 설정하고 4-way handshaking을 통해 해제한다.
• 흐름 제어 및 혼잡 제어를 한다.
• 높은 신뢰성을 보장한다. (Sequence Number, Ack)
• UDP보다 속도가 느리다.
• 전이중(Full-Duplex), 점대점(Point to Poin)방식이다.
• 서버와 클라이언트는 1대 1로 연결된다.
• 스트리밍 서비스에 불리하다. (손실된 경우, 재전송 요청)

[ 장점 ]

• 3-way handshaking과정은 목적지와 수신지를 확실히 하여 정확한 전송을 보장하기 위해서 세션을 수립하는 과정이다. TCP는 연결형 서비스로 신뢰성을 보장하기 때문에 3-way handshaking의 과정도 사용하는 것이고, 데이터의 흐름제어나 혼잡 제어와 같은 기능도 한다. 하지만 이러한 기능때문에 UDP보다 속도가 느리다.
• 통신의 신뢰성이 높다.

[ 단점 ]

• 데이터로 보내기전에 반드시 연결이 형성되어야 한다.
• 1:1 통신만 가능하다.
• 고정된 통신 경로가 최단선이 아닐경우 상대적으로 UDP보다 데이터 전송속도가 느리다.

UDP(User Datagram Protocol)

사용자 데이터그램 프로토콜
데이터를 데이터그램 단위로 처리하는 프로토콜이다. 여기서 데이터그램이란 독립적인 관계를 지니는 패킷이다.
TCP와 달리 UDP는 비연결형 프로토콜로 연결을 위해 할당되는 논리적 경로가 없다. 때문에 각각의 패킷은 다른경로로 전송되고, 각각의 패킷은 독립적인 관계를 지니게 되는데 이렇게 데이터를 독립적인 경로로 독립적으로 처리한다.
즉, UDP는 발신자가 데이터 패킷을 순차적으로 보내더라도 이 패킷들은 서로 다른 통신 선로를 통해 전달될 수 있다. 먼저 보낸 패킷이 느린 선로를 통해 전송될 경우 나중에 보낸 패킷보다 늦게 도착할 수 있으며 최악의 경우 유실될 수도 있다. UDP는 중간에 패킷이 유실이나 변조가 되어도 재전송을 하지 않는다.

[ 특징 및 장점 ]

• 비연결형 서비스로 데이터크램 방식이다. (연결을 설정하고 해제하는 과정이 존재하지 않는다.)
• 정보를 주고 받을때 정보를 보내거나 받는다는 신호절차가 없다.
• UDP헤더의 CheckSum 필드를 통해 최소한의 오류만 검출한다.
• TCP보다 속도가 빠르다.
• 신뢰성보다는 연속성이 중요한 서비스(실시간 스트리밍 서비스)에서 자주 사용.
• 소켓 대신 IP주소를 기반으로 데이터를 전송.
• 서버와 클라이언트 구분이 없다. (1:1, 1:N, N:M 등으로 연결가능)

[ 단점 ]

• 신뢰성이 낮다.
• 흐름제어(flow control)가 없어서 패킷이 제대로 전송되었는지, 오류가 없는지 확인할 수 없다.

1007 - 자바에서 동시성 문제를 해결하는 3가지 키워드

1. synchronized

synchronized 키워드를 통해 해당 블럭의 액세스를 동기화할 수 있다.
간단히 말해서 synchronized가 선언된 블럭에는 동시에 하나의 스레드만 접근할 수 있다.

• 예제

public class SomeClass {
    // 메서드 전체에 동기화 적용
    public synchronized void foo() { 
        /* critical section */
    }

    // 내부에 동기화 블럭 생성
    public void bar() {
        synchronized (this) {
            /* critical section */
        }
    }
}

// 클래스 내부의 전역 메서드에서 동기화 블럭을 생성하는 방법
public class SomeClass {
    public static void syncMethod() {
        synchronized (SomeClass.class) {
            /* critical section */
        }
    }
}

• synchronized method
  • 동기화를 시키고 싶은 클래스의 메소드에 synchronized 키워드를 붙이면 되고, synchronized method는 인스턴스 단위의 synchronized 키워드가 붙은 메소드에 대해서만 lock 공유한다.
• static synchronized method
  • static synchronized method 는 인스턴스가 아닌 클래스 단위로 lock을 공유하며, synchronized method와 동일하게 함수 간의 동기화가 발생한다. 만약 synchronized method과 함께 사용하게 되면 인스턴스 락과 클래스 락은 공유가 안되기 때문에 동기화 이슈가 발생할 수 있다는 점을 주의해야 한다.
• synchronized block
  • synchronized(this) : 여러 스레드가 들어와 서로 다른 block을 호출해도 this를 사용해 자신에 lock을 걸었기 때문에 기다려야 한다.
  • synchronized(Object) : block마다 서로 다른 lock을 걸리게해 훨씬 효율적인 코드를 작성할 수 있다.
• static synchronized block
  • 클래스 단위로 lock을 공유하나 lock객체를 지정하고 block으로 범위를 한정지을 수 없다.

2. volatile

JVM에서 스레드는 실행되고 있는 CPU 메모리 영역에 데이터를 캐싱한다(CPU Cache). 따라서 멀티 코어 프로세서에서 다수의 스레드가 변수 a를 공유하더라도 캐싱된 시점에 따라 데이터가 다를 수 있으며, 서로 다른 코어의 스레드는 데이터 값이 불일치하는 문제가 생긴다.
임의의 데이터를 갱신해 주지 않는 이상 캐싱 된 데이터가 언제 갱신되는지 또한 정확히 알 수 없다.
이런 경우 volatile키워드를 사용하여 CPU 메모리 영역에 캐싱된 값이 아니라 항상 최신의 값을 가지도록 메인 메모리 영역에서 값을 참조하도록 할 수 있다. -> 즉, 동일 시점에 모든 스레드가 동일한 값을 가지도록 동기화한다.

public volatile long count = 0;

하지만 volatile을 통해 모든 동기화 문제가 해결되는건 아니다. 원자성이 보장되지 않는 경우 동시성 문제는 동일하게 발생한다.(단지 멀티 코어에서의 모든 스레드가 캐시 없이 최신의 값을 보게 할뿐)

Atomic 클래스

앞에서 설명한 두 가지 키워드 synchronized, volatile만으로는 동시성 문제를 깔끔하게 해결할 수 없다.
자바에서는 위 문제들을 해결하기 위해, 비-원자적 연산에서도 동기화를 빠르고 쉽게 이용하기 위한 클래스 모음을 제공한다.

java.util.concurrent.* (대표적으로 컬렉션, Wrapper 클래스 등이 있다.)

• java.util.concurrent.atomic.AtomicLong

public class AtomicLong extends Number implements java.io.Serializable {
	
    private volatile long value; // volatile 키워드가 적용되어 있다.
	
    public final long incrementAndGet() { // value 값을 실제로 증가시키는 메서드
        return U.getAndAddLong(this, VALUE, 1L) + 1L;
    }
}

• jdk.internal.misc.Unsafe

public final class Unsafe {
    // 메모리에 저장된 값과 CPU에 캐시된 값을 비교해 동일한 경우에만 update 수행
    public final long getAndAddLong(Object o, long offset, long delta) {
        long v;
        do {
            v = getLongVolatile(o, offset);
        } while (!weakCompareAndSetLong(o, offset, v, v + delta)); // CAS 알고리즘 (JNI 코드로 이루어져 있다.)
        return v;
    }
}

Non-Blocking 임에도 동시성을 보장하는 이유는 CAS(Compare-and-swap) 알고리즘을 이용하기 때문이다.

• valatile 키워드를 이용하면서 현재 스레드에 저장된 값과 메인 메모리에 저장된 값을 비교한다.
  • 일치하지 않는 경우 새로운 값으로 교체(thread-safe 한 상태이므로 로직 수행)
  • 일치하지 않는 경우 실패 후 재시도(thread-safe 하지 않은 상태였으므로 재시도)

성능비교 및 마무리

• Blocking(synchronized)

private static long startTime = System.currentTimeMillis();
private static int maxCnt = 1000;
private static long count = 0;

@Test
void threadNotSafe() throws Exception {
    for (int i = 0; i < maxCnt; i++) {
        new Thread(this::plus).start();
    }

    Thread.sleep(2000); // 모든 스레드가 종료될때 까지 잠깐 대기
    Assertions.assertThat(count).isEqualTo(maxCnt);
}

public synchronized void plus() {
    if (++count == maxCnt) {
        System.out.println(System.currentTimeMillis() - startTime);
    }
    try {
        Thread.sleep(1);
    } catch (InterruptedException e) {
    }
}

평균 1300ms 정도 소요되었다. (Blocking 연산에서 1000개의 스레드가 각각 1ms의 추가 딜레이를 가지기 때문)

• Non-Blocking (AtomicLong)

private static long startTime = System.currentTimeMillis();
private static int maxCnt = 1000;
private static AtomicLong count2 = new AtomicLong();

@Test
void threadNotSafe2() throws Exception {
    for (int i = 0; i < maxCnt; i++) {
        new Thread(this::plus2).start();
    }

    Thread.sleep(2000); // 모든 스레드가 종료될때 까지 잠깐 대기
    Assertions.assertThat(count2.get()).isEqualTo(maxCnt);
}

public void plus2() {
    if (count2.incrementAndGet() == maxCnt) {
        System.out.println(System.currentTimeMillis() - startTime);
    }
    try {
        Thread.sleep(1);
    } catch (InterruptedException e) {
    }
}

평균 140ms 정도 소요되었다. (Non-Blocking 연산에서 1ms의 추가 딜레이는 큰 의미가 없다.)

임의로 딜레이를 주었기 때문에 드라마틱하게 차이가난다

1008 - 자바 설계 결함

1. Generics의 타입을 Runtime에 활용할 수 없다.

• 제네릭이란?

  • 자바의 제네릭이란 클래스와 함수등에 type을 마치 매개변수 값처럼 넣어 줌으로서 컴파일 타임에 미리 타입오류를 검출 할 수 있도록 하는 개념.

• 제네릭의 한계

  • 제네릭을 활용해 컴파일 타임에 타입 체크를 하고 나면 제네릭 인자로 넘겨져 온 타입은 Type erasure라는 절차를 통해 제거된다. 따라서 인자로 넘겨진 타입은 Runtime에서는 활용 될 수 없다.

ArrayList<Integer> li = new ArrayList<Integer>();
ArrayList<Float> lf = new ArrayList<Float>();
if (li.getClass() == lf.getClass()) { // evaluates to true
    System.out.println("Equal");
}

• 위와 같은 코드는 제네릭 타입인자 값이 다르지만 같은 클래스로 인정된다. Runtime에는 타입이 지워지기 때문이다.

public class MyClass<E> {
    public static void myMethod(Object item) {
        if (item instanceof E) {  //Compiler error
            ...
        }
        E item2 = new E();   //Compiler error
        E[] iArray = new E[10]; //Compiler error
    }
}

• 또한 다음과 같은 코드에서 instanceof. new등의 연산자를 활용할 수 없는 이유도 Type erasure 때문이다.

2. Unsigned integer types가 없다.

• 자바에는 기본적으로 c, c++등에서 존재하는 unsigned 자료형이 존재하지 않는다.
• 암호학과 같이 매우 큰 양의 정수를 활용해 다양한 처리를 하는 분야에서 사용하기에 부적합할 수 있다.
• 2의 보수 표현이나 비트관점에서의 표현을 잘 이해하고 사용하려는 노력을 기울인다면 해결할 수 있는 문제이기는 하지만 개발할 때의 추가적인 노력이 필요하다.

3. Operator everloading을 할 수 없다.

• 자바에서는 연산자 오버로딩을 허용하지 않는다.(예외적으로 String의 +, += 연산자만이 유일하게 존재한다.)
• 수학적인 내용의 객체들에 대해서 가독성을 떨어뜨리고 활용하는데에 불편한 점이 있다.

4. 배열 크기가 2^31으로 제한된다.

• 메모리등의 문제가 아니라 배열자체의 크기를 int자료형으로 정의하기로 되어있기 때문에 2^31보다 큰 배열은 정의할 수 없다.

5. primitives type과 Array가 클래스와 다르게 취급됨.

• 다른 클래스들과 다르게 원시값과 배열은 다른 방식의 문법이 활용되는데 언어를 익히거나 활용하는점에서 비효율을 생선한다.

1009 - Jackson ObjectMapper

@Getter
@Setter
@NoArgsConstructor
public class Cat {
    private String name;

    public Cat(String name) {
        this.name = name;
    }
}

• Object to Json

ObjectMapper objectMapper = new ObjectMapper();

Cat cat = new Cat("kitty");
String catString = objectMapper.writeValueAsString(cat);
System.out.println("catString : " + catString);

--- output ---
catString : {"name":"kitty"}

• Json to Object

String json = "{\"name\":\"kitty\"}";
Cat cat2 = objectMapper.readValue(json, Cat.class);
System.out.println("cat2 name :  " + cat2.getName());

--- output ---
cat2 name :  kitty

• Json to Jackson JsonNode

JsonNode jsonNode = objectMapper.readTree(json);
String name = jsonNode.get("name").asText();
System.out.println("Tree cat2 name : " + name);

--- output ---
Tree cat2 name : kitty

• Json List to List

String jsonList = "[{\"name\":\"kitty\"},{\"name\":\"kitty2\"}]";
List<Cat> cats = objectMapper.readValue(jsonList, new TypeReference<List<Cat>>() {});
for (Cat catElement : cats) {
    System.out.println("catElement : " + catElement.getName());
}

--- output ---
catElement : kitty
catElement : kitty2