Tech Log 🛠️

JVM이란?

자바를 가지고 코딩을 하는 사람은 한번 쯤 JVM 이란 단어를 들어왔을 것이다.

이 JVM은 컴퓨터와의 소통을 도와주는데, 어떤 식으로 소통을 도와주는 지 단계별로 살펴보자

먼저 우리가 코딩을 하고 컴파일러를 통해서 컴파일하면 .class 파일이 생성된다.

현재 이 클래스 파일은 기계어가 아닌 바이트 코드로 되어있다.

바이트 코드란 무엇일까?

JVM이 이해할 수 있는 언어로 변환된 자바 소스코드이다.

언제 어디서든 운영체제에 관계없이 JVM 위에서 실행될 수 있다.

예를 들어 아래의 코드는

System.out.println("Hello World");

다음과 같은 바이트 코드를 가진다.

// class version 61.0 (61)
// access flags 0x21
public class Main {

  // compiled from: Main.java

  // access flags 0x1
  public <init>()V
   L0
    LINENUMBER 8 L0
    ALOAD 0
    INVOKESPECIAL java/lang/Object.<init> ()V
    RETURN
   L1
    LOCALVARIABLE this LMain; L0 L1 0
    MAXSTACK = 1
    MAXLOCALS = 1

  // access flags 0x9
  public static main([Ljava/lang/String;)V
   L0
    LINENUMBER 10 L0
    GETSTATIC java/lang/System.out : Ljava/io/PrintStream;
    LDC "hello world"
    INVOKEVIRTUAL java/io/PrintStream.println (Ljava/lang/String;)V
   L1
    LINENUMBER 11 L1
    RETURN
   L2
    LOCALVARIABLE args [Ljava/lang/String; L0 L2 0
    MAXSTACK = 2
    MAXLOCALS = 1
}

이렇게 바이트 코드로 변환 된 클래스 파일을 JVM에게 전달한다.

JVM은 이 형식의 파일을 가지고 있다가 필요할 때 기계어로 번역을 해서 제공한다.

즉 JVM은 컴파일러와 컴퓨터 사이에 통역가 같은 역할을 해준다고 보면 된다.

기존 c,c++ 컴파일러와는 뭐가 다를까?

근데 하나 의문점이 생겼다.

다른 언어들도 마찬가지로 문장으로 코딩을 하는데 왜 자바만 JVM이란 것을 사용할까?

printf("Hello World");

분명 c언어도 다음과 같이 코딩을 하는데 c언어도 JVM 같은 것을 사용할까?

결론은 “아니다”

이는 언어가 추구하는 방식과 컴파일 방식의 차이 때문이다.

c나 c++ 같은 언어들은 소스코드를 기계가 바로 알아들을 수 있는 바이너리 코드로 번역해준다.

여기서 문제가 하나 있는데 모든 컴퓨터 운영체제들이 같은 언어를 쓰는 것이 아니란 거다.

이로 인해 맥에서 컴파일한 파일이 윈도우나 리눅스에서는 안 돌아가는 문제가 생긴다.

왜냐하면 c나 c++은 각 머신에 맞는 기계어로 바로 컴파일을 해준다.

속도 면에서는 빠를 지 몰라도 다른 환경과의 호환성을 떨어진다.

하지만 JVM은 WORA 라는 철학에 기반을 두고 만들어졌다.

*WORA

Write Once Run Anywhere

한번 쓰고 어디든 돌아간다.

이런 특징 덕분에 자바는 운영체제 관계없이 동일하게 실행할 수 있다.

JRE , JDK 와의 관계

JVM과 이름이 비슷한 JRE,JDK는 어떤 관계일까?

결론 적으로 말하면 JVM이 제일 작고 서로 포함되는 관계이다.

아래 그림을 보자

JVM은 위에서 설명한대로 바이트코드를 기계어로 바꿔준다.

JRE는 런타임에 필요한 여러 라이브러리 , 파일들을 포함한다.

JDK는 그 외 개발에 필요한 디버깅 , 컴파일 같은 기능들을 제공한다.

JVM 특징 정리

• 스택 기반의 가상 머신이다.
• 심볼릭 레퍼런스
  • 객체를 참조할 때 메모리 주소를 참조하는 게 아닌, 이름으로 참조한다.

• 가비지 컬렉션
  • 더 이상 할당되지 않는 데이터의 메모리를 해제해준다.

• 기본 자료형을 명확하게 정의하여 플랫폼 독립성 보장
  • 기본 자료형을 명확하게 정의하여 호환성을 유지하고 플랫폼 독립성을 보장한다.

• 네트워크 바이트 오더
  • 빅 엔디안 바이트 주소를 사용해서 통신을 한다.

빅 엔디안 표기법이란?

0x12 0x34 0x56 0x78 과 같이 낮은 주소부터 높은 주소 순으로 표기하는 방식

JVM 명세

JVM 공식 문서를 보면 다음과 같이 나와있다.

To implement the Java Virtual Machine correctly, you need only be able to

read the class file format and correctly perform the operations specified therein. Implementation details that are not part of the Java Virtual Machine's specification would unnecessarily constrain the creativity of implementors.

요약을 해보면 , 구현자의 창의성을 저해할 수 있기 때문에 기본적인 명세를 제외한 세세한 부분은 정하지 않았다는 것이다.

흔히 행동만 추상화 해두고 구현 책임은 벤더사들에게 맡긴 거라고 볼 수 있다.

그 결과 무수한 JVM 벤더사들이 구현을 시작하였고 현재도 많은 JVM이 사용되고 있다.

ex) Oracle 의 핫스팟 , IBM의 Open J9 등등 ..

JVM 동작과정

앞서 JVM이 대략 무엇인지 알아보았으면 지금부터는 구체적인 동작과정을 알아볼 것이다.

JVM 구조

전체적인 동작 방식

JVM의 종류에 따라 상세한 방식은 살짝 다를 수 있지만, 전반적으로 다음과 같은 과정을 거친다.

1. 자바 코드를 바이트 코드로 컴파일한다.
2. 컴파일 된 바이트 코드를 클래스 로더에 전달한다.
3. 해당 클래스가 필요할 때 클래스 로더가 런타임 데이터 영역에 전달한다.
4. 실행 엔진이 해당 클래스 메소드를 실행 시킨다.

클래스 로더

클래스 로더의 구조

• 부트스트랩 클래스 로더
  • JVM을 구동시키기 위한 필수 라이브러리들을 탑재하고 있다.
  • 가장 초기에 실행되며 , 운영체제에 맞는 네이티브 코드로 쓰여있다.

• 익스텐션 클래스 로더
  • 자바 클래스의 핵심 라이브러리들을 탑재한다.

• 시스템 클래스 로더(Application ClassLoader)
  • 개발자들이 작성한 클래스 파일들을 탑재한다.
  • 이것을 상속하여 사용자 정의 클래스 로더를 구현할 수 있다.

요청이 들어왔을 때 모든 클래스 로더에 해당 클래스가 없을 시 ,

ClassNotFoundException 예외를 반환한다.

클래스를 로드하는 과정

클래스 어떻게 어떻게 클래스를 로드하는 지 간단하게 알아보자

• 로드
  • 클래스를 파일에서 가져와서 JVM 메모리에 할당한다.

• 링크
  • 검증(Verifying)
    • 클래스 파일이 유효한지를 검증한다.
    • 자바 명세 , JVM 명세를 잘 지켰는 지 확인하며 만약 테스트를 통과 못하였을 시에 VerifyError를 발생시킨다.
  • 준비(Preparing)
    • 클래스 및 인터페이스에 필요한 static field의 메모리를 할당하고 이를 기본값으로 초기화 한다.
  • 분석(Resolving):
    • constant pool 내에 있는 모든 **심볼릭 참조 값들을 메모리 주소(다이렉트)**로 변환시킨다.

• 초기화
  • 준비과정에서 기본값으로 초기화 시켜줬던 static filed들을 코드에 작성해줬던 초기값으로 변경해준다.

이 과정까지 마쳤으면 JVM에서 클래스 파일을 구동시킬 준비가 끝나게 된다.

클래스 로더의 특징

• 위임 모델
  • 클래스 로더는 계층 구조를 바탕으로 클래스 로더끼리 로드를 위임하는 구조로 동작한다.
  • 요청이 들어오면 상위 클래스로 요청을 위임해가면서 해당 클래스를 찾는데, 모든 클래스 로더에 없으면 클래스 패스에서 찾아보고 거기에도 없으면 예외를 반환한다.
  • 클래스 로더끼리 부모-자식 관계를 이루어 계층 구조로 생성되며 최상위 클래스 로더는 부트스트랩 클래스 로더이다.

• 가시성(visibility) 제한
  • 예를 들어서 어플리케이션 클래스 로더는 부트스트랩 로더의 클래스를 볼 수 있지만 , 그 반대는 안된다. (계층 구조)
  • 하위 클래스 로더는 상위 클래스 로더의 클래스를 찾을 수 있지만, 상위 클래스 로더는 하위 클래스 로더의 클래스를 찾을 수 없다.

• 언로드 불가
  • 클래스 로더는 클래스를 로드할 수는 있지만 언로드할 수는 없다. 언로드 대신, 현재 클래스 로더를 삭제하고 아예 새로운 클래스 로더를 생성하는 방법을 사용할 수 있다.

• 유일성
  • 하위 클래스 로더는 상위 클래스 로더가 로딩한 클래스를 다시 로딩하지 않음으로써 효율적으로 로딩이 가능하다

런타임 데이터 영역

런타임 데이터 영역은 JVM이 OS 할당 받는 메모리 영역이다.

크게 6가지의 영역이 있는데 , 공통으로 접근 가능 한것과 공유하지 않는 것을 구분 지어 알아보자

공유하지 않는 것

쓰레드 내에 있는 것들은 서로 접근 할 수 없다.

1. JVM 스택
   • 메서드가 하나씩 수행될 때마다 스택 프레임이 하나씩 쌓이게 된다.
   • 스택 프레임에는 지역 변수 배열이나 피연산자 스택 등 여러가지를 가지고 있다.
   예시 코드를 보면서 지역 변수 배열과 스택 기반 연산이 어떻게 이루어지는 지 알아보자

int num = 1; // 스택 프레임에 쌓임 
int sum = num + 5; // 스택 프레임에 쌓임

이런 간단한 코드를 수행할 때 JVM 스택 내에서는 어떤 일이 일어날까?

일단 위에서 말한 대로 스택 프레임에 메소드가 쌓이게 될 것 이다.

그 다음 지역 변수 배열에 파라미터 , 변수들이 저장이 되는 데 다음과 같이 저장된다.

다시 바이트 코드를 보자

L0
    LINENUMBER 15 L0
    ICONST_1 // 스택에 정수값 1을 올린다.
    ISTORE 1 // 스택에 있는 정수값을 꺼내서 1번 인덱스에 저장
   L1
    LINENUMBER 16 L1
    ILOAD 1 // 1번 인덱스의 값을 스택에 올려라
    ICONST_5 // 스택에 정수값 5를 올린다.
    IADD // 스택 상단 두 개의 값을 더한다.
    ISTORE 2 // 2번 인덱스에 저장한다.

이렇게 해서 값을 반환하고 연산을 마치게 된다.

2.PC 레지스터

• 현재 JVM 명령의 주소를 가지는 쓰레드 공유의 레지스터이다.
• 쓰레드가 시작될 때 생성된다.

3.네이티브 메서드 스택

• JNI 라는 것은 통해 자바가 아닌 c나 c++을 통해 클래스를 작성하였을 시 이를 수행하기 위한 스택이다.

공유하는 것

1. 힙
   • 인스턴스 혹은 객체를 저장한다.
   • 메모리를 정리하는 가비지 컬렉터의 작업이 주로 이루어진다.
2. 메서드 영역
   • 클래스 로더로 부터 불러온 클래스의 바이트 코드 정보들을 저장한다.

실행 엔진

실행 엔진에서 비로소 기계어로의 번역을 시작한다.

이때 두가지 방법이 쓰이는 데 인터프리터와 JIT 방식이다.

인터프리터

• 바이트 코드 명령어를 하나씩 읽어서 수행한다.
• 해석은 빠르지만 실행은 느리다는 단점이 있다.
• 바이트 코드는 기본적으로 인터프리터로 동작한다.

JIT(Just-In-Time)

• 바이트 코드 전체를 네이티브 코드로 번역한다.
• 이후 인터프리팅을 하지 않고 네이티브 코드로 직접 실행하며 한번 컴파일 된 코드는 캐시에 저장된다.
• 하지만 처음 컴파일 과정이 오래 걸리므로 한번만 쓰는 메소드는 JIT 사용이 적합하지 않다.

참고자료

JVM에 관하여 - Part 2, ClassLoader

JVM. 클래스로더 서브시스템(Class Loader Subsystem)

https://www.youtube.com/watch?v=6reapO0gLPs&t=399s

프로그래머스 백엔드 데브코스에서 진행한 Tech Log 활동 목적으로 제작되었습니다.

1. String 클래스의 equals & hashcode

소프트웨어 세계에서는 문자열도 이상한 방식으로 관리한다.

바로 동등성을 보장해주기 위함인데,

이때 앞에서 말한 equals 메소드와 HashCode 메소드를 재정의해서 사용한다.

이를 재정의하지 않는 클래스를 처음부터 만들어가면서 equals 와 HashCode 에 대해 알아보자

본문에서는 String을 모방한 String_test 객체를 만들어 볼것이며 , 각각의 결과값들을 맞춰나갈 것이다.

equals 비교

먼저 객체의 동등성을 비교하기 위해 equals의 값을 비교해보자

String string1 = new String("hi");
String string2 = new String("hi");

System.out.println("String 객체 hashcode 비교 결과 : "+(string1.equals(string2)));

String_test string1_test = new String_test("hi");
String_test string2_test = new String_test("hi");

System.out.println("String 객체 hashcode 비교 결과 : "+(string1_test.equals(string2_test)));

같은 값을 가지는  클래스끼리 비교하였지만

String 객체는 equals 의 true이고 ,

String_test는 equals 의 값이 false 가 나왔다.

hashcode 비교

다음은 객체의 hashcode 값을 비교해보자

String string1 = new String("hi");
String string2 = new String("hi");

System.out.println("String 객체 hashcode 비교 결과 : "+(string1.hashCode() == string2.hashCode()));

String_test string1_test = new String_test("hi");
String_test string2_test = new String_test("hi");

System.out.println("String_test 객체 hashcode 비교 결과 : "+(string1_test.hashCode() == string2_test.hashCode()));

해쉬코드 비교 결과값도 String 객체와 다르게 나오는 것을 볼 수 있다.

🧐 왜 이런 결과가 나왔을까?

정답은 equals 와 hashcode 의 오버라이딩에 있다.

이 둘을 재정의 하기 전에 각각 원래 무슨 역할을 하는 메소드인지 부터 알아보자

2. equals 란 ?

equals 메소드는 2개의 객체가 동등한 지 검사하기 위해 사용되는 메소드이다.

예를 들어,

String string1 = new String("hi");
String string2 = new String("hi");

System.out.println(string1 == string2); // false
System.out.println(string1.equals(string2)); // true

다음과 같이 String 클래스를 생성하여 비교하는 경우 "==" 는 동일성을 비교하기 때문에 false 를 출력하지만 , equals 메소드는 동등성을 비교하기 때문에 true를 출력한다.

*동등성과 동일성의 차이는 뭘까?

동등성은 대상의 대상의 내용을 비교하고

동일성은 주소값을 비교하여 같은 객체인 지를 비교한다.

Object 클래스의 equals 코드를 살펴보자

public boolean equals(Object obj) {
			return this == obj;
    }

근데 정작 Object의 코드를 보면 동등성을 비교해주지 않는다 .(주소값을 비교한다.)

그런데 왜 String 에서는 문자열의 동등성을 비교할 수 있는 걸까?

자바 공식문서에 보면 String의 equals 메소드는 다음과 같이 equals 메소드를 재정의 한다고 나와있다.

그렇기에 우리는 equals 메소드를 동등성 비교에 사용할 수 있는 것이다 !

그러면 String_test 메소드에도 이런 방식으로 equals를 재정의 하면 동등성 비교가 되지 않을까 ?

우리가 만든 Spring_test 클래스에도 equals 를 재정의 해주었다.

class String_test {
    String string;

