개발 정리 모음집

이진 탐색 - Upper Bound와 Lower Bound

주다애 — Sat, 25 Jan 2025 00:09:05 +0900

이진 탐색

이진 탐색은 정렬된 상태의 데이터에서 원하는 값을 찾아내는 알고리즘이다.
데이터의 중앙값과 찾고자 하는 값을 비교한다.

이진 탐색은 탐색 대상이 매번 절반으로 줄어들기 때문에 시간 복잡도는 O(logN)이다.

이진 탐색의 동작 원리는 다음과 같다.

배열이나 리스트를 정렬한다.
배열이나 리스트의 중간 값을 선택한다.
중간 값이 목표 값보다 크면 왼쪽 절반을 탐색하고, 중간 값이 목표 값보다 크면 오른쪽 절반을 탐색한다.
중간 값과 목표 값이 같을 때까지 탐색한다.

예를 들어보자

정렬된 배열(arr) : [1, 3, 5, 7, 9, 11, 13]

목표 값 : 9

먼저 left는 0, right는 6로 시작한다.(시작 인덱스0, 가장 끝 인덱스 6)

public class BinarySearchMain {
    public static void main(String[] args) {
        int[] arr = {1, 3, 5, 7, 9, 11, 13};
        int v = 7;
        int ans = binarySearch(arr, v);
        System.out.println(ans);
    }

    private static int binarySearch(int[] arr, int v) {
        int left = 0;
        int right = arr.length - 1;

        while (left <= right) {
            int mid = (left + right) / 2;

            if (arr[mid] > v) {
                right = mid - 1;
            }
            else if (arr[mid] < v){
                left = mid + 1;
            }
            else return mid;
        }

        return -1;
    }
}

left = 0, right = 6이므로 mid = 3이다. arr[mid]는 arr[3] = 7이다. 목표 값인 9는 7보다 크므로 mid를 중심으로 오른쪽 절반을 다시 탐색한다. 즉 left 값을 mid + 1로 해준다.
left = 4, right = 6이므로 mid = 5이다. arr[mid]는 arr[5] = 9이다. 목표 값이 9와 동일하므로 else문에 들어와서 mid를 리턴해준다.
만약 left <= right일 때까지, 즉, 시작점이 끝점보다 작거나 같을 때까지 탐색했을 때 원하는 값의 인덱스를 찾지 못하면 -1을 리턴해준다.

Upper Bound와 Lower Bound

이진 탐색의 방식으로 상한선과 하한선 방식이다.

Upper Bound는 상한선 방식으로 주어진 값보다 큰 값이 처음으로 등장하는 위치를 찾는다.

Lower Bound는 하한선 방식으로 주어진 값보다 크거나 같은 값이 처음으로 등장하는 위치를 찾는다.

[1, 3, 3, 5, 7]의 배열 / 목표 값 3의 upper bound는 인덱스 3이다.(값은 5)

[1, 3, 3, 5, 7]의 배열 / 목표 값 3의 lower bound는 인덱스 1이다.(값은 맨 처음 나오는 3)

코드로 구현해보자

package BinarySearch;

public class UpperBound {
    public static void main(String[] args) {
       // 이분탐색은 기본적으로 정렬되어 있어야 함
       int[] arr = {1, 2, 3, 4, 5, 6, 6};
       System.out.println("upper bound : " + upperBound(arr, 5));
       System.out.println("lower bound : " + lowerBound(arr, 5));
    }

    // 특정 값을 초과하는 가장 처음에 나오는 위치
    // 상한선
    static  int upperBound(int[] arr, int target) {
       int left = 0;
       int right = arr.length;

       while (left < right) {
          int mid = (left + right) / 2;
          if (arr[mid] <= target) {
             left = mid + 1;
          }
          else {
             right = mid;
          }
       }
       return left;
    }

    // 특정 값 이상인 첫번째 위치(인덱스)
    // 하한선
    static int lowerBound(int[] arr, int target) {
       int left = 0;
       int right = arr.length;

       while (left < right) {
          int mid = (left + right) / 2;
          if (arr[mid] < target) {
             left = mid + 1;
          }
          else {
             right = mid;
          }
       }
       return left;
    }
}

target 값이 5이면 upper bound는 5보다 큰 값인 6이 맨 처음 나오는 인덱스인 5를 반환한다.

target 값이 5이면 lower bound는 5보다 크거나 같은 값인 5가 처음 나오는 인덱스인 4를 반환한다.

두 가지를 짚고 넘어가볼 수 있다.

둘 다 right 값을 arr.length - 1이 아닌 arr.length로 하고 있다. 만약 upperBound(7)과 lowerBound(7)를 호출하게 되면 주어진 배열 크기만큼 리턴되어야 한다.(upper bound는 목표 값보다 큰 첫 번째 위치를 가리키므로 배열 끝 이후를 가리키게 되고, lower bound는 목표 값이 처음 나타나는 위치를 넘어서 배열 끝을 가리킨다.) 즉, 값이 없는 경우에도 올바를 결과를 리턴한다.
이 때 left 값을 반환하는 이유는 탐색 과정에서 left가 최종적으로 특정 조건을 만족하는 지점을 가리키기 때문이다.그래서 최종적으로 left는 조건을 만족하는 최초의 위치를 가리키게 된다. 이진 탐색 과정에서 left는 항상 조건을 만족할 가능성이 있는 최소 인덱스를 유지한다.

error-css파일 net::ERR_ABORTED 404 (Not Found)

주다애 — Sat, 28 Dec 2024 01:53:08 +0900

상황 : thymeleaf로 개발 중 html파일과 css파일을 분리한 후 발생한 에러

html 파일에 css를 넣으니 html 파일이 너무 길어졌다. 그래서 css파일을 분리했다.

static/css 밑에 css 파일이 들어간다.

공통적으로 resources 폴더 밑에 존재하고 html 파일은 templates 폴더 밑에, css 파일은 static/css/ 폴더 밑에 위치하는 구조이다.

그래서 html 파일에서 css 파일을 읽어올 수 있도록 하기 위해 다음과 같이 설정 해주었다.

<link rel="stylesheet" href="/static/css/subscription.css" />

근데 서버를 실행하면 html 파일은 인식해도 css 파일은 인식을 못했다.

수정 전 코드

<link rel="stylesheet" href="/static/css/subscription.css" />

수정 후 코드

<link rel="stylesheet" href="/css/subscription.css" />

원인 : css 파일의 경로 문제였다.

spring boot는 정적 리소스 파일(css, js, 이미지)을 제공할 때 static, public, resources, META-INF/resources 디렉토리의 파일을 웹 루트 경로(/) 아래에 자동으로 매핑한다.