    public String_test(String string) {
        this.string = string;
    }

    @Override
    public boolean equals(Object o) {
        if (this == o) return true;
        if (o == null || getClass() != o.getClass()) return false;
        String_test that = (String_test) o;
        return Objects.equals(string, that.string);
    }
}

그리고 결과값도 의도한 대로 true 가 나왔다 !

3. hashCode란 ?

hashCode 메소드는 객체의 해시코드를 리턴한다.

*객체의 해시코드란?

객체의 주소값을 변환하여 생성한 고유의 해시값이다.

하지만 기존 방식으로 해시코드를 생성한다면 다른 객체에 대해서 다른 문자열이라도 다른 해시코드를 받을 것이다.

→ 이렇게 된다면 동등성을 보장할 수 없다 !

따라서 String 클래스는 hashCode 역시 재정의해서 사용한다.

자바 공식 문서를 보면 문자열의 문자들을 한 글자씩 가져와서 변환한다는 것을 알 수 있다.

그렇기에 다른 주소값의 객체라도 문자열이 같으면 같은 hashcode 가 나오는 것이다.

따라서 우리가 만든 Spring_test 클래스도 hashCode 를 재정의 해보았다.

class String_test {
    String string;

    public String_test(String string) {
        this.string = string;
    }

    @Override
    public int hashCode() {
        return Objects.hash(string);
    }
}

String 객체처럼 Spring_test 객체도 같은 값이 나옴을 알 수 있다.

Hash 와 Hash 테이블의 관계

hashCode 메소드를 이용해서 해시코드 값을 받는 다는 것을 알게되었다.

이렇게 얻게 된 해시코드는 어디에 사용되는 걸까?

hashCode 와 equals 의 관계를 알기 전 우리는 해시테이블이라는 자료구조에 대해 알아볼 것이다.

🧐 자료구조? 그게 뭔가요?

도서관에는 정말 많은 책들이 있다.

만약 자기가 사서 관리를 맡았는 데 이 많은 책들 중에서 특정 책을 찾거나 정리해야 한다고 생각하면 여간 막막한 일이 아닐 것이다.

다행히 이런 일들을 우리가 처음 겪은 게 아니고 옛날부터 많은 기술자들이 고안한 끝에 데이터를 쉽게 찾고 꺼내올 수 있는 규칙과 틀을 미리 만들어 두었다.

이것들 중에 하나가 우리가 알아볼 해시 테이블이다.

해시테이블이란?

데이터를 key , value 로 저장하는 형태를 말한다.

보통 도서관에서는 도서 관리 번호를 지정하고 , 그 번호를 찾아보면 해당 책을 발견할 수 있다.

이것도 현실 세계에서의 key , value 형태라고 부를 수 있을 것이다.

해시 테이블의 원리

다시 소프트웨어로 돌아와서 이러한 형태의 해시 테이블이 어떻게 만들어지는 지 알아보자

도서관의 책들을 key , value 형태로 저장하려고 한다.

이때 key는 책 이름 , value는 가격으로 해주었다.

그 결과, 가장 오른쪽에 있는 Bucket에는 해쉬 연산을 통해 나온 인덱스와 value(책 가격) 이 담긴다.

이런식으로 저장을 하게 되면 데이터를 찾을 때 Hash 연산을 한번만 수행하면 되므로 매우 빠르게 데이터를 조회할 수 있다.

→ 이런 경우 시간 복잡도는 O(1) 이 된다 !

🧐 그런데 만약 서로 다른 책들끼리 같은 해쉬 연산 결과가 나와서 같은 인덱스에 저장된다면 어떻게 될까 ?

이 문제를 해결하기 위한 대표적인 방법 두가지를 소개해보려고 한다.

Separate Chaining 기법

해쉬테이블에서는 하나의 인덱스에 여러 개의 버킷을 연결시키는 것으로 해결할 수 있다.

다시 그림을 보자

분명 다른 책인데, 같은 인덱스에 저장이 되었다.

즉 해시 충돌이 발생하니까 새로운 값을 기존 값과 연결시킨 거라고 볼 수 있다.

하지만 이렇게 하면 버킷에 하나의 데이터만 저장하는 것 보다 효율이 안좋아진다.

기존엔 해시 함수 결과에 따라 해당 인덱스만 찾아가면 됐었는데 , 이제는 그 안에서 한번 더 탐색을 해야하기 때문이다.

최악의 경우 모든 데이터를 뒤져봐야 할 수도 있다.

→ 시간복잡도는 평균적으로 O(n/m) 최악의 경우 O(n) 을 가지게 될 수 있다.

(해시 테이블의 저장소(Bucket)의 길이를 ‘m’, 키(key)의 수를 ‘n’)

이를 보완하기 위해 자바8 이상부터는 하나의 해시 버킷에 할당 된 데이터가 8개 이상이 되면 연결 리스트에서 트리로 구조를 변경한다.

→ 이럴 경우 평균 적인 시간 복잡도는 O(log(n/m)) 이 된다.

Open addressing 기법 (개방 주소법)

개방 주소법은 해시값의 인덱스에 데이터가 있을 시에 다른 인덱스를 탐색하여 데이터를 저장하는 방법이다.

같은 인덱스에 여러 개의 데이터를 저장하는 방법과는 상반된 방법이다 !

해시 충돌이 발생 했을 시에 어느 인덱스에 데이터를 저장할 것인지를 결정하는 방법은 총 3가지가 있다.

선형 탐색 (linear probing)

충돌이 일어났을 때, 한칸 또는 n칸씩 다음 인덱스가 비어있는지 확인해본다.

제곱 탐색 (quadratic probing)

1의 제곱 , 2의 제곱 … 만큼 인덱스를 이동해가면서 비어있는지 확인해본다.

이중 해시 (Double Hash)

위에 두 방법을 통해서 어느 정도 충돌을 해결할 순 있다.

하지만 해쉬값이 같을 경우 빈 슬롯을 찾아 접근하는 위치가 동일하므로

접근 슬롯을 중심으로 데이터가 한 곳에 집중되어 있는 현상이 발생할 수 있다.

이 상황을 피하기 위해 나온 방법이 이중 해시이다.

말 그대로 해시 함수를 두 번 돌린 것이다.

예를 들어,

1차 해시는 키를 삽입하여 데이터의 해시 인덱스를 정한다.

2차 해시는 충돌이 발생하였을 시에 몇 칸 뒤로 인덱스를 이동할 지 정한다.

이처럼 이중 해시를 사용하면 1차 해시값이 같더라도 2차 해시값은 달라지므로,

데이터의 군집 문제를 어느정도 해결할 수 있다.

개방 주소법의 경우에도 해당 인덱스에 충돌이 발생했었다면 다음 인덱스를 찾아가면서 탐색을 해야하므로 최악의 경우 O(n) 의 시간 복잡도를 가질 수 있다.

🧐 근데 데이터가 점점 많아진다면 어떻게 될까 ?

아마 해쉬 충돌은 빈번해지며 효율은 더욱 나빠질 것이다.

(참고로 자바에서 제공하는 기본 버킷 사이즈는 16이다)

이 상황에 대해 묘사한 재밌는 이론이 있다.

비둘기 집 원리

만약 9개의 비둘기 집이 있는 데 10마리 이상의 비둘기가 들어가려고 한다면?

어쩔 수 없이 2마리 이상의 비둘기가 함께 지내야 할 것이다.

이 상황은 무한한(비둘기) 입력에 대해 유한한(비둘기 집) 출력만이 존재하기 때문에 나타난 현상이라고 할 수 있다.

소프트웨어에서도 마찬가지다.

key값은 무한하지만 버킷 과 해쉬값 은 유한하다.

이 경우 해쉬테이블은 Dynamic Resizing 을 통해서 버킷의 사이즈를 두 배씩 늘려준다.

이때 늘릴 수 있는 최대 길이는 2^30 이다 !

이제 HashCode의 역할과 해시 값을 이용한 해시 테이블도 알아보았으니

이쯤에서 equals and hashcode에 대해 알아보자

4. equals 와 hashcode 을 왜 같이 재정의 해줘야할까 ?

위에서 보았듯이 일반적으로 equals 와 hashcode 는 같이 오버라이딩 해주고 있다.

만약 equals만 오버라이딩 해준다면 여러 문제가 발생할 수 있는데 , 대표적으로 해쉬 자료구조를 사용할 때이다.

중복을 허용하지 않는 set를 예로 들어보자

같은 값의 객체를 넣어준다면 하나만 들어가야 정상일 것이다.

equals만 오버라이딩 하였을 경우

class Test {
    String key;

		public Test(String key) {
        this.key = key;
    }
		
    @Override
    public boolean equals(Object o) {
        if (this == o) return true;
        if (o == null || getClass() != o.getClass()) return false;
        Test test = (Test) o;
        return Objects.equals(key, test.key);
    }    
}

Set<Test> set = new HashSet<>();
        
set.add(new Test("hi"));
set.add(new Test("hi"));

System.out.println(set.size()); // 결과 2

같은 값을 가지는 객체를 넣어줬는데 두개가 들어가는 결과가 나왔다.

이는 Hash 테이블에서 같은 값을 가짐에도 다른 객체로 인식하였다는 것이다.

hashCode 만 오버라이딩 하였을 경우

class Test {
    String key;

    public Test(String key) {
        this.key = key;
    }

    @Override
    public int hashCode() {
        return Objects.hash(key);
    }
}

Set<Test> set = new HashSet<>();
        
set.add(new Test("hi"));
set.add(new Test("hi"));

System.out.println(set.size()); // 결과 2

마찬가지로 같은 값을 가지는 객체를 넣어줬는데 두개가 들어가는 결과가 나왔다.

이 경우도 같은 값을 가짐에도 다른 객체로 인식하였다는 것이다.

🧐 왜 Equals와 HashCode 둘 중 하나만 재정의 하였을 시에 오류가 나는 걸까 ?

이 이유를 알기 위해 해쉬 자료구조의 동작 원리를 순서대로 알아보자

해쉬 맵의 동작 구조

해쉬 자료구조에서 객체가 동등한 지를 비교할 땐 다음 과정을 거친다.

1. 해쉬코드의 값을 비교한다.
2. 해쉬코드의 값이 같다면 equals의 값을 비교한다.
3. 위 두개의 값이 같다면 동등 객체라고 판단한다.

따라서 ,

equals만 재정의 하였을 경우 해쉬코드가 다르게 나왔기 때문이고

hashCode 만 재정의 하였을 경우 equals의 반환값이 false 였기 때문에 다른 객체로 보았던 것이다.

이처럼 둘을 동시에 재정의 해주지 않으면, Hash 자료구조를 사용하면서 예상치 못한 결과를 불어올 수 있다.

4. equals & hashCode 규약

1. equals() 비교에 사용되는 정보가 변경되지 않았다면, 애플리케이션이 실행되는 동안 그 객체의 hashcode()는 항상 같은 값을 반환해야한다.
2. equals()로 비교했을 때 같다고 판단했다면, 두 객체의 hashCode는 같은 값을 반환해야 한다.
3. equals()가 두 객체를 다르다고 판단한 경우 꼭 hashCode가 다를 필요는 없다.
4. 다른 값을 반환하는 게 좋다.

5. 결론

해시코드와 equals의 차이에 대해 알아보고 , 이 둘을 왜 같이 재정의 해줘야하는지에 대해서도 알아보았다.

만약 이 둘을 같이 재정의 해주지 않는다면 위처럼 해쉬 자료구조를 이용할 때 예상치 못한 결과를 가져온다.

동등성을 보장해주지 못하기 때문에 다른 객체로 인식이 되기 때문이다.

따라서 equals와 hashCode 를 같이 재정의 하도록 하자 !

6.참고 자료

Java HashMap은 어떻게 동작하는가?

equals와 hashCode는 왜 같이 재정의해야 할까?

Hashtable의 이해와 구현 #1

equals와 hashCode는 왜 같이 재정의해야 할까?

[데이터 구조] Hashtable 충돌(collisoion)을 해결하는 방법에 대해서 이해가 필요하다. (open addressing, separate chaining) +설명영상

트랜잭션이란 ?

소프트웨어 세계에서의 트랜잭션을 살펴보기 앞서서 실생활에서 흔히 있는 이야기를 예로 들어보려고 한다.

만약 친구가 당신에게 자신의 계좌에 20만원을 보내주려고 한다.

이 경우 작업의 단위는 어떻게 될까?

자세히 파해치면 더 많은 단위가 있을 수 있겠지만 크게 두 가지로 볼 수 있을 것이다.

1. 친구 A의 계좌에서 20만원을 뺀다.

2. 친구 B의 계좌에 20만원을 추가한다.

이 상황에서 발생할 수 있는 문제들은 여러가지가 있는데 대표적으로 4가지만 알아보자

만약, 송금 도중 A의 계좌에는 돈이 빠졌는데 B의 계좌에 돈이 그대로라면?

만약, A의 계좌에 돈이 부족한 상태인데 송금이 되었다면?

만약, 송금 도중 친구C가 송금을 보내서 서로의 데이터가 엇갈린다면?

만약, 송금을 잘 마쳤음에도 데이터가 날아가 버린다면..?

그렇다면 친구가 보내준다고 했던 20만원은 증발해버린 것이고 이는 곧 대형 사고로 이어진다.

이런 현상을 방지하기 위해 사용하는 것이 트랜잭션이다.

트랜잭션은 위에서 말한 작업 단위들을 묶음으로 인해 일부만 성공해서 DB에 반영되는 일이 없도록 도와준다.

즉 데이터베이스의 상태를 변화시키기 해서 수행하는 논리적인 작업의 단위이다.

그리고 트랜잭션의 성질이 위에서 말한 여러 문제상황들을 방지해준다.

트랜잭션의 성질

위에서 말한 4가지 문제들은 트랜잭션의 성질에 정의되어 있다.

그리고 이 성질들을 ACID 라고 부른다.

A : Atomicity (원자성)

C : Consistency (일관성)

I : Isolation (독립성)

D : Durability (지속성)

앞선 사례들을 하나씩 보면서 각각 어떤 성질과 대비되는 지 살펴보자 !

만약, 송금 도중 A의 계좌에는 돈이 빠졌는데 B의 계좌에 돈이 그대로라면?

이 예시는 원자성(Atomicity)을 지키지 못한 것이다.

하나의 작업이 성공하고 하나의 작업이 실패했는데 결과가 DB에 반영된 것이다.

원자성은 지킨다는 것은 모든 작업이 모두 성공하거나 아니면 모두 실패해야한다.

만약, A의 계좌에 돈이 부족한 상태인데 송금이 되었다면?

이 예시는 일관성(Consistency)을 지키지 못한 것이다.

DB에는 잔액은 마이너스가 될 수 없다는 제약이 있음에도 이를 어긴 채 송금을 진행한 것이다.

일관성을 지킨다는 것은 트랜잭션 이전,이후에도 데이터베이스의 제약이나 규칙을 만족한다는 것이다.

만약, 송금 도중 친구C가 송금을 보내서 서로의 데이터가 엇갈린다면?

이 예시는 독립성(Isolation)을 지키지 못한 것이다.

친구C와의 트랜잭션이 동시에 실행됨으로써 영향을 미친것이다.

(친구C가 보낸 돈에 더해지지 않고 기존 금액에 더해짐으로써 잔액이 그대로)

독립성을 지키기 위해서는 트랜잭션들이 동시에 실행될 때에도 혼자 실행되는 것처럼 동작해야한다.

만약, 송금을 잘 마쳤음에도 데이터가 날아가 버린다면..?

이 예시는 지속성(Durability)을 지키지 못한것이다.

당연한 말이지만 저장된 데이터는 영구적으로 DB에 남아있어야한다.

영구성을 지키기 위해서는 DB에 문제가 발생하더라도 커밋된 트랜잭션이 DB에 남아있어야한다.

여기까지가 트랜잭션의 ACID 성질이다.

이렇듯이 트랜잭션은 ACID 성질을 유지해줌으로써 데이터의 정합성을 지켜준다.

🧐 정합성이 뭐지?

데이터 정합성은 데이터가 서로 모순 없이 일관되게 일치해야 함을 의미한다 !

믿을 수 있는 데이터를 위해선 정합성이 보장되어야한다.

지금까지 트랜잭션의 역할과 ACID 성질에 대해 알아보았다 !

이제 트랜잭션이 뭔지 감이 오는가?

트랜잭션은 알겠는데 ... 격리 수준은 뭐지?

트랜잭션은 데이터의 정합성을 지켜줄 수 있는 좋은 장치이다.

하지만 트랜잭션끼리 접촉하다 보면 여러 문제가 발생할 수 있다.

대표적으로 크게 3가지 문제가 있는데

1. dirty read

2. non repeatable read

3. phantom read

하나하나 알아보자 !

고려해봐야 할 문제점들

위에서 언급한 3가지의 이상 현상들을 하나씩 알아보면서 격리레벨이 왜 필요한 지 생각해보자 !

아래에서 설명하는 상황들은 모두 트랜잭션 A,B가 하나의 데이터 베이스에 접근하고 가정한다.

dirty read

쉽게 말해서 , 커밋되지 않은 변화를 읽는 것이다.

트랜잭션 A와 B가 각각 다른 데이터에 접근해서 데이터베이스를 변화시키는 상황을 생각해보자

트랜잭션 A는 x를 변화시키고 , 트랜잭션 B는 y를 변화시킨다.

어떤 문제가 발생할까?

뭔가 이상하지 않은가?

x에 더한 y의 값 10은 더 이상 유효하지 않은 값이다.

즉, 위에서 말했다시피 커밋되지 않은 변화를 읽어서 문제가 생긴것이다.

non repeatable read

같은 데이터를 조회했을 때 값이 다르게 나오는 것이다.

트랜잭션 A가 x의 값을 처음 읽었을 때는 50이었다.

그 사이에 트랜잭션 B가 x의 값을 10으로 변경했고 , 다시 트랜잭션 A가 x를 읽었을 때는 x의 값은 10이 나온다.

값은 x라는 데이터의 값을 조회했지만 조회할때마다 값이 다르게 나오는 것이다.

이는 곧 isolation 관점에서 바람직하지 못하다.

🧐isolation 위에서 배웠는데 .. !

여러 개의 트랜잭션들이 동시에 수행될 때, 각 트랜젝션은 고립(격리)되어 있어 연속으로 실행된 것과 동일한 결과를 나타낸다.

phantom read

없던 데이터가 생기는 것이다.

이 상황도 마찬가지로 똑같은 조건으로 데이터를 검색했는 데 결과가 다르게 나온다.

이 역시 isolation 원칙에 위배된다고 할 수 있다.

지금까지 소개한 3가지가 대표적으로 나타나는 문제점들이다.

🧐 아 그럼 해결책은 간단하네요 ! 다 막아버리면 되는 거죠?

물론 극도의 안정적인 환경을 위해서라면 그렇게 할 수도 있지만 이는 좋은 방법이 아니다.

코로나 거리두기 단계를 떠올려보자

사실 코로나 확진자가 안나오게 하는 방법은 어떻게 보면 매우 간단할 수 있다.

아무것도 하지 못하게하면 코로나 확진자는 안나왔을 것이다.

근데 현실은 다르다.

거리두기 단계에 따라서 허용되는 것이 있고 금지되는 것들을 정해놓았다.

왜일까?

너무나 당연한 얘기이지만, 모든 것을 금지시켜 버리면 사회는 돌아가지 않기 때문이다.

그래서 단계에 따라 준수사항들을 조정함으로써 관리했던 것이다.

트랜잭션에도 비슷한 개념이 적용된다.

격리레벨이 올라갈 수록 안정성은 높아지지만 데이터 처리량이 저하된다.

그리고 이것에 대해 정해놓은 표준 SQL 기준을 알아보려고 한다.

SQL 표준 격리 레벨

SQL 표준에서는 위에서 말한 문제들을 어디까지 허용할 지 구분하는 격리레벨을 지정하였다.

Read uncommitted

Read uncommitted 레벨은 커밋되지 않은 변화도 다른 트랜잭션이 읽을 수 있다.

아래 예시를 보자, 트랜잭션1이 새로운 데이터를 넣고 커밋을 하지 않은 상태이지만 트랜잭션2는 이것을 읽을 수 있다.

사실상 격리가 아예 없는 거나 마찬가지이므로 최소한 Read committed 이상 레벨의 사용을 권장한다.

Read uncommitted 레벨에서 발생할 수 있는 문제점

- 이 레벨에서는 많은 문제들이 발생할 수 있지만 대표적으로 Dirty Read 에 대해 다뤄보고자 한다.

위에서 dirty read는 커밋되지 않은 변화를 읽음으로써 나타나는 문제라고 하였는데 Read uncommitted 에서 그 문제가 그대로 발생한다.

트랜잭션 B는 데이터베이스로 부터 Y를 읽기로 하였다.

하지만 B가 데이터를 읽는 도중 트랜잭션A가 Y의 데이터를 변경하였고 B는 격리레벨 특성상 커밋되지 않은 데이터를 읽게 되었다.

하지만 A가 변경한 데이터가 커밋되지 않고 롤백된다면 어떻게 될까?

트랜잭션B가 읽은 Y의 데이터는 더 이상 유효한 값이 아니게 된다.

이 현상을 dirty read 라고 부른다.

즉, 트랜잭션에서 처리한 작업이 완료되지 않았음에도 불구하고 다른 트랜잭션에서 볼 수 있게 되는 현상이다.

Read committed

Read committed 단계에서는 커밋된 데이터만 읽기 때문에 dirty read 와 같은 현상은 발생하지 않는다.

어떻게 이것을 구현할 수 있었을까?

바로 undo 영역을 따로 만들어줌으로써 백업된 데이터만을 가져오기 때문이다.

밑에 그림을 보면 트랜잭션1에서 데이터를 변경하기 전에 테이블을 백업한다.

그리고 테이블에 변경된 데이터가 반영된다.

트랜잭션2에서는 undo 영역에서 데이터를 가져오기 때문에 이전에 커밋된 데이터만 볼 수 있는 것이다 !

Read committed 발생할 수 있는 문제점

- 이 레벨에서는 non repeatable read 문제가 발생한다.

무엇이 문제일까? 다시 예시를 보자

트랜잭션B가 Y를 두번 조회한다고 가정하자

첫번째로 조회했을 때는 Y가 50이 나왔지만 두번째로 조회했을 땐 70이 나왔다.

얼핏 생각하면 크게 문제될게 없어보이는 데 , 이는 ACID 속성 중 독립성에 어긋난다.

🧐 독립성 벌써 몇번째야 ..

동시에 여러 개의 트랜잭션들이 수행될 때, 각 트랜젝션은 고립(격리)되어 있어 연속으로 실행된 것과 동일한 결과를 나타낸다.

Repeatable read

어떻게 하면 트랜잭션 내에서 특정 행을 조회할 때 마다 항상 같은 데이터를 나오도록 할 수 있을까?

Repeatable read 에서는 이를 트랜잭션 ID 를 통해 해결한다.

이렇게 부여된 트랜잭션 ID보다 작은 트랜잭션 번호에서 변경한 것만 읽게 된다.

그리고 undo 로그가 많아지면 데이터베이스의 성능이 떨어질 수 있기때문에 DB엔진에서는 불필요한 undo 로그를 주기적으로 삭제한다.

Repeable read에서 발생할 수 있는 문제점

- 이 레벨에서는 phantom read 라는 문제가 발생할 수 있다.

예시를 살펴보자

맨처음 데이터행을 조회했을 때 1개가 나왔지만 나중에 한번 더 조회했을 때 하나가 추가된 2가 나왔다.

이는 undo 테이블에 쓰기 잠금을 할 수 없기 때문에 발생하는데 결국 현재 데이터의 값을 가져오게 된다.

(innoDB에서는 팬텀 리드가 발생하지 않는다고 한다!)

Serializable

특정 트랜잭션이 사용중이면 다른 트랜잭션은 일체 접근할 수 없다.

데이터의 안정성(정합성)은 높으나 처리량은 떨어진다.

발생할 수 있는 문제점

- 없음

다시 표로 정리해보자

이처럼 격리 단계에 따라 허용하는 오류들이 정해져있다.

각각의 용도에 맞게 적절하게 격리 레벨을 지정하는 것이 중요하다.

결론

데이터의 정합성을 보장해주기 위해서 트랜잭션을 사용해야한다.

하지만 트랜잭션끼리 동시에 실행되다 보면 여러 문제들이 발생하는 데

SQL 표준에서 이를 어디까지 허용할 것인지에 대한 격리 단계를 지정해놓았다.

각자 상황에 따라 적절한 격리 단계를 선택해야한다.

참고 자료

[MySQL] - 트랜잭션의 격리 수준(Isolation level)

트랜잭션 격리 수준

[데이터베이스] 트랜잭션의 ACID 성질 - 하나몬

트랜잭션의 격리 수준(isolation Level)이란?

https://www.youtube.com/watch?v=bLLarZTrebU&t=397s

https://www.youtube.com/watch?v=sLJ8ypeHGlM&t=144s

주요 디자인 패턴 13가지

1. 생성 패턴

- 싱글톤 패턴

- 추상 팩토리 패턴

- 팩토리 메소드 패턴

2. 행동 패턴

- 템플릿 메소드 패턴

- 싱글톤 패턴

- 상태 패턴 

- 반복자 패턴

- 전략 패턴

- 옵저버 패턴

3. 구조 패턴

- 데코레이터 패턴

- 프록시 패턴

- 컴포지트 패턴

- 어댑터 패턴

- 퍼사드 패턴

1. 추상 팩토리 패턴이란?

- 팩토리 클래스를 통해 구상 클래스에 의존하지 않고도 객체들의 조합을 만들 수 있는 패턴

- 팩토리 클래스는 서로 관련이 있는 객체들의 집합이다.

*서로 관련이 있는 관계의 예시 

- 컴퓨터 브랜드 : 삼성 , LG

- 운영체제에 따른 GUI : 맥 , 리눅스 , 윈도우

삼성 컴퓨터 브랜드 공장에서는 삼성 컴퓨터 부품을 찍어내고,

맥 환경에서는 맥 GUI에서 맥 환경에서의 GUI를 구현한다.

여기서 핵심은 브랜드 , 운영체제의 종류에 상관없이 그것의 기능은 모두 동일하다는 것이다.

향후 이 "기능"은 추상클래스나 인터페이스로 묶어진다.

2. 추상 팩토리를 사용하는 이유

추상 팩토리를 사용하지 않는다면?

먄약 윈도우 환경에서 GUI 기능을 만들려고 한다고 가정해보자

클릭과 스크롤 기능을 구현해볼것이다.

Click click = WinGui.runClick();
Scroll scroll = WinGui.runScroll();
// 윈도우 클릭 , 스크롤 구현체를 가져온다.
click.click();
scroll.scroll();
// 각각의 기능 실행

하지만 이제 윈도우가 아닌 리눅스 기능까지 추가해야한다면 어떨까?

Click click = LinuxGui.runClick();
Scroll scroll = LinuxGui.runScroll();
// 윈도우 클릭 , 스크롤 구현체를 가져온다.
click.click();
scroll.scroll();
// 각각의 기능 실행

이처럼 구현 코드를 다시 수정하여서 코드에 반영해주어야한다.

즉, 클라이언트는 구현 코드에 의존하게 된다.

이것을 추상 팩토리를 적용하여 바꿔볼려고 한다.

GuiFactory gui = new WinGuiFac();
Click click = gui.runClick();
Scroll scroll = gui.runScroll();    

click.click();
scroll.scroll();

다음과 같이 팩토리 구현체를 받아서 해당 팩토리의 메소드를 실행시키는 방식으로 리팩토링하였다.

그럼 다시 윈도우 기능을 쓰려면?

GuiFactory gui = new WinGuiFac();
// 여기만 바꿔주면 됨
Click click = gui.runClick();
Scroll scroll = gui.runScroll();    

click.click();
scroll.scroll();

팩토리 하나만 바꿔주면 된다 !

기존 구현 클래스에 의존하던 것에 비하면 훨씬 개선되었다.

3. 추상 팩토리 구현 방법

위에서 추상 팩토리가 어떤 것이 대략 알았다면 , 이제 어떻게 구현을 하는 것이 좋을까 ?

기본 구조는 다음과 같다.

AbstractFactory : 모든 팩토리 구현체를 담을 수 있는 인터페이스 (혹은 추상 클래스)이다.

ConcreteFactory : AbstractFactory의 추상 메소드를 오버라이딩 함으로써 제품/기능을 생산한다.  