[참고 : https://spring.io/blog/2013/12/19/serving-static-web-content-with-spring-boot]

즉, src/main/resources/static 폴더를 정적 리소스의 루트 경로로 설정하는 것이다.

그래서 /static/css 폴더 밑에 위치한 css 파일은 /static/css가 아니라 /css 로 매핑 해주어야 한다.

(css/style.css가 아니라 /css/style.css 라고 설정 해주어야 한다!)

수정 후 코드로 설정하면 정상적으로 css 파일 경로를 불러와서 html 화면에 적용된다!

error-thymeleaf 적용 시 whitelabel error page가 나와요.

주다애 — Fri, 27 Dec 2024 10:47:54 +0900

상황 : spring 프로젝트 시에 thymeleaf로 화면을 구성하고 서버를 올렸다.
그리고 localhost:8080/{내 html 파일 이름}.html을 하니 whitelabel error page를 마주하게 되었다.

해결

일단 확인할 것은 다음과 같다.

build.gradle

implementation 'org.springframework.boot:spring-boot-starter-thymeleaf'
implementation 'org.springframework.boot:spring-boot-starter-web'

applicaton.yml

# Thymeleaf 설정
spring:
  thymeleaf:
    prefix: classpath:/templates/
    suffix: .html
    cache: false

두 개 모두 적절히 설정이 되었다면

다음을 확인하자

MvcConfiguration.class

@Configuration
public class MvcConfiguration implements WebMvcConfigurer {

	@Override
	public void addResourceHandlers(final ResourceHandlerRegistry registry) {
		registry.addResourceHandler("/**")
			.addResourceLocations("classpath:/templates/", "classpath:/static/")
			.setCacheControl(CacheControl.maxAge(10, TimeUnit.MINUTES));
	}
}

나는 templates 폴더 밑에 html을 작성했다.

위의 설정 클래스를 만들어주어야 하는 이유는 다음과 같다.

설정하기 전에는 static 폴더의 html 파일을 불러온다.
그래서 templates 폴더의 html 파일을 불러오게 만들어야 한다.(addResourceLocations("classPath:/templates/")

이렇게 해주면 서버가 올라가고 정상적으로 html 파일에 접근하게 되어 화면이 나오게 된다!

참고 자료

https://devzzi.tistory.com/16

[Spring Boot] thymeleaf 사용하기 (1) - thymeleaf 초기 설정하기 | templetes 폴더에서 정적 파일 불러오기 |

[Spring] thymeleaf 사용하기 (1) thymeleaf 기초 설정 - templetes 폴더에서 정적 파일 불러오기 -View Mapping Controller 생성 Thymeleaf 란? - spring 기반 웹 애플리케이션의 view에서 html, xml, javascript, css, text 처리 후

devzzi.tistory.com

@Component만 사용하면 안되나요?

주다애 — Thu, 12 Dec 2024 13:48:23 +0900

약간의 사견이 들어있는 글입니다.

@Component

@Component 어노테이션은 Spring Context에 Bean(빈)을 추가하는 방식이다.

스프링 컨텍스트에 빈을 추가하는 것은 스프링이 관리해야 하는 객체를 인식하게 하는 것이다.

즉, 스프링 컨텍스트에 빈을 추가해야 스프링이 객체를 볼 수 있게된다.(그 후 객체 간의 의존성 설정이라던지 메소드 호출이라던지 다양한 기능을 수행할 수 있다.)

그 방법 중 하나가 @Component 어노테이션을 사용하는 것이다.

간단히 과정을 설명하면

@Component
@Getter
@Setter
public class Parrot {
    private String name;
} // Parrot.class

@Configuration
@ComponentScan(basePackages = "com.spring.study.component")
public class ProjectConfig {
} // ProjectConfig.class

public class ComponentMain {
    public static void main(String[] args) {
        var context = new AnnotationConfigApplicationContext(ProjectConfig.class);
        Parrot p = context.getBean(Parrot.class);
        p.setName("앵무새");
        System.out.println(p);
        System.out.println(p.getName());
    }
} // ComponentMain.class

빈으로 만들 클래스에 @Component 어노테이션을 추가한다.
@ComponentScan 어노테이션으로 스프링이 @Component 어노테이션이 추가된 클래스를 찾을 수 있게 한다. 이 때 basePackages의 속성으로 해당 빈(Parrot)이 위치한 정확한 패키지 명을 작성해주어야 한다.
Main 클래스에서 스프링 컨텍스트가 빈을 생성하고 추가하는 것을 확인한다.

빈이 제대로 등록되었음을 알 수 있다.

@Component 어노테이션은 가장 일반적인 형태의 어노테이션으로 특정 역할에 종속되지 않는 일반적인 스프링 빈을 생성할 때 사용한다.

다른 어노테이션은 없나?

@Service, @Repository, @Controller와 같은 어노테이션을 통해 스프링 빈을 등록할 수 있다.

@Service

@Serivce 어노테이션은 서비스 레이어에 해당하는 클래스에서 사용한다.

"이 클래스는 비즈니스 로직을 처리하는 서비스이다."라는 의미를 담고 있다.

@Repository

@Repository 어노테이션은 데이터 접근 계층 클래스에서 사용된다.

"이 클래스는 데이터베이스와의 상호작용을 담당한다."라는 의미를 담고 있다.

@Controller

@Controller 어노테이션은 웹 컨트롤러 클래스에서 사용한다.

"이 클래스는 HTTP 요청과 응답을 처리한다."라는 의미를 담고 있다.

Spring MVC에서 모델 객체를 만들어서 데이터를 담고 뷰를 반환한다.

필자도 그렇고 다양한 Spring 프로젝트를 보면 위의 세 개의 어노테이션을 거의 사용하는 것을 볼 수 있다.

@Component만 사용하면 안되나요?

다시 질문으로 돌아가서 스프링 빈으로 등록하기 위해 @Component 어노테이션만 사용하면 안되나요?에 대한 대답을 해보자.

그러지 말자..!

1️⃣ 의미의 명확성 부족

모든 빈에 @Component 어노테이션을 붙이면 클래스의 역할을 파악하기 힘들다.

각 클래스의 역할을 표현하는 다른 어노테이션(@Service 등등)이 있음에도 사용하지 않는 것은 좋은 선택은 아닌 듯하다.

2️⃣ 특화된 기능 부족

@Service, @Repository, @Controller 에는 각각 고유한 기능이 포함되어 있다.

@Repository로 예를 들어 보자
@Repository는 데이터 계층에서 발생하는 예외 처리에 특화되어 있다.
PersistenceExceptionTranslationPostProcessor는 예외를 DataAccessException으로 변환한다.
그럼 스프링은 데이터 접근 계층의 예외를 일관된 스프링의 데이터 접근 예외(DataAccessException)으로 처리할 수 있다.
해당 어노테이션을 사용하면 PersistenceExceptionTranslationPostProcessor가 자동으로적용된다.

즉, 데이터베이스에 종속적이지 않은 기술 독립적이고 일관된 예외 처리가 가능해지는 것이다.
@Controller로 예를 들어보자
Spring 5 및 Spring Boot 2.x 이전에는 @Component + @RequestMapping 조합으로 웹 요청 처리 핸들러로 해당 클래스를 등록할 수 있었다.
즉, @Controller 없이도 HTTP 요청 처리가 가능했다.(기본적으로 @Controller가 @Component를 확장한 구조였기 때문)

그런데 Spring 6(Spring Boot 3.x) 이후부터는 HTTP 요청 처리를 위한 핸들러로 등록할 때 반드시 @Controller나 @RestController를 사용해야 한다. 그렇지 않으면 HTTP 요청을 제대로 처리할 수 없다.

public class RequestMappingHandlerMapping extends RequestMappingInfoHandlerMapping
		implements MatchableHandlerMapping, EmbeddedValueResolverAware {
    ...
    @Override
    protected boolean isHandler(Class<?> beanType) {
		// 컨트롤러 애너테이션인지 확인	
        return AnnotatedElementUtils.hasAnnotation(beanType, Controller.class);
    }
    ...
}

3️⃣ 유지 보수의 어려움

클래스가 많아질수록 @Component만 사용하면 클래스 역할을 구분하기 어려워 유지 보수의 어려움이 생긴다.

의미적 명확성 부족과도 일맥상통하는 부분이다.

프로젝트의 구조가 복잡해질수록 @Component만 사용하면 클래스의 역할을 파악하기 어려워진다.

유틸리티 클래스나 특정 기능과 관련되지 않은 일반적인 구성 요소를 스프링 빈으로 등록할 때 @Component 어노테이션을 사용하자

동일성과 동등성

주다애 — Tue, 3 Dec 2024 12:00:26 +0900

‍♂️ 동일성(Identity)

동일성은 두 객체가 메모리 상에서 같은 객체인지 비교하는 개념이다.

즉, 동일성은 두 객체가 메모리에서 동일한 위치를 참조하는지 의미한다.

"==" 연산자를 사용하여 비교한다.

즉, "==" 연산자는 객체의 참조(레퍼런스)를 비교한다. 객체의 값이 같아도 항상 true를 반환하는 것은 아닌 것이다.

대신 기본 타입에 대해서는 "==" 연산자를 사용하면 값을 비교한다.

public static void main(String[] args) {
    Coffee coffee1 = new Coffee(100);
    Coffee coffee2 = new Coffee(100);
    System.out.println(coffee1 == coffee2); // false
}

두 Coffee 객체는 같은 값(100)을 가지지만 다른 객체이기 때문에(참조 값이 다르므로) 메모리 상에서 다른 위치를 참조할 것이고 즉 동일성 비교에서는 false가 반환된다.

public static void main(String[] args) {
    Coffee coffee1 = new Coffee(100);
    Coffee coffee2 = new Coffee(100);
    Coffee coffee3 = coffee1;

    System.out.println(coffee1 == coffee3); // true
}

위와는 다르게 coffee3 객체는 coffee1과 같은 참조 값를 가진다. 그래서 동일성 비교를 하면 같다고 의미하는 true가 반환된다.

‍♀️ 동등성(Equality)

동등성은 객체의 내용(값)을 비교하는 개념이다.

즉, 동등성은 객체의 값이 같은지를 의미한다.

equals() 메소드를 사용하여 비교한다.

두 객체의 값을 equals() 메소드를 사용해 비교했을 때 내용이 같으면 true, 다르면 false를 반환한다.

public static void main(String[] args) {
    Coffee coffee1 = new Coffee(100);
    Coffee coffee2 = new Coffee(100);
    Coffee coffee3 = coffee1;

    System.out.println(coffee1.equals(coffee2)); // false. 왜일까?
}

방금 전의 설명과는 다르게 coffee1과 coffee2를 동등 비교 했을 때 false가 나왔다. 두 객체의 내용이 같은데 왜그럴까?

문자열(String)이 아닌 다른 객체를 비교할 때 동등 비교를 하려면 equals() 메소드를 오버라이딩 해서 사용해야 한다.

위 Coffee 객체의 동등 비교를 하려면 Coffee 클래스에서 equals() 메소드를 오버라이딩해야 한다.

그렇지 않으면 Object 클래스의 equals() 메소드를 사용하기 때문에 비교할 대상이 객체인 경우 객체 주소를 이용해서 비교한다.

즉, 객체를 비교하는 경우 "==" 연산자와 차이가 없다는 것이다.

public class Coffee {
    private int price;

    public Coffee(int price) {
        this.price = price;
    }

    @Override
    public boolean equals(Object o) {
        if (this == o)
            return true;
        if (o == null || getClass() != o.getClass())
            return false;
        Coffee coffee = (Coffee)o;
        return price == coffee.price;
    }

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

우리는 객체의 값을 비교하기 위해 equals()메소드를 오버라이딩했다.

(hashCode() 메소드도 함께 오버라이딩 했는데 이건 다음 포스팅에서 알아보겠다 )

public static void main(String[] args) {
    Coffee coffee1 = new Coffee(100);
    Coffee coffee2 = new Coffee(100);
    Coffee coffee3 = coffee1;

    System.out.println(coffee1.equals(coffee2)); // true
}

그럼 이렇게 true가 반환된다! 우리가 원하는대로 객체의 값을 비교하는 동등 비교를 한 것이다.

문자열(String)의 객체 비교

문자열(String) 클래스는 equals() 메소드가 오버라이딩 되어 있다.

위에서 우리는 문자열(String)이 아닌 다른 객체를 비교할 때 동등 비교를 하려면 equals() 메소드를 오버라이딩 해서 사용해야 한다. 라고 이야기 했다.

public boolean equals(Object anObject) {
    if (this == anObject) {
        return true;
    }
    return (anObject instanceof String aString)
            && (!COMPACT_STRINGS || this.coder == aString.coder)
            && StringLatin1.equals(value, aString.value);
}

String 클래스 내부에 이렇게 equals() 메소드가 재정의 되어있다.

그래서 우리가 오버라이딩을 해주지 않아도 .equals() 비교를 하면 동등 비교가 되는 것이다.

또한 String은 객체인데 "==" 비교를 했을 때 두 값이 같으면 true를 반환한다.

public static void main(String[] args) {
    String str1 = "Hello World!";
    String str2 = "Hello World!";
    System.out.println(str1 == str2); // true
}

그 이유는 문자열 리터럴은 문자열 상수 풀(String Constant Pool)에서 관리된다. 그래서 동일한 리터럴은 재사용된다.

즉 동일한 문자열 리터럴에 대해서 "==" 비교를 하면 같다고 판단하고 true를 반환하는 것이다.

그런데 new 키워드를 사용해서 문자열을 생성하면 매번 다른 객체를 생성한다. 그래서 같은 문자열이라도 서로 다른 객체가 된다.

public static void main(String[] args) {
    String str1 = "Hello World!";
    String str2 = "Hello World!";
    String str3 = new String("Hello World!");
    String str4 = new String("Hello World!");

    System.out.println(str1 == str3); // false
    System.out.println(str4 == str3); // false
}

그래서 str3과 str4는 서로 다른 객체이므로 "==" 비교를 하면 false가 반환되는 것이다.

즉, 우리는 문자열 비교를 할 때 항상 equals() 메소드를 사용하는 것이 동등성 비교를 위해 좋은 선택이다.

[JPA] ID 생성 전략

주다애 — Fri, 29 Nov 2024 15:30:36 +0900

JPA의 ID 생성 전략

JPA는 직접 할당과 자동 할당을 통해 ID를 생성한다.

먼저, 직접 할당 방식은 @Id 어노테이션을 사용한다. 이 때 다른 어노테이션은 함께 사용하지 않고 기본키를 할당한다.

데이터베이스가 아니라 애플리케이션에서 기본 키를 직접 할당한다.

@Id
@Column(name = "ID")
private String id;

기본 키 직접 할당 전략은 em.persist()로 엔티티를저장하기 전에 기본 키를 직접 할당한다.

Book book = new Book();
book.setId("id1"); // 기본 키 직접 할당
em.persist();

그럼 기본키를 직접 할당하지 않고 데이터베이스에서 생성하주는 값을 사용하려면 어떻게 매핑해야 할까?

데이터베이스마다 기본 키를 생성하는 방식이 다르기 때문에 해당 문제를 해결하기 쉽지 않다.

JPA는 데이터베이스 기본 키 전략을 제공한다.

자동 할당

JPA에서 제공하는 데이터베이스 기본 키 생성 전략은 IDENTITY, SEQUENCE, TABLE, AUTO 전략이 있다.

기본 키 자동 할당은 @Id와 @GeneratedValue 어노테이션을 함께 사용한다.

하나씩 살펴보자

1️⃣ IDENTITY 전략

IDENTITY 전략은 기본 키 생성을 데이터베이스에 위임하는 전략이다.

주로 MySQL, PostgreSQL. SQL Server, DB2에서 사용하는 전략이다.

MySQL에서는 AUTO_INCREMENT 기능을 사용해서 기본 키 생성을 MySQL에게 넘긴다.

CREATE TABLE BOOK (
	ID INT NOT NULL AUTO_INCREMENT PRIMARY KEY;
   	TITLE VARCHAR(255)
 );

이런 식으로 작성하면 ID 값을 직접 작성해주지 않아도 값이 저장될 때 자동으로 순서대로 ID값을 작성해준다.

@Id
@GeneratedValue(strategy = GenerationType.IDENTITY)
private Long id;

이렇게 속성 값을 GenerationType.IDENTITY로 지정해주면 된다.

그러면 JPA는 기본 키 값을 얻어오기 위해서 데이터베이스를 추가로 조회한다.

IDENTITY 전략에서 중요한 점은 데이터베이스에 값을 저장하고 나서야 기본 키 값을 구할 수 있다는 것이다.

즉, 엔티티에 식별자 값을 할당하기 위해서 JPA가 데이터베이스를 추가로 조회해야 한다는 의미이다.

엔티티가 영속 상태가 되려면 식별자는 필수이다.

그런데 방금 설명했듯 IDENTITY 전략에서는 데이터베이스에 엔티티가 저장되어야 식별자를 구할 수 있어서 em.persist()를 호출하는 즉시 INSERT SQL이 데이터베이스에 전달된다.

따라서 IDENTITY 전략은 트랜잭션을 지원하는 쓰기 지연이 동작하지 않는다.

2️⃣ SEQUENCE 전략

SEQUENCE 전략은 유일한 값을 순서대로 생성하는 시퀀스를 사용해서 기본 키를 생성하는 전략이다.

데이터베이스 시퀀스란 유일한 값을 자동으로 생성하는 객체이다.

오라클, PostgreSQL, DB2, H2 데이터베이스에서 사용할 수 있다.

CREATE TABLE BOOK (
    ID BIGINT NOT NULL PRIMARY KEY,
    TITLE VARCHAR(255)
)

// 시퀀스 생성
CREATE SEQUENCE BOOK_SEQ START WITH 1 INCREMENT BY 1;

이렇게 시퀀스를 직접 생성한 후 엔티티와 매핑해야 한다.

@Entity
@SequenceGenerator(
        name = "BOOK_SEQ_GENERATOR",
        sequenceName = "BOOK_SEQ", // 매핑할 데이터베이스 시퀀스 이름
        initialValue = 1,
        allocationSize = 1
)
public class BOOK {
    @Id
    @GeneratedValue(strategy = GenerationType.SEQUENCE,
    generator = "BOOK_SEQ_GENERATOR")
    private Long id;
}

@SequenceGenerator를 사용해서 시퀀스 생성기를 등록하면 JPA는 이 시퀀스 생성기를 실제 데이터베이스의 시퀀스와 매핑한다.

그리고 속성 값을 GenerationType.SEQUENCE로 지정해주면 된다.

IDENTITY 전략과 SEQUENCE 전략의 차이

얼핏보면 비슷해 보이지만 차이가 존재한다.

SEQUENCE 전략은 em.persist()를 호출할 때 먼저 데이터베이스 시퀀스를 사용해서 식별자를 조회한다.

그리고 조회한 식별자를 엔티티에 할당한 후 엔티티를 영속성 컨텍스트에 저장한다.

이후 트랜잭션을 커밋해서 플러시가 일어나면 엔티티를 데이터베이스에 저장한다.

IDENTITY 전략은 엔티티를 데이터베이스에 저장한 후 식별자를 조회해서 엔티티에 할당했다.

3️⃣ TABLE 전략

TABLE 전략은 키 생성 전용 테이블을 만들어 그곳에 이름과 값으로 사용할 칼럼을 만들어 시퀀스를 흉내내는 전략이다.

테이블을 사용하기 때문에 모든 데이터베이스에 적용할 수 있다.

CREATE TABLE MY_SEQUENCES (
    SEQUENCE_NAME VARCHAR(255) NOT NULL,
    NEXT_VAL BIGINT
    PRIMARY KEY (SEQUENCE_NAME)
)

위와 같이 직접 MY_SEQUENCES라는 시퀀스 역할을 하는 테이블을 만들어서 사용한다.

@Entity
@TableGenerator(
        name = "BOOK_SEQ_GENERATOR",
        table = "MY_SEQUENCE",
        pkColumnValue = "BOOK_SEQ",
        initialValue = 1,
        allocationSize = 50
)
public class Book {
    @Id
    @GeneratedValue(strategy = GenerationType.TABLE,
    generator = "BOOK_SEQ_GENERATOR")
    private Long id;
}

@TableGenerator 를 사용해서 테이블 키 생성기를 등록한다.

그리고 테이블 키 생성기(BOOK_SEQ_GENERATOR)와 위에서 생성한 MY_SEQUENCES 테이블을 키 생성용 테이블로 매핑했다.

그리고 속성 값을 GenerationType.TABLE로 지정해주면 된다.

TABLE 전략은 따로 시퀀스 역할을 하는 테이블을 사용한다는 것만 제외하면 SEQUENCE 전략과 내부 동작 방식은 같다.

하지만 TABLE 전략은 값을 조회하면서 SELECT 쿼리를 사용하고 + UPDATE 쿼리를 통해 다음 값으로 증가시키므로 SEQUENCE 전략보다 데이터베이스와 한 번 더 조회하는 단점이 있다. 하지만 데이터베이스 종류를 타지 않기 때문에 그 점은 장점으로 볼 수 있다.

4️⃣ AUTO 전략

AUTO 전략은 데이터베이스 방언에 따라 IDENTITY, SEQUECNE, TABLE 전략 중 하나를 자동으로 선택하는 전략이다.

데이터베이스 종류에 따라 기본 키 자동 생성 전략이 가능한 방언도 있고 그렇지 않은 방언도 있었지만 AUTO 전략은 데이터베이스 방언에 따라 전략 중 하나를 자동으로 선택한다.

그래서 데이터베이스를 변경해도 코드를 수정할 필요가 없다는 장점을 가지고 있다.(개발 초기 단계에 특히 편하다.)

@Entity
public class Book {
    @Id
    @GeneratedValue(strategy = GenerationType.AUTO)
    private Long id;
}

이렇게 속성 값을 GenerationType.AUTO로 지정해주면 된다.

기본 키 매핑 전략 정리

영속성 컨텍스트는 엔티티를 식별자 값으로 구분하므로 엔티티를 영속 상태로 만드려면 식별자 값이 반드시 있어야 한다.

직접 할당 : em.persist()를 호출하기 전에 애플리케이션에서 직접 식별자 값을 할당한다.
IDENTITY : 데이터베이스에 엔티티를 저장해서 식별자 값을 획득한 후에 영속성 컨텍스트에 저장한다. 데이터베이스에 엔티티 저장이 선행되어야 한다.
SEQUENCE : 데이터베이스 시퀀스에서 식별자 값을 획득한 후 영속성 컨텍스트에 저장한다. 그 후 엔티티를 데이터베이스에 저장한다.
TABLE : 데이터베이스 시퀀스 생성용 테이블에서 식별자 값을 획득한 후 영속성 컨텍스트에 저장한다.

이렇게 자동 생성 전략을 사용해서 식별자를 선택해도 되고, 자연 키(NATURAL KEY)를 기본 키로 선택할 수도 있다.(주민번호, 이메일, 전화번호 등)

어쨌든 기본 키는 NULL이 아니고 + 유일해야 하고 + 변하지 않아야 한다.

참고 자료

도서 : 자바 ORM 표준 JPA 프로그래밍(김영한 지음)

얕은 복사와 깊은 복사

주다애 — Wed, 27 Nov 2024 13:50:11 +0900

자바에서의 객체 복사

자바에서의 객체 복사는 얕은 복사와 깊은 복사가 존재한다.

둘의 차이를 알아보자

사용할 예제는 다음과 같다.

import java.util.Objects;

class Book {

	private String name; // 책 이름
	private Author author; // 저자

	public Book(String name, Author author) {
		this.name = name;
		this.author = author;
	}

	public Book shallowCopy() { // 얕은 복사
		return new Book(this.name, this.author);
	}

	public Book deepCopy() { // 깊은 복사
		Author copiedAuthor = new Author(this.author.getName());
		return new Book(this.name, copiedAuthor);
	}

	public void changeAuthor(String name) { // 저자 이름 변경
		author.setName(name);
	}

	@Override
	public String toString() {
		return "Book name : " + name + ", " + author;
	}

	static class Author {

		private String name; // 저자 이름

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

		public String getName() { // 저자 이름 반환
			return name;
		}

		public void setName(String name) { // 저자 이름 변경
			this.name = name;
		}

		@Override
		public String toString() {
			return "Author : " + name;
		}
	}

	@Override
	public boolean equals(Object o) {
		if (this == o)
			return true;
		if (o == null || getClass() != o.getClass())
			return false;
		Book book = (Book)o;
		return Objects.equals(name, book.name) && Objects.equals(author, book.author);
	}

	@Override
	public int hashCode() {
		return Objects.hash(name, author);
	}

	public static void main(String[] args) {
		Author author1 = new Author("조슈아 블로크");
		Book book1 = new Book("이펙티브 자바", author1);

		// 얕은 복사 후 변경
		Book shallowCopyBook = book1.shallowCopy();
		shallowCopyBook.changeAuthor("Joshua Bloch");

		// 얕은 복사 결과 출력
		System.out.println("After shallow copy and change:");
		System.out.println("Original book1: " + book1);
		System.out.println("Shallow copied book: " + shallowCopyBook);

		System.out.println("book1's hashcode: " + book1.hashCode());
		System.out.println("shallowCopyBook's hashcode: " + shallowCopyBook.hashCode());
		System.out.println("book1's author's hashcode: " + book1.author.hashCode());
		System.out.println("shallowCopyBook's  author's hashcode: " + shallowCopyBook.author.hashCode() + "\n");

		Author author2 = new Author("마틴 파울러");
		Book book2 = new Book("리팩터링", author2);

		// 깊은 복사 후 변경
		Book deepCopyBook = book2.deepCopy();
		deepCopyBook.changeAuthor("Martin Fowler");

		// 깊은 복사 결과 출력
		System.out.println("After deep copy and change:");
		System.out.println("Original book2: " + book2);
		System.out.println("Deep copied book: " + deepCopyBook);

		System.out.println("book2's hashcode: " + book2.hashCode());
		System.out.println("deepCopyBook's hashcode: " + deepCopyBook.hashCode());
		System.out.println("book2's author's hashcode: " + book2.author.hashCode());
		System.out.println("deepCopyBook's  author's hashcode: " + deepCopyBook.author.hashCode());
	}
}

조금은 복잡해 보이지만 프린트 문이 길어서 그렇다.

하나씩 살펴보자

얕은 복사

자바의 얕은 복사는 복사 대상 객체의 참조(주소값)만 복사한다.

즉, 원본과 복사본이 같은 힙(Heap)의 데이터를 바라보는 것이다.(객체를 생성하면 힙 영역에 객체의 값이 올라간다.)

public Book shallowCopy() { // 얕은 복사
    return new Book(this.name, this.author);
}

여기서 Book 객체는 new를 통해 새로 만들어 주었지만 Author 객체는 기존의 값과 같은 참조를 가진다.

shallowCopy()를 사용해서 얕은 복사를 실행하면

Author author1 = new Author("조슈아 블로크");
Book book1 = new Book("이펙티브 자바", author1);

// 얕은 복사 후 변경
Book shallowCopyBook = book1.shallowCopy();
shallowCopyBook.changeAuthor("Joshua Bloch");

book1 객체와 shallowCopyBook 객체가 같은 Author 참조값을 가지게되는 것이다.

그래서 shallowCopyBook에서 changeAuthor() 메소드를 통해 저자 이름을 바꾸게 되면 book1 객체에도 영향을 준다.

둘은 같은 Author 객체를 공유하기 때문이다.

결과 값을 출력하면

둘의 저자 이름이 모두 같은 값으로 변경됐다.

이렇게 Author 값이 둘 다 변경된 것을 알 수 있다.

equals()와 hashCode() 메소드를 오버라이딩해서 해시 코드 값이 같은지도 살펴보면

같은 해시 코드를 가진다.

둘의 Author 객체는 같은 해시 코드 값을 가짐을 알 수 있다.

동일성 비교를 해도

System.out.println(book1.author == shallowCopyBook.author);

같음을 확인할 수 있다.

깊은 복사

자바의 깊은 복사는 원본이 참조하고 있는 힙의 데이터까지 복사한다.

즉, 원본과 복사본이 서로 다른 객체를 참조하므로 원본의 변경이 복사본의 변경에 영향을 주지 않는다.

public Book deepCopy() { // 깊은 복사
    Author copiedAuthor = new Author(this.author.getName());
    return new Book(this.name, copiedAuthor);
}

deepCopy() 메소드를 살펴보면 new를 통해 새로운 Author 객체(copiedAuthor)를 생성하고 그 후 new를 통해 새로운 Book 객체를 리턴해주고 있다.

그래서 deepCopy() 를 통해 deepCopyBook 객체를 만들고 changeAuthor() 메소드를 통해 저자 이름을 바꾸게 되면 book2 객체에 영향을 주지 않는다.

애초에 각각 다른 Author 주소값을 가리키고 있기 때문이다.

결과 값을 출력하면

저자 이름이 복사본만 변경됐다.

이렇게 변경을 한 복사본의 저자 이름만 변경된 것을 알 수 있다.

equals()와 hashCode() 메소드를 오버라이딩해서 해시 코드 값이 다른지도 살펴보면

다른 해시 코드를 가진다.

둘의 Author 객체는 다른 해시 코드 값을 가짐을 알 수 있다.

동일성 비교를 해도 당연히 false를 리턴한다.

clone 메소드

Object.clone() 메소드는 인스턴스 객체의 복제를 위한 메소드로 해당 인스턴스를 복제해서 새로운 인스턴스를 생성하여 그 참조값을 반환한다.

clone() 메소드를 사용하기 위해서는 Cloneable 인터페이스를 구현해야 한다.(implements Cloneable)

그 후 해당 클래스에서 clone() 메소드를 오버라이딩 하면 된다.

예를 들어서 Book 클래스가 Cloneable 인터페이스를 구현하고 그 안에 clone() 메소드가 오버라이딩 되어있다고 하면

// 깊은 복사(deep copy)
Book book = new Book();
book.setName("책책");
Book copiedBook = (Book) book.clone();

book 객체와 copiedBook은 다른 힙 영역을 참조한다. 둘은 당연히 다른 해시 코드를 가진다.

기억해야 할 점은

데이터 clone의 핵심은 원시 타입이 아닌 클래스를 복사할 일이 있을 경우 clone() 메소드를 꼭 오버라이딩 해야한다는 것이다. 그래야 깊은 복사를 수행할 수 있다.

다루는 데이터가 참조 타입인 경우 clone() 메소드를 재정의해야 깊은 복사가 이루어진다.

참고 자료

https://inpa.tistory.com/entry/JAVA-%E2%98%95-Object-%ED%81%B4%EB%9E%98%EC%8A%A4-clone-%EB%A9%94%EC%84%9C%EB%93%9C-%EC%96%95%EC%9D%80-%EB%B3%B5%EC%82%AC-%EA%B9%8A%EC%9D%80-%EB%B3%B5%EC%82%AC

☕ 자바 clone 메서드 재정의 (얕은 복사 & 깊은 복사)

clone 메소드 Object.clone() 메소드는 인스턴스 객체의 복제를 위한 메소드로, 해당 인스턴스를 복제하여 새로운 인스턴스를 생성해 그 참조값을 반환한다. 이러한 clone() 메소드를 사용하기 위해서

inpa.tistory.com

@NoargsConstructor(AccessLevel.PROTECTED)

주다애 — Tue, 26 Nov 2024 22:38:55 +0900

내 코드

@Entity
@Getter
@NoArgsConstructor(access = AccessLevel.PROTECTED)
@AllArgsConstructor(access = AccessLevel.PRIVATE)
@Builder(access = AccessLevel.PRIVATE)
public class Book { ... }

Book 엔티티 코드를 살펴보자. 도서 관련 백엔드 서비스이므로 당연히 Book 엔티티는 존재한다.

여기서 살펴볼 것은

@NoArgsConstructor(access = AccessLevel.PROTECTED)

이 부분이다.

왜 사용했나?

정말 솔직하게 말하면 이 프로젝트 이전 팀 프로젝트에서 팀원 분이 베이스 코드 작성 시에 위처럼 코드를 작성하셨다.

그 때는 내가 맡은 부분에만 정신이 팔려서 사실 저 코드 쓰임의 이유를 못 여쭤봤다.(내가 찾아봤어야 하는건데 말이다.)

그래서 좋은 게 좋은거지 라는 안일한 생각으로 버드북 프로젝트에 그대로 가져왔다.

그럼 왜 @NoArgsConstructor 어노테이션에 access 레벨을 proteced로 지정하는걸까?

@NoArgsConstructor

@NoArgsConstructor 어노테이션은 파라미터가 없는 디폴트 생성자를 생성하는 어노테이션이다.

즉, Book엔티티를 예시로 보면

public Book() {}

이 생성자를 알아서 만들어준다는 소리다.

JPA는 기본 스펙 상 기본 생성자를 요구한다. JPA는 리플렉션을 사용해서 내부적으로 엔티티를 생성하는데 이 때 동적으로 런타임 시점에 기본 생성자를 통해 클래스를 인스턴스화 한다.

즉, 직접 기본 생성자를 작성하든 어노테이션을 통해서 생성하든 해야한다는 소리다.

@NoArgsConstructor(access = AccessLevel.PROTECTED)

외부에서 무분별한 불완전한 객체 생성을 방지하기 위해 기본 생성자에 접근 제한을 건다.

그럼 일단 JPA를 사용하기 위해 기본 생성자가 필요하단 것은 이해했다.

그러면 왜 접근 제한을 두는걸까? 즉, AccessLevel을 왜 설정하는걸까?

외부에서 기본 생성자로 객체를 생성하는 것을 방지하기 위함이다.

기본 생성자 생성에 접근 제한을 걸지 않았을 때를 가정해보자

@Entity
@Getter
@NoArgsConstructor
public class Book { ... }

이렇게 되면 외부에서 기본 생성자를 통해 객체 생성이 자유로워진다.

그러면 아무런 필드 값을 가지지 못한 불완전한 Book 객체가 생성될 수 있고, 이는 비즈니스 로직이나 데이터베이스와의 상호작용에서 예외를 발생시킬 가능성이 높다.

또한, 완전한 객체를 만들기 위해서 setter를 함께 쓴다고 가정해보자.(위의 코드에서 @Setter 어노테이션을 추가했다고 가정한다.)

setter는 객체 생성 시 지양하는 방법이다. setXX()를 사용하면 어디든 객체의 값을 변경할 수 있다. 즉, 객체의 일관성을 유지하기가 어렵고 데이터베이스의 일관성 또한 깨지기 쉽다.

결국 기본 생성자에 접근 제한을 걸어서 외부에서 무분별한 불완전한 객체 생성을 방지하는 것이다.

access = AccessLevel.PROTECTED

접근 권한을 Protected로 설정하는 이유는 엔티티의 프록시 조회 때문이다.

위의 예시에서 접근 권한을 그냥 Public으로 해주면 안되는 이유를 살펴보았다.

그렇다면 왜 접근 권한이 Protected인가?

엔티티끼리 연관관계를 맺게되면 지연 로딩의 경우에 실제 엔티티가 아니라 프록시 객체를 조회한다.(프록시에 대해선 다음에 알아보자..)

암튼 JPA의 구현체는 실제 엔티티의 기본 생성자를 통해 프록시 객체를 생성한다.

이 때 접근 권한을 private으로 하면 프록시 객체를 생성할 수가 없다. 즉, 지연 로딩 시 값을 조회할 수가 없다.

결론은?

무분별한 객체 생성을 막고, 프록시 객체 생성을 통한 조회를 위해 기본 생성자 생성 @NoargsConstructor 어노테이션의 접근 제한은 Protected로 하자

고민할 지점을 알려주신 팀원 분께 감사드린다!

참고 자료

https://velog.io/@kevin_/%EB%82%B4%EA%B0%80-NoargsConstructor-access-AccessLevel.PROTECTED%EB%A5%BC-%EC%99%9C-%EC%9E%91%EC%84%B1%ED%96%88%EC%9D%84%EA%B9%8C

내가 @NoArgsConstructor (access = AccessLevel.PROTECTED)를 작성했던 이유

그 때 당시에는 Spring은 물론 Java에 대한 개념도 매우 약할 때라 지금도 약하지만레퍼런스의 코드를 가져다 사용하기에 급급했다.당시의 나는 해당 개념에 대한 정확한 이해보다는 기능 구현이

velog.io

https://erjuer.tistory.com/106

[JPA] Entity Class의 @NoargsConstructor (access = AccessLevel.PROTECTED)

실무에서 JPA를 활용하다보면 Entity 생성시 @NoargsConstructor (access = AccessLevel.PROTECTED) 이라는 Annotation을 붙여서 개발을 하게 된다. 이에 조금 더 정확히 이해하고자 이번 블로그 글로 언급하고자 한

erjuer.tistory.com

Servlet(서블릿) 이란?

주다애 — Tue, 26 Nov 2024 16:48:11 +0900

Servlet(서블릿)

Servlet(서블릿)은 Java 언어를 기반으로 하는 웹 애플리케이션 개발을 위한 기술로, 클라이언트의 요청에 따라 동적으로 서버에서 처리하는 자바 클래스이다.

서블릿은 동적 웹페이지를 만들 때 사용되는 자바 기반의 웹 애플리케이션 프로그래밍 기술이며 HTTP 프로토콜을 통해 클라이언트의 요청을 받고, 자바 코드를 통해 동적인 웹 페이지를 생성하거나 데이터를 처리해서 응답을 반환해준다.

서블릿 이전에는?

서블릿 이전의 초기 웹은 단순히 정적인 HTML 문서를 클라이언트에게 제공하는 방식이었다.

사용자가 서버에 HTML 파일을 요청하면 서버는 해당 HTML 문서를 그대로 전송한 것이다.

이를 통해 웹 페이지를 표시할 수는 있었지만, 사용자 맞춤형 데이터나 동적인 컨텐츠는 제공할 수 없었다.

(ex. 사용자가 로그인하면 이름을 표시하거나, 상품 검색 결과를 동적으로 보여줄 수 없었음)

이를 해결하기 위해서 나온 기술이 CGI(Common Gateway Interface)였다.

CGI는 웹 서버가 클라이언트의 요청을 받을 때마다 외부 프로그램을 실행해서 동적인 결과를 생성하고 이를 HTML로 반환했다. 즉, 동적인 컨텐츠 제공이 가능해진 것이다.

그런데, CGI의 치명적인 문제가 있는데 바로 각 요청마다 매번 새로운 프로세스를 생성한다는 것이다.(1요청 1프로세스)

즉, 리소스의 소모가 크고, 성능 이슈를 발생시키고 확장성도 부족했다.

그래서 나온 것이 바로 서블릿(Servlet)이라는 기술이다!

서블릿의 등장

위의 역사를 요약하자면

정적인 웹(초기) : 단순 HTML 파일만 제공. A 클라이언트와 B 클라이언트가 보는 화면 같음
CGI 도입 : 동적인 콘텐츠 제공이 가능하지만 리소스 낭비와 성능 문제 발생(1요청 1프로세스)
서블릿(Servlet) : Java 기반의 멀티 스레드 기술로 CGI의 문제를 해결하고 동적인 웬 애플리케이션 개발 가능하게 함

이렇게 해서 서블릿이라는 기술이 등장했다고 이해할 수 있다.

그럼 서블릿의 특징을 간단히 알아보자

1️⃣ 멀티 스레드 지원

서블릿은 각 클라이언트의 요청을 새로운 스레드로 처리하여 멀티 스레드를 지원한다.

CGI와 다르게 별도의 프로세스를 생성하는 것이 아니라 하나의 프로그램에서 여러 스레드가 작동한다.

그러면 프로그램은 하나만 켜져있고, 그 안에서 스레드들이 요청을 처리할 수 있어 성능 이슈를 줄인다.

2️⃣ Wirte Once, Run Anywhere

서블릿은 자바 언어로 작성되므로, 플랫폼 독립성을 가진다. 어떤 OS에서든 자바를 지원하는 서버 환경에서 실행 가능하다.

3️⃣ 영구적인 서버 프로그램

서블릿은 웹 애플리케이션이 실행되는 동안 서버에 지속적으로 유지된다.

요청마다 종료되는 CGI와 다르게 웹 애플리케이션이 실행되는 동안 서버에 유지되므로 속도와 성능이 더 뛰어나다.

4️⃣ 효율적인 자원 관리

서블릿은 웹 애플리케이션 시작 시 메모리에 로드되며 요청이 들어오면 해당 서블릿 객체가 재사용된다.(싱글톤으로 관리되는 서블릿 객체)

이런 특성으로 인해 초기화 비용이 줄어들고 서버 자원을 효율적으로 사용할 수 있다.

서블릿 동작 방식

그렇다면 서블릿은 어떻게 동작할까?

클라이언트 측에서 HTTP 요청을 보내면 HTTP 요청이 Servlet Container(서블릿 컨테이너)로 전송된다.
요청을 전송받은 서블릿 컨테이너는 HttpServletRequest, HttpServletResponse 객체를 생성한다.
web.xml을 기반으로 사용자가 요청한 URL이 어느 서블릿에 대한 요청인지 찾는다.
해당 서블릿에서 service 메소드를 호출한 후 클라이언트의 GET, POST 여부에 따라 doGet(), doPost()를 호출한다.
doGet(), doPost() 메소드는 동적 페이지를 생성하서 HttpServletResponse 객체에 응답을 담는다.(서블릿 컨테이너(WAS)가 객체에 담긴 내용으로 HTTP응답 정보를 생성해서 클라이언트에게 전달한다.)
응답이 끝난 후 생성한 HttpServletRequest, HttpServletResponse 객체를 소멸한다.

동작 과정을 코드로 살펴보자

import java.io.IOException;
import java.io.PrintWriter;

import jakarta.servlet.ServletException;
import jakarta.servlet.annotation.WebServlet;
import jakarta.servlet.http.HttpServlet;
import jakarta.servlet.http.HttpServletRequest;
import jakarta.servlet.http.HttpServletResponse;

@WebServlet("/hello")
public class HelloServlet extends HttpServlet {
	// GET 요청을 처리하는 메서드
	@Override
	protected void doGet(HttpServletRequest request, HttpServletResponse response)
		throws ServletException, IOException {

		// 응답의 Content-Type을 설정
		response.setContentType("text/html");

		// 클라이언트에게 데이터를 쓰기 위한 PrintWriter 객체 생성
		PrintWriter out = response.getWriter();

		// 응답으로 반환할 HTML 생성
		out.println("<html>");
		out.println("<head><title>Hello Servlet</title></head>");
		out.println("<body>");
		out.println("<h1>Hello, Servlet!</h1>");
		out.println("<p>This is a simple servlet example.</p>");
		out.println("</body>");
		out.println("</html>");

		// PrintWriter 닫기
		out.close();
	}
}

클라이언트의 요청이 GET인 경우의 코드이다. 이 때는 위의 설명과 같이 doGet() 메소드가 동작한다.

클라이언트가 http://localhost:8080/MyServletApp/hello 요청을 보내면 화면에 "Hello, Servlet!"이라는 메세지가 출력된 HTML 페이지가 표시된다.

서블릿 컨테이너(Servlet Container)

서블릿 컨테이너(Servlet Container)는 서블릿을 관리하는 컨테이너이다.

말 그대로 서블릿 컨테이너는 서블릿을 관리하는 컨테이너이다.

서블릿 컨테이너(Servlet Container)

서블릿을 생성했다고 해서 스스로 작동하는 것이 아니다. 누군가 서블릿을 관리해주어야 하는데 그 역할을 하는 것이 서블릿 컨테이너이다.

서블릿 컨테이너는 WAS(Web Application Server)로 클라이언트의 요청을 받고 응답할 수 있도록 웹 서버와 소켓으로 통신한다.

서블릿 컨테이너의 역할을 알아보자

1️⃣ 웹 서버와 통신 지원

서블릿 컨테이너는 서블릿과 웹 서버가 손쉽게 통신할 수 있도록 한다.

소켓을 만들고 listen, accept 등의 작동을 API로 제공하여 개발자가 서블릿에 구현해야 할 비즈니스 로직만 구현할 수 있게 해준다.

2️⃣ 서블릿 생명주기 관리

서블릿 컨테이너는 서블릿의 탄생과 죽음을 관리한다.

서블릿의 생명주기는 크게 3단계로 나눌 수 있다.

서블릿 생성 및 초기화
1. 서블릿 컨테이너가 애플리케이션이 처음 실행되거나 서블릿이 처음 요청될 땨 서블릿 객체를 최초 한 번만 생성한다.
2. 서블릿 객체가 생성되면 컨테이너가 init() 메소드를 호출해서 서블릿 객체를 초기화한다.
3. init() 메소드는 서블릿이 로드될 때 딱 한 번만 호출된다.
서블릿 요청 처리
1. 클라이언트의 HTTP 요청을 받을 때마다 service() 메소드를 호출한다.
2. service() 메소드는 클라이언트의 요청 유형에 따라 doGet(), doPost() 메소드를 호출한다.
3. 요청마다 새로운 스레드가 생성되어 처리한다.
4. 즉, 서블릿 객체는 싱글톤으로 관리되지만 요청 / 응답 데이터는 각 요청마다 독립적으로 처리된다.
서블릿 종료
1. 서블릿 컨테이너가 애플리케이션을 종료하거나 서블릿을 제거할 때 서블릿 객체를 메모리에서 해제한다.
2. destroy() 메소드를 호출한다. init() 메소드와 마찬가지로 한 번만 실행된다.
3. 컨테이너가 정상 종료될 때 destroy() 메소드가 호출된다.

@Override
public void init() throws ServletException {
    // 초기화 작업
    System.out.println("Servlet Initialized!");
}

@Override
protected void doGet(HttpServletRequest request, HttpServletResponse response) 
        throws ServletException, IOException {
    // GET 요청 처리
    response.getWriter().println("Handled GET request!");
}

@Override
protected void doPost(HttpServletRequest request, HttpServletResponse response) 
        throws ServletException, IOException {
    // POST 요청 처리
    response.getWriter().println("Handled POST request!");
}

@Override
public void destroy() {
    // 종료 작업
    System.out.println("Servlet Destroyed!");
}

3️⃣ 멀티 스레드 지원 및 관리

서블릿 컨테이너는 요청이 올 때 마다 새로운 자바 스레드를 생성하고 관리한다.

위에서 설명했듯 요청이 올 때 마다 각각 스레드 독립적으로 처리된다. 서버가 멀티 스레드를 생성 및 운영해주기 때문에 스레드 안정성도 보장된다.

4️⃣ 선언적 보안 관리

서블릿 컨테이너는 개발자가 보안에 관한 내용을 서블릿이나 자바 클래스에 구현하지 않아도 된다.

결국 서블릿은 클라이언트 요청을 처리하고 결과를 반환하는 자바 웹 프로그래밍 기술로 동적 웹페이지 생성 시 사용된다.

그리고 서블릿을 관리해주는 것이 서블릿 컨테이너이다.

참고 자료

https://jh2021.tistory.com/20

서블릿(Servlet)이 뭔지 궁금해?

자바 웹기술 역사는 서블릿 → JSP → (서블릿 + JSP) MVC 패턴 → 스트럿츠, 웹워크 -> 스프링 MVC 요런식으로 발전해왔어요. 요즘은 Spring WebFlux라는 서블릿 기반이 아닌 Web Reactive 기반을 이용하기도

jh2021.tistory.com

https://mangkyu.tistory.com/14

[JSP] 서블릿(Servlet)이란?

1. Servlet(서블릿) 서블릿을 한 줄로 정의하자면 아래와 같습니다. 클라이언트의 요청을 처리하고, 그 결과를 반환하는 Servlet 클래스의 구현 규칙을 지킨 자바 웹 프로그래밍 기술 간단히 말해서,

mangkyu.tistory.com

[DB] Index란?

주다애 — Mon, 25 Nov 2024 13:02:06 +0900

Index(인덱스)

Index(인덱스)란 데이터베이스 테이블의 검색 속도를 향상시키기 위한 자료구조이다. 사전의 색인과 같다.

인덱스를 사용하면 데이터베이스에서 원하는 정보(레코드, 튜플)를 빠르게 조회할 수 있다.

인덱스는 튜플의 주소라고 생각하면 쉽다. (인덱스에 키를 대응시키고 튜플에 값을 대응시켜보자)

또한 인덱스는 정렬되어 있다.

인덱스를 이루는 자료구조

인덱스를 구현하기 위한 자료구조로 대표적인 것은 B-Tree와 해시 테이블이다.

1️⃣ B(Balanced)-Tree 인덱스

B-Tree는 데이터베이스의 인덱싱 알고리즘 가운데 가장 먼저 도입되고 가장 일반적으로 사용되는 알고리즘으로 트리 구조를 따른다.

(트리구조 : 루트 노드, 브랜치 노드, 리프 노드로 구성되는 형태)

트리의 리프 노드가 실제 데이터 레코드를 찾아가기 위한 주소 값(키 값)을 가지고 있다. 모든 노드들이 데이터를 가진다.

그리고 인덱스의 키 값은 빠른 탐색을 위해 정렬되어 있다.

하지만 키 값에 대응되는 레코드는 정렬 되어 있을 수도 있고 아닐 수도 있다.(대부분 RDMS에는 레코드들이 정렬되지 않고 저장된다.)

인덱스는 페이지 단위로 저장된다.(페이지? 디스크와 메모리에 대해 데이터를 읽고 쓰는 최소의 단위로 블록이라고도 한다.)

레코드를 찾는 순서를 간단하게 살펴보면

데이터를 따라서 리프노드에 도달하면 인덱스 키에 해당하는 레코드의 PK 값이 저장되어 있다.
이후 PK를 따라 리프노드에서 실제 레코드를 읽어온다.

위와 같다. 즉, 인덱스를 통해서 데이터를 조회하면 인덱스를 통해 PK를 찾고 PK를 통해 레코드를 찾는 2가지 작업이 수행되는 것이다.

그렇기 때문에 모든 테이블을 뒤져서 레코드를 찾는 것보다 레코드를 찾는 속도가 훨씬 빠르다.

2️⃣ 해시 테이블 인덱스

해시 테이블은 데이터를 Key : Value 쌍으로 저장하는 자료구조로, 빠른 데이터 검색이 필요할 때 유용하다.

key값을 이용해서 고유한 인덱스를 생성한 후, 그 인덱스에 저장된 값을 읽어오는 구조이다.

해시 테이블의 시간 복잡도는 O(1)로 매우 빠른 검색을 지원한다.

레코드를 찾는 순서를 간단하게 살펴보면

검색하고자 하는 값을 넘기면
해시 함수를 거쳐서 찾고자 하는 key 값이 포함된 버킷을 찾아내고
버킷 안에서 실제 레코드가 저장된 위치를 찾는 순서로 검색이 이루어진다.

그래서 트리 내의 여러 노드를 거쳐서 검색하는 B-Tree에 비해서 속도가 빠르다.

하지만 해시 테이블 자료구조는 동등 비교 검색에 최적화 되어있다.(DB 인덱스에서 해시 테이블이 사용되는 경우도 적다.)

만약 해시 함수의 값이 1이라도 달라지면 기존 해시 값과 완전히 다른 해시 값을 생성한다.

그렇기 때문에 부등호 연산이 자주 사용되는 데이터베이스 검색에는 적합하지 않다.

예시를 들어보면

동등 비교인 경우

"12345"라는 key를 가진 데이터를 해시 테이블에 저장했다고 가정하자

해시 함수는 "12345"를 입력받아 특정 인덱스(예: 7번 버킷)으로 매핑한다.
이제 "12345"를 검색할 대 해시 함수가 다시 같은 결과(7번 버킷)를 생성하므로 데이터는 곧바로 7번 버킷에서 검색된다.
즉, 해시 값의 일치 여부를 통해 빠르게 동등성을 확인한다.(O(1))

부등호 연산인 경우

"1", "2", "3", "4", "5"라는 키가 각각 다른 해시 값으로 변환되어 해시 테이블에 저장되어 있다고 가정하자

key "1" 해시 값: 12AB34

key "2" 해시 값: CDEF78

key "3" 해시 값: 9A1B2C

여기서 볼 수 있듯 key 값이 "1"에서 "2"로 단 1 증가했음에도 해시 값은 전혀 다른 값으로 변한다.

해시 함수는 입력 간의 순서와 크기는 고려하지 않고 고유한 해시 값을 생성하기 때문이다.

이 때 Key > 3 이라는 조건으로 검색한다고 하면
해시 함수는 key를 고유한 해시 값으로 변환하므로 키의 크기나 순서를 알 수 없다. 또한 key가 정렬되어 있지도 않다.
즉, 해시 테이블의 모든 데이터를 하나씩 확인해야 한다.(O(N))

3️⃣ B+-Tree 인덱스

B+-Tree 인덱스는 자식 노드가 2개 이상인 B-Tree를 개선한 자료구조이다.

B+-Tree 인덱스는 리프 노드만 인덱스와 함께 데이터를 가지고 있으며 다른 노드들은 인덱스만 가진다.

리프 노드들은 LinkedList로 연결되어 있어서 부등호를 이용한 순차 검색에 용이하다.

MySQL이 B+-Tree 구조를 가진다.

인덱스 스캔 방식

MySQL의 인덱스 스캔 방식에는 크게 인덱스 레인지 스캔, 인덱스 풀 스캔, 루스 인덱스 스캔이 있다.

1️⃣ 인덱스 레인지 스캔

인덱스 레인지 스캔은 검색할 인덱스 범위가 결정된 경우 사용되며 가장 빠른 스캔 방식이다.

SELECT * FROM EMPLOYEE WHERE NAME BETWEEN "Lemon" AND "Mango";

위와 같은 쿼리가 날아갔다고 해보자. 그리고 Employee 테이블의 name 칼럼에 인덱스가 걸려있다고 하자

쿼리의 실행 순서는

인덱스 탐색 : 인덱스의 조건을 만족하는 값이 저장된 시작 리프 노드를 찾는다.
인덱스 스캔 : 시작 리프 노드부터 필요한 만큼 인덱스를 순서대로 읽는다.
랜덤 I/O : 읽어들인 인덱스와 PK를 사용해서 최종 레코드를 읽는다.

2️⃣ 인덱스 풀 스캔

인덱스 풀 스캔은 처음부터 끝까지 페이지를 이동하며 모든 인덱스를 읽는 스캔 방식이다.

만약 인덱스가 A, B, C 순서로 되어있고 쿼리의 조건절이 B 또는 C 칼럼으로 검색되면 이 때 인덱스 풀 스캔이 사용된다.

인덱스 풀 스캔은 인덱스를 사용한다고 하지 않는다. 하지만 모든 데이터 레코드들을 읽는 풀 테이블 스캔보다는 인덱스만 스캔하는 인덱스 풀 스캔이 분명히 성능이 낫기 때문에 사용된다.

3️⃣ 루스 인덱스 스캔

루스 인덱스 스캔은 인덱스를 듬성듬성 읽는 스캔 방식이다.(위의 두 스캔 방식은 타이트 인덱스 스캔으로 분류)

중간에 필요하지 않은 인덱스 키 값은 무시하고 넘어간다.

Group by, max(), min() 함수에 대해 최적화 하는 경우에 사용된다.

참고 자료

https://mangkyu.tistory.com/286

[MySQL] B-Tree로 인덱스(Index)에 대해 쉽고 완벽하게 이해하기

인덱스를 저장하는 방식(또는 알고리즘)에 따라 B-Tree 인덱스, Hash 인덱스, Fractal 인덱스 등으로 나눌 수 있습니다. 일반적으로 B-Tree 구조가 사용되기 때문에 B-Tree 인덱스를 통해 인덱스의 동작

mangkyu.tistory.com

https://mangkyu.tistory.com/96

[Database] 인덱스(index)란?

1. 인덱스(Index)란? [ 인덱스(index)란? ] 인덱스란 추가적인 쓰기 작업과 저장 공간을 활용하여 데이터베이스 테이블의 검색 속도를 향상시키기 위한 자료구조이다. 만약 우리가 책에서 원하는 내

mangkyu.tistory.com