                              여기서 삼성/LG , 리눅스/윈도우 처럼 여러 타입으로 나뉨

ConcreteProduct : 팩토리에서 생성되는 구체적인 제품/기능이다.

                               AbstractProduct를 오버라이딩한다.

AbstractProduct : ConcereteProduct의 공통 인터페이스이다. 

구체적인 코드들을 살펴보자

AbstractFactory

public interface GuiFactory {
    public Click runClick();
    public Scroll runScroll();
}

ConcreteFactory 

public class WindowGuiFac implements GuiFactory {
    @Override
    public Click runClick() {
        return new WindowClick();
    }

    @Override
    public Scroll runScroll() {
        return new WindowScroll();
    }
}

AbstractProduct 

public class WindowClick implements Click {
    @Override
    public void click() {
        System.out.println("윈도우 환경에서 클릭합니다.");
    }
}

public class WindowScroll implements Scroll {
    @Override
    public void scroll() {
        System.out.println("윈도우 환경에서 스크롤합니다.");
    }
}

ConcreteProduct

public class WindowGuiFac implements GuiFactory {
    @Override
    public Click runClick() {
        return new WindowClick();
    }

    @Override
    public Scroll runScroll() {
        return new WindowScroll();
    }
}

구현은 어려울 수 있지만 클라이언트 코드는 

public class main {
    public static void main(String[] args) {
        GuiFactory gui = new LinuxGuiFac();
        Click click = gui.runClick();
        Scroll scroll = gui.runScroll();

        click.click();
        scroll.scroll();
    }
}

이렇게 간단해진다.

요약을 하자면

클라이언트에서 추상 팩토리(Abstract Factory)에 팩토리(Concrete Factory) 주입

-> 팩토리에서 기능 구현 메소드 호출 (Concrete Product)

-> 추상 기능 인터페이스(Abstract Product)를 오버라이딩 한 구현 클래스(Concrete Product)에서 기능 반환 순으로 이루어진다.

4. 추상 팩토리의 장단점  

장점 : 

1. 클라이언트가 구현 클래스에 의존하지 않는다.

- 팩토리를 통해 기능을 생성하는 과정과 책임을 캡슐화 하였기 때문이다.

2. 구현 클래스에 의존하지 않으므로 구현체를 변경 시에 변경해야 할 코드가 줄어든다.

단점 :

1. 코드가 필요 이상으로 복잡해 질 수 있다.

2. 새로운 메소드(기능,제품 등) 을 추가하는 게 어렵다.

     - 추가하려면 Abstract Product를 변경해야하는데 이러면 모든 구현 클래스를 변경해야한다.

5. 결론

여러 제품이나 기능군이 있고 그들끼리 하나를 고르거나 대체할 수 있을 때 추상 팩토리 패턴을 사용할 수 있다.

하지만 코드가 조금 복잡해지거나 나중에 새로운 기능을 추가하기 번거로울 수 있다.

참고자료

https://www.youtube.com/watch?v=qXcxySA-Qes&t=370s 

https://inpa.tistory.com/entry/GOF-%F0%9F%92%A0-%EC%B6%94%EC%83%81-%ED%8C%A9%ED%86%A0%EB%A6%ACAbstract-Factory-%ED%8C%A8%ED%84%B4-%EC%A0%9C%EB%8C%80%EB%A1%9C-%EB%B0%B0%EC%9B%8C%EB%B3%B4%EC%9E%90

https://gmlwjd9405.github.io/2018/08/08/abstract-factory-pattern.html

https://refactoring.guru/ko/design-patterns/abstract-factory

0.상태를 가지지 않는 것(stateless)은 어떤 의미일까?

네트워크 관점

클라이언트와 서버간의 상호작용에서  상태를 갖지 않는 빈.
무상태 세션 빈의 모든 인스턴스는 동일하다

스프링 빈 관점

- 특정 클라이언트에 의존적인 필드가 없다.

- 특정 클라이언트가 값을 변경할 수 있는 필드가 없다.

- 클라이언트들끼리 공유하는 필드가 없다.

1. 상태를 가지는 빈과 상태를 가지지 않는 빈의 차이

The non-singleton, prototype scope of bean deployment results in the creation of a new bean instance
every time a request for that specific bean is made. That is, the bean is injected into another bean
or you request it through a getBean() method call on the container. As a rule, use the prototype scope for all stateful beans and the singleton scope for stateless beans.

- 스프링 공식 문서 발췌

stateless beans

ApplicationContext가 초기화되는 동안 생성한 번만 초기화되는 빈

일반적으로 싱글톤 빈에서 사용

stateful beans

상태를 전달할 수 있는 빈

일반적으로 프로토타입 빈에서 사용되며 개체가 필요할 때마다 생성

2. 싱글톤 빈은 thread - safety 한가?

아니다.

싱글톤 빈은 생명 주기가 길기 때문에 , 많은 HTTP 요청 속에서 계속 재사용될 수 있다.

때문에 특정 클라이언트에게 의존적이거나 클라이언트들 간의 공유되는 피드가 있다면 문제가 발생할 수 있다.

3. 왜 상태를 가지면 안되는가? (코드 실습)

public class StatefulServiceTest {

@Test
void statefulServiceSingleton() {
ApplicationContext ac = new
AnnotationConfigApplicationContext(TestConfig.class);

StatefulService statefulService1 = ac.getBean("statefulService",
StatefulService.class);

StatefulService statefulService2 = ac.getBean("statefulService",
StatefulService.class);

//ThreadA: A사용자 10000원 주문
statefulService1.order("userA", 10000);

//ThreadB: B사용자 20000원 주문
statefulService2.order("userB", 20000);

//ThreadA: 사용자A 주문 금액 조회
int price = statefulService1.getPrice();

//ThreadA: 사용자A는 10000원을 기대했지만, 기대와 다르게 20000원 출력
System.out.println("price = " + price);

Assertions.assertThat(statefulService1.getPrice()).isEqualTo(20000);
}

static class TestConfig {

@Bean
public StatefulService statefulService() {

return new StatefulService();

}
}
}

5가지 관점에서으로 보는 stateless의 장점

A. 스레드 안전성

- Bean에 변경 가능한 상태가 있는 경우 스레드 안전성 문제가 발생할 수 있다.

B. 확장성
- Stateless Bean은 여러 인스턴스 간에 동기화 또는 복제해야 하는 공유 상태가 없기 때문에 수평 확장이 더 쉽다. 

C. 단순성 및 유지 관리
- 상태 비저장 빈은 일반적으로 이해, 테스트 및 유지 관리가 더 간단하다.

D. 재사용성
-  상태 비저장 빈은 다양한 컨텍스트와 사용 사례에서 더 재사용 가능합니다. 충돌을 일으키지 않고 여러 구성 요소와     스레드 간에  안전하게 공유할 수 있다.

E. 트랜잭션 무결성
- Spring은 트랜잭션 관리를 위한 강력한 지원을 제공. Bean을 상태 비저장 상태로 유지하면 실패 또는 롤백 시 롤백 또는 상태 재설정에 대해 걱정할 필요가 없으므로 트랜잭션 관리가 더 쉬워진다.

참고자료

https://docs.spring.io/spring-framework/docs/3.0.0.M3/reference/html/ch04s04.html

https://www.javapedia.net/Spring-Beans/1040

https://d-memory.tistory.com/26

https://alwayspr.tistory.com/11

http://dolszewski.com/spring/spring-bean-thread-safety-guide/

0. 스프링 컨테이너란? or IOC Container

- DI 을 이용하여 애플리케이션을 구성하는 여러 빈(Bean)들의 생명주기(Lifecycle)와 애플리케이션의 서비스 실행 등을 관리하며

  생성된 인스턴스들에게 기능을 제공

- Bean 생성, 관리, 제거 등의 역할을 담당

- BeanFactory와 ApplicationContext라는 2개의 컨테이너로 제어하고 관리한다.

1. Bean Factory란?

Bean Factory는 스프링 컨테이너의 최상위 인터페이스이며  빈을 관리하고 조회한다.

getBean 메소드를 통해서 빈을 인스턴스화 할 수 있다.

스프링에서 빈을 관리하기 위한 기본 컨테이너이다.

- 스프링 컨테이너의 최상위 인터페이스다.
- 스프링 빈을 관리하고 조회하는 역할을 담당한다.
- getBean() 을 제공한다.
- IoC의 기본 기능에 초점

2. Application Context 란?

Application Context는 Bean Factory의 모든 기능 상속하면서 여러 부가 기능을 제공하는 컨테이너이다.

- BeanFactory 기능을 모두 상속받아서 제공한다.
- 여러 부가 기능들을 제공한다.

- 빈의 생성, 관계 설정 등의 제어를 총괄하는 것에 초점

3. 공통점

- 제공된 Bean 정의 및 구성을 기반으로 Bean 인스턴스를 생성하고 관리

- 빈의 생성 , 초기화 및 소멸을 포함하여 빈의 수명 주기를 처리

4. 차이점

A. 기능의 차이

애플리케이션을 개발할 때는 빈을 관리하고 조회하는 기능은 물론이고, 수 많은 부가기능들을 제공한다.

MessageSouce

- 메시지소스를 활용한 국제화 기능

EnvinromentalCapable

- 로컬, 개발, 운영등을 구분해서 처리

ApplicationPublisher

- 애플리케이션 이벤트 프로그래밍에 필요한 기능을 제공

ResouceLoader

- 편리한 리소스 조회 기능 제공

B. 빈 로딩시점의 차이

Bean Factory : Lazy Loading 

- 필요 시에 빈을 로딩한다.

Application Context : Eager Loading

- 런타임 실행 시에 모든 빈을 로딩한다.

C. 구성의 차이

BeanFactory는 주로 XML 을 통해 구현된다.

Application Context는 XML 외에도 자바 코드나 어노테이션 등으로 설정을 구성할 수 있다.

5. 결론

Normally when building most applications in a J2EE-environment, the best option is to use the ApplicationContext
, since it offers all the features of the BeanFactory and adds on to it in terms of features, while also allowing a more declarative approach to use of some functionality, which is generally desirable. 

- 스프링 공식 문서

ApplicationContext를 사용하는 것입니다. ApplicationContext는 BeanFactory의 모든 기능을 제공하고 기능 측면에서 추가하고 일부 기능을 사용하는 데 더 선언적인 접근을 허용하기 때문입니다. 일반적으로 바람직한 기능입니다. 

다만 ApplicationContext의 모든 기능이 필요하지 않거나 메모리 관리 적인 측면이 중요할 때는 Bean Factory가 선호될 수 있다.

참고자료

https://velog.io/@sangwoo0727/BeanFactory%EC%99%80-Application-Context-%EB%B9%88-%EB%A1%9C%EB%94%A9%EC%8B%9C%EC%A0%90%EC%9D%98-%EC%B0%A8%EC%9D%B4

https://www.geeksforgeeks.org/spring-difference-between-beanfactory-and-applicationcontext/

https://docs.spring.io/spring-framework/docs/1.2.x/reference/beans.html

주요 디자인 패턴 13가지

1. 생성 패턴

- 싱글톤 패턴

- 추상 팩토리 패턴

- 팩토리 메소드 패턴

2. 행동 패턴

- 템플릿 메소드 패턴

- 싱글톤 패턴

- 상태 패턴 

- 반복자 패턴

- 전략 패턴

- 옵저버 패턴

3. 구조 패턴

- 데코레이터 패턴

- 프록시 패턴

- 컴포지트 패턴

- 어댑터 패턴

- 퍼사드 패턴

싱글톤 패턴이란?

- 객체가 오직 하나만 생성되는 디자인 패턴이다.

싱글톤 패턴을 사용하는 이유

예를 들어서 사무실에 프린트가 한 대만 있다고 가정해보자.

직원들은 이 프린터를 사용할 때 프린터 한 대를 공유하면서 사용한다.

하지만 직원들이 프린터가 필요할 때 마다 프린터를 새로 주문한다고 하면 어떨까 ? 

이는 매우 비효율적일 것이다.

프린터 한대를 직원들끼리 공유하는 것을 '싱글톤'으로 비유할 수 있다.

이것은 프로그램에서도 적용이 가능한데, 마찬가지로 같은 객체를 단 한번만 생성해서 여러 이점을 가질 수 있다.

주로 데이터베이스 커넥션 풀, 스레드 풀 , 캐시 , 로그 기록 객체에서 사용한다.

1. 메모리를 절약 할수 있다.

생성자를 통해서 한번 생성하고 그 뒤로 고정된 메모리 영역을 사용하기 때문에 메모리 낭비를 방지할 수 있다.

즉, 한번 생성한 인스턴스를 계속 사용한다.

2. 데이터를 쉽게 공유할 수 있다.

전역으로 사용되는 인스턴스이기 때문에 다른 클래스의 인스턴스들도 쉽게 접근할 수 있다.

하지만 이 경우 동시성 문제가 발생할 수 있기때문에 조심해야한다.

싱글톤 패턴 적용 방법

구현코드

public class Singleton {

    private static Singleton instance = new Singleton();
    
    private Singleton() {
        // 생성자는 외부에서 호출못하게 private 으로 지정해야 한다.
    }

    public static Singleton getInstance() {
        return instance;
    }

    public void say() {
        System.out.println("hi, there");
    }
}

메소드와 인스턴스 변수가 모두 static으로 되어있다.

기본 생성자로 객체를 생성할 수 없기 때문에 변수와 메소드의 접근을 해용해야한다.

싱글톤 패턴의 단점

1.  구현의 복잡성

싱글톤 코드를 구현하려면 적지 않은 코드가 들어간다.

생성자 외에도 동시성 문제를 해결하려면 syncronized 같은 키워드를 따로 사용해야한다.

2. 테스트의 어려움

테스트는 격리된 상태에서 진행되어야 하는데 싱글톤은 자원을 공유하기 때문에 제대로 된 테스트가 어렵다.

싱글톤으로 테스트를 진행하려면 매번 인스턴스를 초기화 시켜주어야한다.

3. 클라이언트가 구체 클래스에 의존

싱글톤을 위해 클래스 안에서 객체를 생성하고 있으므로 이는 DIP를 위반한다.또한 OCP 원칙도 위반할 가능성이 있다.

스프링에서의 싱글톤 패턴

- 스프링 컨테이너는 객체 인스턴스를 싱글톤으로 관리한다.(싱글톤 레지스트리)

- 스프링을 통해서 싱글톤을 유지하면 기존 싱글톤의 단점을 해결할 수 있다.

1. 기존의 싱글톤을 구현하기 위해서는 복잡한 코드가 들어갔지만 스프링에서는 별도의 코드가 필요없다.

2. 테스트, DIP , OCP , private 생성자로부터 자유롭게 싱글톤을 사용할 수 있다.

구현코드

void springContainer() {
ApplicationContext ac = new
AnnotationConfigApplicationContext(AppConfig.class);
//1. 조회: 호출할 때 마다 같은 객체를 반환
MemberService memberService1 = ac.getBean("memberService",
MemberService.class);
//2. 조회: 호출할 때 마다 같은 객체를 반환MemberService memberService2 = ac.getBean("memberService",
MemberService.class);
//참조값이 같은 것을 확인
System.out.println("memberService1 = " + memberService1);
System.out.println("memberService2 = " + memberService2);
//memberService1 == memberService2
assertThat(memberService1).isSameAs(memberService2);
}

싱글톤 패턴을 사용할 시 주의사항

싱글톤 객체는 상태를 유지하게(stateful) 설계하지 말자!

싱글톤 객체는 무상태(stateless) 해야한다 !

1. 특정 클라이언트에 의존적인 필드가 있으면 안된다.     

    - 특정 클라이언트가 값을 변경할 수 있는 필드가 있으면 안됨

2. 가급적 읽기만 가능해야한다.

3. 자바에서 공유되지 않는 지역변수 , 파라미터 , ThreadLocal 등을 사용햐여한다.

추상 팩토리 패턴이란?

구체적인 클래스의 의존하지 않고도 서로 연관 된 객체들의 조합을 만들어주는 인터페이스를 제공하는 패턴이다.

예를 들어서, 어떤 GUI 환경에서 클릭과 스크롤 기능을 제공한다고 생각해보자

운영체제는 크게 3가지가 있다 (윈도우 , 맥 , 리눅스)

그리고 운영체제의 종류에 상관 없이 각각의 기능은 동일한 역할을 한다

추상 팩토리는 동일한 OS에 대해 일관된 객체를 생성하여 준다.

추상 팩토리의 요소들을 각각 다음과 같은 역할을 한다.

AbstractFactory
- 실제 팩토리 클래스의 공통 인터페이스

- GUI로 치면 모든 OS 버전을 담는 인터페이스이다.

ConcreteFactory
- 구체적인 팩토리 클래스로 AbstractFactory 클래스의 추상 메서드를 오버라이드함으로써 구체적인 제품을 생성한다.

- GUI로 치면 OS에 맞는 기능을 수행하는 클래스이다.

AbstractProduct
- 제품의 공통 인터페이스

- GUI로 치면 공통 기능(추상적으로)을 가지고 있는 인터페이스이다. 

ConcreteProduct
- 구체적인 팩토리 클래스에서 생성되는 구체적인 기능

- 여기서 각각의 OS에 맞는 기능을 구현한다.

이렇게 함으로써 사용자는 GUI에 접속할 때 OS 에 맞는 기능들을 수행할 수 있다.

구현 코드

추상 팩토리 패턴에는 인터페이스가 크게 두가지가 있다.

먼저 AbstractFactory 와 AbstractProduct 를 구현해보자 - 기능은 클릭과 스크롤이 있다고 가정한다.

GuiFac(AbstractFactory)

public interface GuiFactory {
    public Click runClick();
    public Scroll scroll();
}

Click(AbstractProduct)

public interface Click {
    public void click();
}

Scroll(AbstractProduct)

public interface Click {
    public void click();
}

기능 두 개를 인터페이스화 함으로써 각각의 OS는 이 기능들을 구체화하면 된다.

만약 리눅스 환경에서의 기능을 구현한다고 하자

LinuxClick(ConcreteProduct)

public class LinuxClick implements Click{
    @Override
    public void click() {
        System.out.println("리눅스 환경에서 클릭합니다.");
    }
}

LinuxScroll(ConcreteProduct)

public class LinuxScroll implements Scroll {
    @Override
    public void scroll() {
        System.out.println("리눅스 환경에서 스크롤합니다.");
    }
}

이렇게 두 가지의 기능을 구현했다.

각각 미리 작성해놓은 Click , Scroll 인터페이스를 구체화한다.

구현된 기능들을 사용자에게 제공하려면 ConcreteFactory 가 필요하다.

LinuxGuiFac(ConcreteFactory)

public class LinuxGuiFac implements GuiFactory {

    @Override
    public Click runClick() {
        return new LinuxClick();
    }

    @Override
    public Scroll scroll() {
        return new LinuxScroll();
    }
}

이제 기능을 사용할 준비가 끝났다

메인에서 기능을 실행시켜보자

public class main {
    public static void main(String[] args) {
        GuiFactory gui = new LinuxGuiFac();
        Click click = gui.runClick();
        Scroll scroll = gui.scroll();

        click.click();
        scroll.scroll();
    }
}

이 코드를 실행시키면,

다음과 같이 리눅스에서 실행한 결과 값이 나온다.

만약 리눅스가 아니라 다른 환경(윈도우 , 맥) 에서의 기능을 구현하고 싶다면 위에서 했던 방식과 동일하게 진행하면 된다.

(과정생략)

public class main {
    public static void main(String[] args) {
        GuiFactory gui = new WindowGuiFac();
        Click click = gui.runClick();
        Scroll scroll = gui.scroll();

        click.click();
        scroll.scroll();
    }
}

윈도우로 구현 팩토리를 변경해주었다.

이렇게 추상 팩토리 패턴을 사용하면 의존성을 주입해주는 것만으로도 구현 코드의 변경없이 기능 구현을 변경할 수 있다.

참고한 사이트

https://www.youtube.com/watch?v=soV1C6j9kkg 

https://gmlwjd9405.github.io/2018/08/08/abstract-factory-pattern.html

문자열을 추가할 때 흔히 StringBuilder 와 StringBuffer 를 주로 사용한다.

그 동안은 멀티 쓰레드의 차이라고만 알고 있었는데 이번에 구체적으로 어떻게 다른 지 코드를 통해 살펴보았다.

StringBuilder VS StringBuffer

기본적으로 스트링 버퍼와 스트링 빌더 모두 AbstractStringBuilder 라는 추상클래스를 상속받는다.

대표적으로 사용하는 append 함수의 구현 코드를 보면 둘다 super() 메소드를 통해 AbstractStringBuilder 의 함수를 호출한다.

근데 스트링 버퍼에만 있는 것들이 몇가지 있다.

1. synchronize 

2. toStringCache

각각이 어떤 역할을 하는 지 알아보자

synchronize

- 이 키워드는 멀티 스레드 환경에서의 동기화를 지원한다.  

- 공유 데이터에 lock을 걸어 작업중이던 쓰레드가 마칠때까지 다른 쓰레드에게 제어권이 넘어가지 않게 보호한다.

이 키워드를 통해 스트링 버퍼를 멀티 스레드 환경에서 지원해준다.

toStringCache

- 이름 그대로 toString() 함수의 캐시 같은 변수이다.

   toString() 함수 호출 시에 이 value 배열의 변경이 없다면,  toStringCache을 이용해서 String을 만든다.

스트링 버퍼는 함수를 호출할 때마다 toStringCache 멤버 변수를 초기화 해준다.

그 상태에서 toString()을 호출하면 toStringCache 는 null 이기때문에 새로운 value 값으로 String 을 만드는 것이다 !

@HotSpotIntrinsicCandidate
    public synchronized String toString() {
        return this.toStringCache == null ? (this.toStringCache = this.isLatin1() ? StringLatin1.newString(this.value, 0, this.count) : StringUTF16.newString(this.value, 0, this.count)) : new String(this.toStringCache);
    }

이미 저장된 값이 있을 경우 기존 값을 이용해 String 을 만든다. 

그게 아니라면 새로운 값으로 String 을 만든다.

근데 왜 toStringCache 변수는 스트링 버퍼에만 있을까 ?

그 이유는 스트링 빌더는 단일 쓰레드 환경에서만 사용되는 것으로 간주하기 때문이다.

이게 무슨 의미냐면, 스트링 버퍼는 멀티 쓰레드에서 실행되기 때문에 변하지 않은 상태에서 여러번 불릴 수 있지만

단일 쓰레드에서 실행되는 스트링 빌더는 상대적으로 이런 경우가 적다.

결국 최적화의 차이이다.

결론

공통점

스트링 빌더와 스트링 버퍼 모두 같은 추상 클래스를 상속 받는다.

차이점

스트링 빌더 : 단일 스레드이거나 동기화를 신경 쓰지않아도 되는 곳

스트링 버퍼 : 멀티 스레드 환경에서 사용

참고한 사이트

https://woooongs.tistory.com/98?category=798806 

https://stackoverflow.com/questions/46294579/why-stringbuffer-has-a-tostringcache-while-stringbuilder-not

문제

분석

사실 이 문제를 굉장히 단순 무식하게 풀었다.

대략 문제의 조건을 요약하면

1.  중간에 파티션(X)이 존재한다면 거리 두기를 지킨 것이다.

2. 파티션을 사이에 두고 앉은 경우도 거리 두기를 지킨것이다. (옆에 빈 테이블이 있으면 안됨)

으로 요약 가능하다.

생각해보면, 

1번 조건은 파티션이 나오면 해당 라인은 더 이상 탐색할 필요가 없는 것이다.

2번 조건에서는 P(참가자) 옆에 공석(O)이 있으면 안된다. 

라고 해석할 수 있다.

이제 알고리즘을 짜보자 

탐색을 할 때는 세가지 경우가 있다.

1. 파티션(X)이 나오는 경우 

     - 더 이상 볼 필요 없음 skip

2. 참가자(P)가 나오는 경우

    - 무조건 안됨

3. 공석(O)이 나오는 경우

    - 이건 좀 더 탐색할 필요가 있다.

      주변에 참가자(P) 가 있는 지 확인해 보자

이런 메커니즘으로 풀면 문제를 효율적으로 해결할 수 있다.

근데 난 상하좌우 대각선 까지 일일이 탐색해주었다 ㅎㅎ...

코드

import java.util.*;

class Solution {
    
    static int[] dx = {1,2,-1,-2,0,0,0,0,-1,-1,1,1};
    static int[] dy = {0,0,0,0,1,2,-1,-2,-1,1,-1,1};
    static List<Integer> answer_ = new ArrayList<>();
    public int[] solution(String[][] places) {
        int[] answer = new int[5];
        for(int i=0;i<5;i++){
            visit(places[i]);
            if(visit(places[i]) == true){
                answer_.add(1);
            }
            else {
                answer_.add(0);
            }
        }
        
        for(int i=0;i<5;i++){
            answer[i] = answer_.get(i);
        }
        
        return answer;
    }
    
    static boolean visit(String[] places){
        for(int j=0;j<5;j++){
                for(int k=0;k<5;k++){
                    if(places[j].charAt(k) == 'P'){
                        check(j,k,places);
                        if(check(j,k,places) == false){
                            return false;
                        }
                    }    
                }
            }    
        return true;
    }
    
    static boolean check(int y,int x,String[] places){
        for(int i=0;i<=7;i++){
            if(y+dy[i] < 0 || y+dy[i] > 4 || x+dx[i] < 0 || x+dx[i] > 4) break; 
            if(places[y+dy[i]].charAt(x+dx[i]) == 'X') break;
            if(places[y+dy[i]].charAt(x+dx[i]) == 'P') return false;
        }
        
        for(int i=2;i<=3;i++){
            if(y+dy[i] < 0 || y+dy[i] > 4 || x+dx[i] < 0 || x+dx[i] > 4) break;
            if(places[y+dy[i]].charAt(x+dx[i]) == 'X') break;
            if(places[y+dy[i]].charAt(x+dx[i]) == 'P') return false;
        }
        for(int i=4;i<=5;i++){
            if(y+dy[i] < 0 || y+dy[i] > 4 || x+dx[i] < 0 || x+dx[i] > 4) break;
            if(places[y+dy[i]].charAt(x+dx[i]) == 'X') break;
            if(places[y+dy[i]].charAt(x+dx[i]) == 'P') return false;
        }
        for(int i=6;i<=7;i++){
            if(y+dy[i] < 0 || y+dy[i] > 4 || x+dx[i] < 0 || x+dx[i] > 4) break;
            if(places[y+dy[i]].charAt(x+dx[i]) == 'X') break;
            if(places[y+dy[i]].charAt(x+dx[i]) == 'P') return false;
        }
        for(int i=8;i<=11;i++){
            if(y+dy[i] < 0 || y+dy[i] > 4 || x+dx[i] < 0 || x+dx[i] > 4) continue;
            if(places[y+dy[i]].charAt(x+dx[i]) == 'X' || places[y+dy[i]].charAt(x+dx[i]) == 'O') 
                continue;
            if(places[y+dy[i]].charAt(x+dx[i]) == 'P'){
                
                
              if(places[y+dy[i]].charAt(x) == 'X' && places[y].charAt(x+dx[i]) == 'X') {
                  continue;
                }
                else return false;
                }
            
            }  
        return true;
        }
        
    
    }