추측보다는 측정

[Jenkins Pipeline] Environment Setting

글을 쓰는 개발자 — Sun, 7 May 2023 17:05:19 +0900

간혹 Jenkins pipeline 내에서 환경변수를 저장하고 싶을 때가 있다.

상황을 예를 들어보자.

webhook 으로부터 "example,hello,world" 와 같이 ","가 seperator 형식인 String으로 전달되었다고 가정하자.

사용자 입장에서는 해당 값을 배열식으로 전달받고 싶을 것이다.

이 때, 배열로 변환하고 다음 stage에서 사용해야하는 상황에서 넘기는 방법은 다양하지만 가장 대표적인 방법은 환경변수로 저장하는 방법이 있다.

이에 대한 방법은 다음과 같다.

stage('set env') {
	steps {
    	script {
            def list = value.split(",")
            env.MY_LIST = list // <-- 환경변수에 저장하는 방법
        }
    }
}

간단하다.

env.YOUR_ENV_NAME = VALUE

Jenkins Pipeline Docker Usage

글을 쓰는 개발자 — Wed, 3 May 2023 08:30:18 +0900

Plugin Install

좌측에 Jenkins 관리 클릭
System Configuration > 플러그인 관리 클릭
좌측 Avaulable plugins 클릭 후 검색창에 Docker API Plugin 타이핑
checkbox 클릭 후 설치 진행

Docker Pipeline CLI

Credentials

일반적으로 Docker Pipeline CLI 를 쓰는 이유는 사내 docker registry 혹은 docker hub 에 이미지를 푸시하기 위해 사용된다. 그렇기에 해당 registry에 접근하기 위한 username & password 등록이 필요하다.

구성을 보면

Username
Password
ID

이렇게 존재하며 여기서 Username은 레지스트리 아이디, Password 는 레지스트리 비밀번호, ID는 젠킨스에서 사용할 키 이다.

키 등록 방법

Manage Credentials
System -> Global credentials <Default 일 경우> -> 우측에 Add Credentials 클릭 -> Kind ( Username with password) 설정 후 위에서 말한 Username, Password, ID 등록

pipeline


stage('docker registry access') {
    steps {
        script {
            docker.withRegistry("<DOMAIN>","<YOUR_CREDENTIALS_ID>") { // -- 1
                def dockerImage = docker.build("<DOMAIN>/<REPOSITORY>/<IMAGE_NAME>:<TAG>", " .") // -- 2
                dockerImage.push() // -- 3
            }
        }
    }
}

withRegistry

docker registry 접근하기 위해서는 로그인이 필요한 상황인데 이를 도와주는 인터페이스이다.
위에서 등록한 로그인하고자 하는 레지스트리 도메인은 좌측에, credentialsId 를 우측에 작성하면 된다.

docker.build("image 관련 정보 (이미지이름, 태그, 레지스트리 도메인, 레포지토리)", "빌드 시 추가적인 arg 명령어를 작성할 수 있는 곳")

대략적으로 다시 설명하자면 좌측에는 이미지 이름과 태그 등 어떻게 등록할 것인가에 대한 내용을, 우측에는 추가적인 명령어를 작성하고자 했을 때 사용하면 된다.

dockerImage.push()

build를 하게 되면 이미지 객체를 가지게 되는데 이에 대한 내용을 레지스트리에 등록하는 명령어이다.
여기서 push 안에 force 파라미터에 대한 boolean 값을 설정할 수 있는데 이는 제대로 동작하지 않는 것 같다. 기본적으로 force = true 이며 false 로 진행해도 true로 동작한다.

그래서 만일 force = true 의 동작을 미리 하고 싶다면 다음과 같이 구현하면 될 것 같다.

validation

stage('validate') {
    steps {
        script {
            docker.withRegistry('<DOMAIN>','<YOUR_CREDENTIALS_ID>') {
                def valid = false
                try {
                    sh "docker pull <IMAGE>:<TAG>"
                } catch(Exception e) {
                    valid = true
                }
                if (!valid) {
                    error("already ${IMAGE}:${TAG} exists")
                }
            }
        }
    }
}

원리는 간단하다. 푸쉬하고자 하는 image 와 tag 를 미리 레지스트리에 pull하여 해당 이미지 존재 유무를 판단하고 이에 대해서 error를 일으킬 것인지 아니면 그래도 동작하게 할 것인지 돌아가게 하면 된다.

[Reflections] 하위 클래스를 어떻게 하면 가져올 수 있을까?

글을 쓰는 개발자 — Wed, 22 Mar 2023 14:04:04 +0900

위 제목처럼 고민하게 된 계기는 다음과 같습니다.

서비스를 운영하면서 어떤 특정 클래스의 라인수가 길어지게 되고 해당 라인 수를 쪼개고 싶어지는 순간이 오게 됩니다.

예를 들어 설명해보겠습니다.

라면 레시피 관련 클래스가 있다고 생각해봅시다.

이 때 라면 종류는 다양합니다.

- 빨간 국물 라면

- 짜장 라면

- 짬뽕 라면

- 비빔면

- 불닭 볶음면

등 다양한 레시피가 존재합니다.

그리고 빨간 국물 라면의 종류도 다양합니다.

- 신라면

- 삼양라면

- 진라면

등 다양한 제품이 존재하게 됩니다.

이러한 정보를 하나의 클래스를 담는다고 생각해봅시다. 가령 다음과 같이 말이죠.

@Getter
@RequiredArgsConstructor
public enum RamenRecipe {
    RED_SHIN(RamenType.RED, Brand.N, "신라면"),
    // ...
    RED_SAM(RamenType.RED, Brand.S, "삼양라면");
    private final RamenType type;
    private final Brand brand;
    private final String description;
}

다음과 같이 적을 때는 별 문제가 없으며 description 이란 필드가 단순히 설명으로 되어 있으니 상관은 없지만

만일 description 대신

- receipe의 내용을 담고 있는 클래스를 맵핑

- suppier를 통해 라면을 생성하는 람다식

등 다양한 옵션이 붙게 되면 하나 하나의 enum의 크기가 커지게 되고 이러한 갯수가 많아지면 관리하기 힘들어진다는 단점이 존재합니다.

그랬을 때 내가 생각한 방안은 다음과 같습니다.

enum 필드에 대한 getterMethod 인터페이스 구성

public interface Recipe {
    RamenType getType();

    Brand getBrand();

    String getDescription();
}

각 관심사에 맞는 enum 클래스 생성

@Getter
@RequiredArgsConstructor
public enum SamRecipe implements Recipe{
    RED_SAM_1(RamenType.RED, Brand.S, "삼양라면"),
    RED_SAM_2(RamenType.RED, Brand.S, "삼양라면"),
    RED_SAM_3(RamenType.RED, Brand.S, "삼양라면"),
    RED_SAM_4(RamenType.RED, Brand.S, "삼양라면");
    private final RamenType type;
    private final Brand brand;
    private final String description;
}

@Getter
@RequiredArgsConstructor
public enum ShinRecipe implements Recipe{
    RED_SHIN_0(RamenType.RED, Brand.N, "신라면"),
    RED_SHIN_1(RamenType.RED, Brand.N, "신라면"),
    RED_SHIN_2(RamenType.RED, Brand.N, "신라면"),
    RED_SHIN_3(RamenType.RED, Brand.N, "신라면"),
    RED_SHIN_4(RamenType.RED, Brand.N, "신라면");
    private final RamenType type;
    private final Brand brand;
    private final String description;
}

aggregation class 구성

@NoArgsConstructor(access = AccessLevel.PRIVATE)
public final class RecipeAggregation {
    public static Collection<Recipe> values;
    private static final String PACKAGE_NAME = "com.vixx.springground.ramen";
    private static final Reflections reflections = new Reflections(PACKAGE_NAME);
    static {
        final List<Recipe> recipes = new LinkedList<>();
        reflections.getSubTypesOf(Recipe.class).forEach(clazz -> recipes.addAll(Arrays.asList(clazz.getEnumConstants())));
        values = recipes;
    }
}

테스트

    @Test
    void name() {
        final Collection<Recipe> values = RecipeAggregation.values;
        Assertions.assertThat(values.size()).isEqualTo(9);
        values.forEach(System.out::println);
    }

RED_SAM_1
RED_SAM_2
RED_SAM_3
RED_SAM_4
RED_SHIN_0
RED_SHIN_1
RED_SHIN_2
RED_SHIN_3
RED_SHIN_4

간단하지만 간혹 하위클래스를 가져오는 방법에 대해 고민하셨던 분들이라면 다음과 같은 방법도 고려하면 좋을 것 같아 작성해봤습니다.

읽으시면서 부족한 점이 있거나 수정할 부분이 있으면 댓글 부탁드립니다.

[Java] Thread 이해해보기

글을 쓰는 개발자 — Mon, 10 Oct 2022 08:34:07 +0900

글을 앞서 소개하기 앞서서 글을 적는 데 도움이 되었던 사이트 링크를 먼저 남깁니다.

https://bugs.openjdk.org/browse/JDK-8277131

https://github.com/spring-projects/spring-framework/issues/23443

https://spring.io/blog/2022/10/11/embracing-virtual-threads

Java Thread 의 변화

Loom Project 가 JDK 19 에 들어가면서 Virtual Thread, Concurrency 에 대한 내용이 추가가 되었다.

이전 버전에서의 Java 에서는 Virtual Thread 가 아닌 OS Thread를 생성하는 형식으로 구성되어 있었다.

기본적으로 Virtual Thread 특성은 가벼운 스레드로서 생성하는 비용을 많이 줄일 수 있다는 특성이 있으며 concurrent 애플리케이션의 높은 처리량이 관찰된다.

그렇다고 이번 패치는 자바의 concurrency model을 바꾸는 것은 아니며 병행처리에 대한 자바 model을 바꾸는 것은 아니다.

이유

기본적으로 자바는 멀티 스레드이며, 각각의 스레드는 지역 변수 저장하거나 메소드 call을 조정하기 위한 스택을 제공해줬다. 그 뿐만 아니라 Exception이 같은 스레드에서 나거나 했을 때 같은 context를 공유하며 개발자는 이를 통해 어떤 일이 일어났는 지 스레드의 call stack을 debugging 하는 데 용이한 구조를 가졌다.

기본적으로 서버 애플리케이션은 유저 요청에 따라 독립적으로 동시에 다루며, 이와 같이 구성하기 위해서는 해당 요청을 스레드와 묶어 하나의 스레드가 하나의 요청을 처리하도록 구성되어 있다.

이 말을 thread-per-request style 이라 하며 이러한 방식은 이해하기 쉬우며, 프로그램하기 쉽다.

Thread-Per-Request

서버 어플리케이션의 확장성은 Little's law 의해 처리되며, 해당 법칙은 latency, concurrency, 그리고 처리량과 관련되어 있다.

예를 한 번 들어보자. 평균 latency가 50ms 이고 초당 200개의 요청을 처리한다고 했을 때 동시에 처리할 수 있는 갯수는 10개의 요청들이다.

20 * x = 200

여기서 20 은 50ms을 1초 기준으로 환산한 값이며 x는 Little's Law 에서의 람다 역할, 200은 L 을 의미한다.

이 때 초당 처리량이 2000개, 20000개 점점 늘어날수록 x의 값은 커져갈 것이다. (초당 처리량의 값이 커진다는 의미)

불행하게도, JDK에 구현된 스레드는 OS 스레드로 구성되어 있어서 이용가능한 스레드의 수는 제한된다.

OS 스레드는 비용이 비싸서 우리는 해당 스레드를 많이 생성할 수 없으며, 이러한 상황은 thread-per-style 과 부적절하지 않다.

왜냐하면 숫자가 늘어남에 따라 CPU 나 네트워크 연결에 대하여 제한적이게 된다. 그래서 이러한 것을 다른 방식으로 풀어냈는데 우리가 흔히 아는 pooling 방식으로 스레드 생성에 대한 비용을 줄이고 스레드의 총 갯수를 증가하지 않는 방식으로 되어 있다.

Asynchronous

하지만 우리는 안다. thread-per-request 방식 말고 다른 방식이 있다는 것을 바로 asynchronous style 방식이 있다.

asynchrous 방식은 thread-per-style 과 같이 하나의 스레드로 처음부터 끝까지 하는 것에 비해, fine-grained sharing of threads(스레드의 세분화된 공유)는 오직 수행할 때에만 스레드를 수행하며, 이러한 방식은 많은 스레드 사용 없이 많은 수의 요청건을 처리한다. OS Thread 부족함으로 인한 처리량의 제한은 제거되지만, 비용은 비싸다. 왜냐하면 흔히 아는 asynchronous style을 알아야 한다. 이 말은 람다 표현식, 순차적 파이프 형식을 구성해야 한다.

비동기 방식은 각 순간마다 다른 스레드를 사용하기 때문에 하나의 스레드에 여러 개의 요청에 대한 콜 스택이 쌓이게 된다. 이러한 방식은 Stack trace가 불 필요하게 된다는 것을 의미한다. 이유는 디버깅하기 힘든 구조를 가졌기 때문이다.

이야기 하고자 하는 것을 이제 말하고자 한다. 바로 virtual thread가 도입된 방식이다.

Virtual Thread

애플리케이션이 기존 방식을 유지하며 더 확장성 있게 가능하며 효율적으로 바꿔준다.

운영체제는 한정된 램보다 더 많은 크기의 메모리가 존재한다고 생각하게 하며 이러한 방식은 Java 런타임 때 OS Thread 방식보다 더 많다고 환상을 주게 된다.

Virtual thread는 비동기 방식과 유사하게 OS Thread를 연산할 때에만 소비한다.

Virtual Thread는 생성하기 쉽고 가벼우며 많은 양을 생성할 수 있는 스레드다.

그래서 이전과 다르게 주의할 점이 있다. 바로 pooling을 해서는 안된다는 것이다.

새로운 virtual thread는 요청마다 생성된다. 대부분 스레드들은 짧은 수명과 얇은 콜 스택을 가진다. 사용 예는 http 요청이나 JDBC Query Call 이다. 이와 다르게 Platform Thread는 무겁고 비싸며 반드시 pooling 방식을 유지해야한다.

One OS Thread = Many Virtual Thread at time
즉 하나의 OS Thread는 여러개의 Virtual Thread와 연관되며 공유하는 관계다.

요약하자면 다음과 같다.

virtual thread는 OS Thread보다 결코 빠른 것은 아니다.
동시에 많은 요청을 처리해야하는 상황에서 유리하다.

Pooling 하지 않는다는 점에서도 많은 이점을 얻을 수 있다.

왜냐하면 virtual thread는 스레드를 공유하면서 사용하지 않고 요청마다 생성하는 형태로 사용하기 때문에 ThreadLocal에 값을 저장하여 사용할 때 다른 요청에서 쓸 걱정하지 않아도 된다는 큰 이점이 있기 때문이다.

virtual thread의 스택은 자바의 GC heap에 저장된다. 애플리케이션이 동작하면서 해당 스택은 줄거나 늘어날 수 있다.

그리고 virtual thread는 많은 상황에서 스택을 변경하고 재사용할 수 있는 반면 asynchronous pipeline은 항상 새 객체를 할당해야 하므로 virtual thread는 더 적은 할당이 필요하다.

공식문서에 의하면 시간이 지남에 따라 virtual thread 스택의 내부 표현이 훨씬 더 간결해질 것으로 예상한다고 한다.

Unlike platform thread stacks, virtual thread stacks are not GC roots, so the references contained in them are not traversed in a stop-the-world pause by garbage collectors, such as G1, that perform concurrent heap scanning.

virtual thread stack은 가비지 수집기에 의한 stop the world 일시중지에서 순회되지 않는다.

since the virtual thread can never be interrupted or unblocked. Of course, the virtual thread will not be garbage collected if it is running or if it is blocked and could ever be unblocked.

virtual thread는 결코 interrupt 나 unblock을 일으키지 않는다.

Little's Law

L = λW

L : 총 처리량

λ: 대기열에 있는 요청 수

W: 대기 시간

[Java] record 이해해보기

글을 쓰는 개발자 — Thu, 6 Oct 2022 15:52:10 +0900

쓰는 방식

public record MyRecordVo(
        Long id,
        String name,
        String phone
) {
    public String region() {
        return Arrays.stream(phone.split("-")).findFirst().orElseThrow(RuntimeException::new);
    }
}

record로 설정한다.
( ) 괄호 안에 원하는 타입과 필드 이름을 설정한다.
추가적인 메소드는 {} 안에 작성하면 된다. (위의 메소드는 억지로 작성한 것이니 그냥 넘어가주셔도 됩니다 ㅎㅎ)

특성

https://docs.oracle.com/en/java/javase/14/docs/api/java.base/java/lang/Record.html

https://docs.oracle.com/javase/specs/jls/se16/html/jls-8.html#jls-8.10

기본적으로 정의된 타입과 이름에 따라 public 접근제어자와 return type 그리고 method name이 정해진다.
해당 값들은 immutable 하다 ( 즉 Vo 에 쓰기 적절하다)
암묵적으로 final 제어자가 붙게 된다.
동일한 키워드가 레코드 선언의 수정자로 두 번 이상 나타나거나 레코드 선언에 public, protected 및 private 중 하나 이상의 액세스 수정자가 있는 경우 컴파일 시간 오류
equals, hashCode, toString 들은 멤버 변수에 맞게 정의된다.
생성자를 정확히 하나만 지정하는 이유는 해당 변수 값들을 validate 하기 위함이다.

public void record(MyRecordVo vo) {
    log.info("record id = {}, name = {}, phone = {}", vo.id(), vo.name(), vo.phone());
    Class<?> superclass = vo.getClass().getSuperclass();
    log.info("classes = {}", superclass);
}

record로 정의한 java의 경우 상위 클래스가 뭔지 알아보기 위해 찍어봤다.

18:20:51.011 [Test worker] INFO com.playground.springplayground.java.RecordService - classes = class java.lang.Record

보통 클래스들은 extends를 하지 않는 이상 superClass는 Object 이다.

근데 record로 설정한 경우 java.lang.Record 이다

Record

public abstract class Record {
    
    protected Record() {}

    
    @Override
    public abstract boolean equals(Object obj);

    
    @Override
    public abstract int hashCode();

    
    @Override
    public abstract String toString();
}

해당 추상 클래스를 상속하여 구현하게 되는 것이다.

그렇기에 record로 설정한 경우 extends 를 사용할 수 없다는 것을 유념해야 한다.

사용처

위에서 말한 것 처럼 Value Object로 사용할 경우 이용하기에 적절하다. 그 이유는 VO 의 경우 값이 바뀌면 안되고, 수정해서는 안되는 것이 기본이므로 왠만한 Vo 의 경우 record를 사용하기에 적절하다.

[Java] Generic 에 대한 이해

글을 쓰는 개발자 — Thu, 6 Oct 2022 15:51:52 +0900

Generic은 왜 도입이 되었고 이점은 무엇인가?

Oracle 참고

https://docs.oracle.com/javase/tutorial/java/generics/index.html

Fortunately, some bugs are easier to detect than others. Compile-time bugs, for example, can be detected early on; you can use the compiler's error messages to figure out what the problem is and fix it, right then and there. Runtime bugs, however, can be much more problematic; they don't always surface immediately, and when they do, it may be at a point in the program that is far removed from the actual cause of the problem.

문서에서 말하길 Generic 도입으로 인하여 Compile 시점에서 에러 또는 버그를 찾을 수 있게 되었고, 이로 인해 개발적 생산성이 높아지는 기대를 얻을 수 있었다.

그리고 가장 좋은 버그는 컴파일 에러라 하지 않았는가!

그렇기에 Generic의 도입은 많은 버그를 잡아주는 포인트였다.

이점

컴파일 에러를 발견할 수 있는 이점
casting 하지 않아도 된다는 이점

Convention

E - Element (used extensively by the Java Collections Framework)
K - Key
N - Number
T - Type
V - Value
S,U,V etc. - 2nd, 3rd, 4th types

Type Parameter 와 Type Arguments의 차이

흔히 Type Parameter와 Type Arguments를 혼용하여 쓰인다. 하지만 엄연히 차이점이 존재한다.

Box<T> 에서 T는 Type Parameter 이고 Box<String> 에서 String 은 Type Arguments 이다.

static, 일반 배열에 사용할 수 없다.

왜 쓸 수 없을까?

쓸 수 없는 이유는 generic은 인스턴스변수로 간주되기 때문에 static 와 같이 인스턴스가 아닌 경우 사용할 수가 없다.

배열 또한 사용할 수 없는 것은 new 연산자 때문인데, 컴파일 시점에 generic type을 알아야 하기 때문이다.

다만 generic 배열 타입의 참조변수를 선언하는 것은 가능하다. generic 배열을 생성하는 것이 불가능하다는 것을 말하는 것이다.

? extends T, ? super T

java 코드를 보다 보면 위와 같은 형식을 자주 볼 수 있다.

extends 와 super 연산자는 우리가 아는 것과 비슷하게 동작을 한다.

? extends T

T 와 그 sub class 에 대해서만 접근을 가능하게 하는 역할을 한다.

우선 예를 먼저 보자

위의 예시와 같이 <T extends CheckType> 으로 설정하면 CheckType 포함하여 그 하위클래스들만 접근할 수 있게 된다. 그렇기에 Object를 넣었을 때 Compile Error가 나는 것을 알 수 있다.

? super T

https://docs.oracle.com/javase/tutorial/java/generics/lowerBounded.html

우리는 예를 들어 숫자를 더하는 함수를 만드는 데 Integer 뿐만 아니라 Number 까지 허용하는 것을 구현하고 싶을 때 사용할 수 있다.

우리가 흔히 볼 수 있는 곳은 sort 이다.

static <T> void sort(List<T> list, Comparator<? super T> c)

Generic Method

메서드의 선언부에 generic type이 선언된 메서드를 generic method라 한다.

위와 같은 경우에는 접근제어자가 생략되어 있는데 접근 제어자를 쓰고나서 generic method에서 사용하고자 하는 generic을 선언하면 된다. 여기서 선언된 generic의 경우에는 클래스에서 선언한 generic과 별개로 움직인다는 것만 알면 된다.

[Java] Annotation 의 동작의 이해

글을 쓰는 개발자 — Thu, 6 Oct 2022 15:51:35 +0900

참고: https://docs.oracle.com/javase/tutorial/java/annotations/

Java Annotation

Annotations, a form of metadata, provide data about a program that is not part of the program

메타데이터의 한 형태인 어노테이션은 프로그램의 일부가 아닌 프로그램에 대한 데이터를 제공합니다.

컴파일러를 위한 정보 - 어노테이션은 컴파일러가 에러나 supress warnings를 찾기 위해 사용된다.
Compile-time 그리고 deployment-time 가공과정 - 소프트웨어 도구들은 어노테이션 정보들을 활용하여 코드, XML, JSON 등을 생성한다.
런타임 처리 - 몇몇 어노테이션은 런타임 시간에 검사되는 데 사용된다.

Declaring an Annotation Type

실제 프로젝트를 진행하면서 어떤 클래스에 중요한 정보를 저장해야 할 때 다음과 같이 표현할 수 있다.

public class MyClass {
// Author: Park Suhan
// Date: 2022/10/01
// Current Version: 1.5.6
// Last Modified: 2022/10/30
// By: Park Suhan
// Reviewers: Mike, Sandy, Alice
}

하지만 어노테이션을 가지고 메타데이터를 더한다면, 다음과 같이 정의할 수 있다.

@interface ClassRecord {
	String author();
    String date();
    double currentVersion() default 1.0;
    String lastModified() default "N/A";
    String lastModifiedBy() default "N/A";
    String[] reviewers();
}

어노테이션 타입 정의는 인터페이스 정의하는 방식 ( 앞에 '@'붙였다는 사실만 다를 뿐)과 비슷하다.

타입을 다음과 같이 설정했으면 우리는 어노테이션 타입에 대한 값 설정을 다음과 같이 할 수 있다.

@ClassRecord(
        author = "Park Suhan",
        date = "2022/10/01",
        currentVersion = 1.56,
        lastModified = "2022/10/30",
        lastModifiedBy = "Park Suhan",
        reviewers = {"Alice", "Sandy", "Mike"}
)
public class MyClass {
}

이 때 약간의 팁을 주자면 해당 어노데이션은 문서의 성향이 있으며 Javadoc을 원한다면 다음과 같이 추가해주면 더 좋다.

@Documented
public @interface ClassRecord {
    // 생략
}

Predefined Annotation Types

@Deprecated, @Override, @SuppressWarnings

@Deprecated

Deprecated 어노테이션은 해당 클래스 또는 메소드를 더 이상 사용하지 않을 것이라고 표현하는 메타데이터이다. 컴파일러가 @Deprecated 어노테이션 표시된 클래스, 메소드 등을 프로그램에서 사용할 때 사용하지 말라고 경고문을 날린다.

@Override

@Override 어노테이션은 컴파일러에게 부모 클래스로부터 상속받은 메소드라는 정보를 준다. @Override 어노테이션은 의무적으로 사용해야 하는 것은 아니지만, 사용할 경우 에러를 예방할 수 있다.

@SuppressWarnings

SuppressWarnings 어노테이션은 특정 경고 메시지를 없애는 데 사용된다. 해당 사용되는 곳은 컬렉션 프레임워크를 보면 심심치 않게 볼 수 있다.

@SuppressWarnings("unchecked")
public <T> T[] toArray(T[] a) {
    if (a.length < size)
        // Make a new array of a's runtime type, but my contents:
        return (T[]) Arrays.copyOf(elementData, size, a.getClass());
    System.arraycopy(elementData, 0, a, 0, size);
    if (a.length > size)
        a[size] = null;
    return a;
}

모든 컴파일러 경고는 하나의 카테고리에 속하게 되는데 "unchecked", "deprecation"이 이에 속한다.

@SafeVarags

SafeVarags 어노테이션은 메소드나 생성자에 지원되는 어노테이션으로 코드가 varargs 매개변수에 대해 잠재적으로 안전하지 않은 작업을 수행하지 않음을 나타냅니다

https://www.baeldung.com/java-safevarargs

@FunctionalInterface

FunctionalInterface 어노테이션은 람다를 사용할 때 컴파일 에러를 체크하기 위해 사용되는 어노테이션으로서 메소드를 하나만 정의하도록 설정하는 어노테이션입니다. 두개 이상이 정의되었을 때 에러 표시가 나면서 실수를 줄일 수 있게 해줍니다.

Annotation을 지원하는 Annotation

@Rentention

어느 시점까지 유지할 것인지 표시하는 어노테이션

RetentionPolicy.SOURCE – 소스 코드 상까지는 유지되며 그 이후 (컴파일러 이후) 부터는 효력이 없음
RetentionPolicy.CLASS – 컴파일 시점까지 유지되며, 그 이후 부터는 무시(Java Virtual Machine (JVM)에 의해)
RetentionPolicy.RUNTIME – JVM시점 부터 유지되며 런타임때 사용가능하다.

@Documented

JavaDoc 관련 문서화할 때 사용되는 어노테이션

@Target

적용되는 어노테이션의 범위를 제한하는 어노테이션

ElementType.ANNOTATION_TYPE -> annotation type.
ElementType.CONSTRUCTOR -> constructor.
ElementType.FIELD -> field or property.
ElementType.LOCAL_VARIABLE -> local variable.
ElementType.METHOD -> method-level annotation.
ElementType.PACKAGE -> package declaration.
ElementType.PARAMETER -> parameters of a method.
ElementType.TYPE -> any element of a class.

@Inherited

어노테이션 상속을 허용해주는 어노테이션. 기본적으로 어노테이션은 상속 불가능하다. (자세한 것은 밑의 예시를 확인할 것)

@Repeatable

하나의 예시를 보자

Name.java

해당 어노테이션은 값을 저장하는 어노테이션으로 중복해서 사용할 수 있는 어노테이션이다.

중복된 값을 가져올 때는 Names.class를 사용하라는 표시로 @Repeatable를 표시한다.

@Target(ElementType.TYPE)
@Repeatable(Names.class)
@Retention(RetentionPolicy.RUNTIME)
public @interface Name {
    String value();
}

Names.java

Name 어노테이션들을 관리하는 어노테이션으로 사용하는 코드에서 해당 어노테이션을 통해 정보를 가져온다.

@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
public @interface Names {
    Name[] value();
}

@Name("A")
@Name("B")
@Name("C")
public class TargetName {
}

public class Runner {
    public static void main(String[] args) {
        TargetName targetName = new TargetName();
        Names names = targetName.getClass().getAnnotation(Names.class);
        Name[] nameArray = targetName.getClass().getAnnotationsByType(Name.class);
        Name[] values = names.value();
        for (Name value : values) {
            System.out.println(value);
        }
        System.out.println(Arrays.toString(nameArray));
    }
}

@com.playground.springplayground.annotation.Name("A") @com.playground.springplayground.annotation.Name("B") @com.playground.springplayground.annotation.Name("C") [@com.playground.springplayground.annotation.Name("A"), @com.playground.springplayground.annotation.Name("B"), @com.playground.springplayground.annotation.Name("C")]

사용하는 방법은 다음 두가지 정도 있다.

Name을 관리하는 Names를 통해 가져오는 방법
Name을 지정하여 Array로 받는 방법

취향이니 좀 더 끌리는 것을 선택하면 좋을 것 같다.

Spring Annotation

@SpringBootApplication

@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Inherited
@SpringBootConfiguration
@EnableAutoConfiguration
@ComponentScan(excludeFilters = { @Filter(type = FilterType.CUSTOM, classes = TypeExcludeFilter.class),
      @Filter(type = FilterType.CUSTOM, classes = AutoConfigurationExcludeFilter.class) })
public @interface SpringBootApplication {
   
   @AliasFor(annotation = EnableAutoConfiguration.class)
   Class<?>[] exclude() default {};
   
   @AliasFor(annotation = EnableAutoConfiguration.class)
   String[] excludeName() default {};
   
   @AliasFor(annotation = ComponentScan.class, attribute = "basePackages")
   String[] scanBasePackages() default {};

   @AliasFor(annotation = ComponentScan.class, attribute = "basePackageClasses")
   Class<?>[] scanBasePackageClasses() default {};

   
   @AliasFor(annotation = ComponentScan.class, attribute = "nameGenerator")
   Class<? extends BeanNameGenerator> nameGenerator() default BeanNameGenerator.class;

   @AliasFor(annotation = Configuration.class)
   boolean proxyBeanMethods() default true;

}

@Target(ElementType.TYPE)

해당 어노테이션은 클래스에만 사용가능하도록 한정시키는 역할

@Retention(RetentionPolicy.RUNTIME)

JVM 동작하는 시점에 적용되며, 흔히 런타임 시점에서 동작한다고 생각하면 된다.

@Inherited

적용된 어노테이션의 A 클래스가 존재한다고 했을 때 A 클래스를 상속한 B 클래스에서 A 클래스에 적용된 메타 데이터를 사용할 수 있게 해주는 것이 @Inherited 이다.

예시

@Inherited 를 적용한 클래스

@Inherited
@Retention(RetentionPolicy.RUNTIME)
public @interface MyInherit {
    String value() default "hi";
}

@Inherited 를 적용하지 않은 클래스

public @interface NoInherit {
    String value() default "noInherit";
}

적용한 클래스

@NoInherit
@MyInherit
public class AClass {
}

테스트할 클래스

public class BClass extends AClass{
}

실행 결과

public class Runner {
    public static void main(String[] args) {
        final BClass bClass = new BClass();
        Annotation[] annotations = bClass.getClass().getAnnotations();
        for (Annotation annotation : annotations) {
            System.out.println(annotation);
        }
    }
}

@com.playground.springplayground.annotation.inherited.MyInherit("hi")

보시는 바와 같이 @Inherited 어노테이션을 적용한 곳에서만 값을 가져올 수 있는 것을 볼 수가 있다.

이 점을 유의해가면 사용하시길 바란다.

@AliasFor

@AliasFor 에 정의된 어노테이션의 메타데이터 값을 가져오는 역할을 한다.

@AliasFor(annotation = EnableAutoConfiguration.class)
Class<?>[] exclude() default {};

"해당 부분은 SpringBootApplication 어노테이션에 있는 exclude method의 값은 EnableAutoConfiguration 어노테이션의 exclude 값의 역할을 부여한다." 라고 이해하면 된다.

하나의 예시를 들어보자

MyRequestMapping.java

@Target({ElementType.METHOD,ElementType.TYPE})
@Retention(RetentionPolicy.RUNTIME)
@RequestMapping
public @interface MyRequestMapping {
    @AliasFor(annotation = RequestMapping.class, attribute = "value")
    String route() default "";
    @AliasFor(annotation = RequestMapping.class, attribute = "method")
    RequestMethod[] define() default {};

}

MyRequestMapping은 RequestMapping의 일부분을 재정의한 어노테이션으로서 RequestMapping의 value 부분은 route로 재정의하였으며, method 부분은 define을 재정의하였다.

@RestController
public class AnnoController {
    @MyRequestMapping(define = RequestMethod.GET, route = "/web/annotation")
    public String view() {
        return "view";
    }
}

해당 부분을 테스트 해보면 view가 정상적으로 찍히는 것을 알 수 있다.

어노테이션에 대한 이해는 이 정도 하면 될 것 같다.

나중에 하면서 부족하거나 필요한 지식은 추가해나갈 것이다.

읽어주셔서 감사합니다.

[Spring] @EventListener

글을 쓰는 개발자 — Thu, 6 Oct 2022 15:51:14 +0900

참고 글: https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/context/event/EventListener.html

구조 파악하기

@EventListener를 사용하는 방법은 다음과 같다.

EventPublisher

@Component
@RequiredArgsConstructor
public class EventPublisher {
    private final ApplicationEventPublisher publisher;
    public void publish(PublicEvent event) {
        publisher.publishEvent(event);
    }
}

EventSubscriber

@Component
@RequiredArgsConstructor
public class EventSubscriber {
    private final EventService service;

    @Async
    @EventListener
    public void subscribe(PublicEvent event) throws InterruptedException {
        service.doing(event);
    }
}

SurfaceService

@Slf4j
@Service
@RequiredArgsConstructor
public class SurfaceService {
    private final EventPublisher publisher;

    public void surface(PublicEvent event) {
        log.info("start surface");
        publisher.publish(event);
        log.info("finish surface");
    }
}

호출 시

2022-10-09 20:51:01.160 INFO 14161 --- [nio-8080-exec-1] c.p.s.pubsub.SurfaceService : start surface 2022- 2022-10-09 20:51:01.161 INFO 14161 --- [nio-8080-exec-1] c.p.s.pubsub.SurfaceService : finish surface 2022-10-09 20:51:03.168 INFO 14161 --- [cTaskExecutor-1] c.p.s.pubsub.EventService : eventName = hi

@Async만 써도 되는 데 굳이 왜 Pub Sub을 따로 구성하는 이유가 뭘까?

무엇보다 강한 레이어를 분리하는 것이 가장 큰 목표다.

Subscriber 는 A만 알면 되는데 그 이상의 정보를 넘기는 순간 애플리케이션 레이어 및 로직들이 꼬이게 된다.

그렇기에 Publisher에서 특정 정보만 다듬어서 Subscriber에만 넘김으로서 느슨한 결합을 유지하며 레이어도 유지할 수 있게 된다.

다이어그램을 표현하면 다음과 같다.

다음과 같은 상황이 올 수 있다.

여러 도메인에서 들어오는 요청값이 다양할 수 있다. 하지만 처리에 필요한 것은 특정 값은 하나다.

그런 상황에서 비동기로 처리하기 좋은 방식은 다음 위 다이어그램과 같다.

이렇게 구성하면 느슨한 결합으로 확장성 있는 구조를 작성할 수 있게 된다.

[Spring] @Async 비동기로 처리하는 방법

글을 쓰는 개발자 — Sat, 1 Oct 2022 18:22:46 +0900

사용법

초기설정

@SpringBootApplication
@EnableAsync
public class SpringplaygroundApplication {

    public static void main(String[] args) {
        SpringApplication.run(SpringplaygroundApplication.class, args);
    }

}

첫 번째로 @EnableAsync을 설정해야 한다. 그래야 비동기로 동작하는 데 필요한 Bean 들이 등록이 된다.

돌리고자 하는 클래스 또는 메소드

@Slf4j
@Service
@Async
public class AsyncService {
    public void myAsyncCall() throws InterruptedException {
        Thread.sleep(1000L);
        log.info("async call = {}", LocalDateTime.now());
    }
}

필자는 클래스에 설정하긴 했지만 메소드로 설정해도 상관이 없다.

@Slf4j
@Service
@RequiredArgsConstructor
public class MyAsyncService {

    private final AsyncService asyncService;
    
    public void call() throws InterruptedException {
        log.info("start time = {}", LocalDateTime.now());
        asyncCall();
        log.info("end time = {}", LocalDateTime.now());
    }

    public void asyncCall() throws InterruptedException {
        asyncService.myAsyncCall();
    }
}

실제 해당 Async 클래스를 사용하는 서비스를 호출했을 때 다음과 같은 로그가 남는다.

2022-10-03 19:28:10.392  INFO 16905 start time = 2022-10-03T19:28:10.392891
2022-10-03 19:28:10.395  INFO 16905 end time = 2022-10-03T19:28:10.395125
2022-10-03 19:28:11.400  INFO 16905 async call = 2022-10-03T19:28:11.400748

서비스에 따라 ThreadPoolTaskExecutor 설정을 다르게 하고 싶을 수 있다.

그랬을 때는 다음과 같이 구성을 해주면 된다.

@Configuration
public class ThreadConfiguration {

    @Bean(name = "first")
    public ThreadPoolTaskExecutor asyncFirstExecutor() {
        final ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor();
        executor.setCorePoolSize(2);
        executor.setMaxPoolSize(4);
        executor.setThreadNamePrefix("first");
        executor.initialize();
        return executor;
    }

    @Bean(name = "second")
    public ThreadPoolTaskExecutor asyncSecondExecutor() {
        final ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor();
        executor.setCorePoolSize(2);
        executor.setMaxPoolSize(4);
        executor.setThreadNamePrefix("second");
        executor.initialize();
        return executor;
    }
}

ThreadPoolTaskExecutor 설정 값은 이와 같이 구성할 수 있으며 추가적인 API는 검색을 통해 찾아보시면 될 것 같다.

우선 해당 Bean이름을 편의를 위해 이름을 설정했다.

그리고 해당 이름을 @Async("first") 이와 같이 구성해주면 그에 대한 설정을 쓸 수가 있다.

@Slf4j
@Service
@Async("first")
public class AsyncService {
    public void myAsyncCall() throws InterruptedException {
        Thread.sleep(1000L);
        log.info("async call = {}", LocalDateTime.now());
    }
}

2022-10-03 19:28:31.543  INFO 16905 --- [nio-8080-exec-4] c.p.s.async.MyAsyncService               : start time = 2022-10-03T19:28:31.543265
2022-10-03 19:28:31.543  INFO 16905 --- [nio-8080-exec-4] c.p.s.async.MyAsyncService               : end time = 2022-10-03T19:28:31.543708
2022-10-03 19:28:32.551  INFO 16905 --- [        second2] c.p.s.async.SecondAsyncService           : async call2 = 2022-10-03T19:28:32.551425
2022-10-03 19:28:32.551  INFO 16905 --- [         first2] c.p.springplayground.async.AsyncService  : async call = 2022-10-03T19:28:32.551425

그랬을 때 스레드 이름이 second 와 first 각각 다르게 찍히는 것을 볼 수가 있다.

돌아가는 과정

@EnableAsync

@Target({ElementType.TYPE})
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Import({AsyncConfigurationSelector.class})
public @interface EnableAsync {
    Class<? extends Annotation> annotation() default Annotation.class;

    boolean proxyTargetClass() default false;

    AdviceMode mode() default AdviceMode.PROXY;

    int order() default Integer.MAX_VALUE;
}

여기서 @Import를 통해 AsyncConfigurationSelector.class 빈 정보들을 가져온다.

AsyncConfigurationSelector

public class AsyncConfigurationSelector extends AdviceModeImportSelector<EnableAsync> {
    private static final String ASYNC_EXECUTION_ASPECT_CONFIGURATION_CLASS_NAME = "org.springframework.scheduling.aspectj.AspectJAsyncConfiguration";

    public AsyncConfigurationSelector() {
    }

    @Nullable
    public String[] selectImports(AdviceMode adviceMode) {
        switch (adviceMode) {
            case PROXY:
                return new String[]{ProxyAsyncConfiguration.class.getName()};
            case ASPECTJ:
                return new String[]{"org.springframework.scheduling.aspectj.AspectJAsyncConfiguration"};
            default:
                return null;
        }
    }
}

여기서 ProxyAsyncConfiguration.class 정보를 보도록 하자

ProxyAsyncConfiguration

@Configuration(
    proxyBeanMethods = false
)
@Role(2)
public class ProxyAsyncConfiguration extends AbstractAsyncConfiguration {
    public ProxyAsyncConfiguration() {
    }

    @Bean(
        name = {"org.springframework.context.annotation.internalAsyncAnnotationProcessor"}
    )
    @Role(2)
    public AsyncAnnotationBeanPostProcessor asyncAdvisor() {
        Assert.notNull(this.enableAsync, "@EnableAsync annotation metadata was not injected");
        AsyncAnnotationBeanPostProcessor bpp = new AsyncAnnotationBeanPostProcessor();
        bpp.configure(this.executor, this.exceptionHandler);
        Class<? extends Annotation> customAsyncAnnotation = this.enableAsync.getClass("annotation");
        if (customAsyncAnnotation != AnnotationUtils.getDefaultValue(EnableAsync.class, "annotation")) {
            bpp.setAsyncAnnotationType(customAsyncAnnotation);
        }

        bpp.setProxyTargetClass(this.enableAsync.getBoolean("proxyTargetClass"));
        bpp.setOrder((Integer)this.enableAsync.getNumber("order"));
        return bpp;
    }
}

해당 클래스를 통해 @EnableAsync 설정한 정보들을 이용한다.

AsyncAnnotationBeanPostProcessor

위 ProxyAsyncConfiguration에서 볼 수 있다시피 AsyncAnnotationBeanPostProcessor를 통해 Advice로 동작하게 된다.

protected Advice buildAdvice(@Nullable Supplier<Executor> executor, @Nullable Supplier<AsyncUncaughtExceptionHandler> exceptionHandler) {
    AnnotationAsyncExecutionInterceptor interceptor = new AnnotationAsyncExecutionInterceptor((Executor)null);
    interceptor.configure(executor, exceptionHandler);
    return interceptor;
}

interceptor를 등록하는 과정이며 자세한 것은 검색해보시길 바란다.

AsyncExecutionAspectSupport

protected Object doSubmit(Callable<Object> task, AsyncTaskExecutor executor, Class<?> returnType) {
   if (CompletableFuture.class.isAssignableFrom(returnType)) {
      return executor.submitCompletable(task);
   }
   else if (org.springframework.util.concurrent.ListenableFuture.class.isAssignableFrom(returnType)) {
      return ((org.springframework.core.task.AsyncListenableTaskExecutor) executor).submitListenable(task);
   }
   else if (Future.class.isAssignableFrom(returnType)) {
      return executor.submit(task);
   }
   else if (void.class == returnType) {
      executor.submit(task);
      return null;
   }
   else {
      throw new IllegalArgumentException(
            "Invalid return type for async method (only Future and void supported): " + returnType);
   }
}

을 통해 실제 작업을 처리하게 된다.

언제 사용하면 좋을까?

주로 문자 메세지, 이메일 등을 처리하기 위해 많이 사용될 것이다.

그 뿐만 아니라 클라이언트에게 빠른 결과를 보여주고 해당 처리는 비동기로 처리함으로써 유저들에게 더 좋은 서비스를 경험해줄 때 쓰일 수 있다.

[Spring] @Scheduled, @EnableScheduling

글을 쓰는 개발자 — Sat, 1 Oct 2022 18:20:33 +0900

사용법

@EnableScheduling 설정

반드시 @Scheduled를 사용할려면 @EnableScheduling을 다음과 같이 설정해야 한다.

@SpringBootApplication
@EnableScheduling
public class SpringplaygroundApplication {

    public static void main(String[] args) {
        SpringApplication.run(SpringplaygroundApplication.class, args);
    }

}

@Scheduled 사용

@Scheduled는 다음 아래와 같이 3가지 설정을 통해 구현할 수 있으며, 원하는 내용에 어노테이션을 설정하면 된다.

cron

cron은 흔히 우리가 linux에서 설정하는 cron 형식과 유사하며 사용하는 방법은 다음 아래와 같다.

@Service
@Slf4j
public class ScheduleService {
    @Scheduled(cron = "10 * * * * *") //10초로 끝날 때마다 호출
    public void cronCall() {
        log.info("cron execute");
    }
}

2022-10-01 18:36:10.005  INFO 7847 --- [   scheduling-1] c.p.s.schedule.ScheduleService           : cron execute
2022-10-01 18:37:10.004  INFO 7847 --- [   scheduling-1] c.p.s.schedule.ScheduleService           : cron execute
2022-10-01 18:38:10.005  INFO 7847 --- [   scheduling-1] c.p.s.schedule.ScheduleService           : cron execute
2022-10-01 18:39:10.005  INFO 7847 --- [   scheduling-1] c.p.s.schedule.ScheduleService           : cron execute

CronExpression 에 정의 되어 있는 cron 예시

"@yearly", "0 0 0 1 1 *",
"@annually", "0 0 0 1 1 *",
"@monthly", "0 0 0 1 * *",
"@weekly", "0 0 0 * * 0",
"@daily", "0 0 0 * * *",
"@midnight", "0 0 0 * * *",
"@hourly", "0 0 * * * *"

@Service
@Slf4j
public class ScheduleService {
    @Scheduled(cron = "@hourly") // 매 정각마다
    public void cronCall() {
        log.info("cron execute");
    }
}

실제 위의 표현식은 제대로 동작을 한다.

2022-10-01 18:54:35.361  INFO 8103 --- [           main] c.p.s.SpringplaygroundApplication        : Started SpringplaygroundApplication in 1.115 seconds (JVM running for 1.315)
2022-10-01 19:00:00.004  INFO 8103 --- [   scheduling-1] c.p.s.schedule.ScheduleService           : cron execute

cron 순서는 다음과 같다

* <li>second</li> 초
* <li>minute</li> 분
* <li>hour</li> 시간
* <li>day of month</li> 일
* <li>month</li> 월
* <li>day of week</li> 주

fixedDelay

fixedDelay는 이전 작업이 끝나고 일정시간 마다 도는 것을 설정하는 필드다.

@Service
@Slf4j
public class ScheduleService {
    @Scheduled(fixedDelay = 1L, timeUnit = TimeUnit.SECONDS)
    public void publicCall() throws InterruptedException {
        Thread.sleep(500L);
        log.info("public call fixedDelay = 1's");
    }
}

2022-10-01 18:46:39.827  INFO 7915 --- [   scheduling-1] c.p.s.schedule.ScheduleService           : public call fixedDelay = 1's
2022-10-01 18:46:41.334  INFO 7915 --- [   scheduling-1] c.p.s.schedule.ScheduleService           : public call fixedDelay = 1's
2022-10-01 18:46:42.840  INFO 7915 --- [   scheduling-1] c.p.s.schedule.ScheduleService           : public call fixedDelay = 1's
2022-10-01 18:46:44.349  INFO 7915 --- [   scheduling-1] c.p.s.schedule.ScheduleService           : public call fixedDelay = 1's
2022-10-01 18:46:45.859  INFO 7915 --- [   scheduling-1] c.p.s.schedule.ScheduleService           : public call fixedDelay = 1's
2022-10-01 18:46:47.366  INFO 7915 --- [   scheduling-1] c.p.s.schedule.ScheduleService           : public call fixedDelay = 1's

* Execute the annotated method with a fixed period between the end of the
* last invocation and the start of the nex

즉 마지막 동작이 끝나고 정해진 시간 뒤에 일어난다는 뜻이다.

예시에서 스레드를 0.5초 쉬게 한 이유도 정확히 이전 작업이 끝나고 1초 뒤에 작업을 한다는 것을 보여주기 위해 작성했다.

참고로 timeUnit은 기본은 MiliSeconds 이다.

그러면 public Method 에서만 동작할까?

그렇지 않다!

@Service
@Slf4j
public class ScheduleService {
    @Scheduled(fixedDelay = 1500L)
    private void privateCall() {
        log.info("private call fixedDelay = 1.5's");
    }
}

2022-10-01 18:49:20.443  INFO 8038 --- [   scheduling-1] c.p.s.schedule.ScheduleService           : private call fixedDelay = 1.5's
2022-10-01 18:49:21.949  INFO 8038 --- [   scheduling-1] c.p.s.schedule.ScheduleService           : private call fixedDelay = 1.5's
2022-10-01 18:49:23.451  INFO 8038 --- [   scheduling-1] c.p.s.schedule.ScheduleService           : private call fixedDelay = 1.5's
2022-10-01 18:49:24.957  INFO 8038 --- [   scheduling-1] c.p.s.schedule.ScheduleService           : private call fixedDelay = 1.5's
2022-10-01 18:49:26.463  INFO 8038 --- [   scheduling-1] c.p.s.schedule.ScheduleService           : private call fixedDelay = 1.5's

다음과 같이 private method 에서도 동작하는 것을 볼 수가 있다.

fixedRate

fixedRate의 경우에는 시작을 기준으로 일정 간격마다 동작하는 방식이다.

@Service
@Slf4j
public class ScheduleService {
    @Scheduled(fixedRate = 1000L)
    public void fixedRateCall() throws InterruptedException {
        Thread.sleep(500L);
        log.info("public call fixedRate = 1's");
    }
}

2022-10-01 18:51:24.293  INFO 8080 --- [   scheduling-1] c.p.s.schedule.ScheduleService           : public call fixedRate = 1's
2022-10-01 18:51:25.296  INFO 8080 --- [   scheduling-1] c.p.s.schedule.ScheduleService           : public call fixedRate = 1's
2022-10-01 18:51:26.298  INFO 8080 --- [   scheduling-1] c.p.s.schedule.ScheduleService           : public call fixedRate = 1's
2022-10-01 18:51:27.293  INFO 8080 --- [   scheduling-1] c.p.s.schedule.ScheduleService           : public call fixedRate = 1's
2022-10-01 18:51:28.298  INFO 8080 --- [   scheduling-1] c.p.s.schedule.ScheduleService           : public call fixedRate = 1's
2022-10-01 18:51:29.294  INFO 8080 --- [   scheduling-1] c.p.s.schedule.ScheduleService           : public call fixedRate = 1's
2022-10-01 18:51:30.294  INFO 8080 --- [   scheduling-1] c.p.s.schedule.ScheduleService           : public call fixedRate = 1's
2022-10-01 18:51:31.297  INFO 8080 --- [   scheduling-1] c.p.s.schedule.ScheduleService           : public call fixedRate = 1's

fixedRate는 fixedDelay랑 다르게 일정 주기성을 가지고 정확히 1초마다 돌아가는 것을 볼 수가 있다.

* Execute the annotated method with a fixed period between invocations.
* <p>The time unit is milliseconds by default but can be overridden via
* {@link #timeUnit}.

주석을 읽으면 아시다시피 정해진 주기에 맞게 동작을 한다고 적혀 있다.

동작원리

@EnableScheduling 으로 필요한 Bean들을 등록한다!

SchedulingConfiguration

@Configuration(
    proxyBeanMethods = false
)
@Role(2)
public class SchedulingConfiguration {
    public SchedulingConfiguration() {
    }

    @Bean(
        name = {"org.springframework.context.annotation.internalScheduledAnnotationProcessor"}
    )
    @Role(2)
    public ScheduledAnnotationBeanPostProcessor scheduledAnnotationProcessor() {
        return new ScheduledAnnotationBeanPostProcessor();
    }
}

여기서 ScheduledAnnotationBeanPostProcessor를 빈으로 등록하는 과정을 거친다.

ScheduledAnnotationBeanPostProcessor

    public ScheduledAnnotationBeanPostProcessor() {
        this.registrar = new ScheduledTaskRegistrar();
    }

생성자에서 ScheduledTaskRegistrar()를 새로 생성하는 과정을 거치며

ScheduledTaskRegistrar

    public void setTaskScheduler(TaskScheduler taskScheduler) {
        Assert.notNull(taskScheduler, "TaskScheduler must not be null");
        this.taskScheduler = taskScheduler;
    }

taskScheduler를 주입받으며 생성하게 되는데 taskScheduler는

spring-autoconfigure-metadata.properties

org.springframework.boot.autoconfigure.task.TaskSchedulingAutoConfiguration.ConditionalOnClass=org.springframework.scheduling.concurrent.ThreadPoolTaskScheduler

에 정의되어 있는 ThreadPoolTaskScheduler를 빈으로 생성하고 이를 주입 받는 형태로 진행된다.

그럼 @Scheduled을 붙인 메소드는 어떻게 동작하게 될까?

ScheduledAnnotationBeanPostProcessor 의 이름에서 느껴지겠지만 빈 후처리기를 통해 생성된 빈에 스케줄 관련 후처리를 진행한다.

    public Object postProcessAfterInitialization(Object bean, String beanName) {
        if (!(bean instanceof AopInfrastructureBean) && !(bean instanceof TaskScheduler) && !(bean instanceof ScheduledExecutorService)) {
            Class<?> targetClass = AopProxyUtils.ultimateTargetClass(bean);
            if (!this.nonAnnotatedClasses.contains(targetClass) && AnnotationUtils.isCandidateClass(targetClass, Arrays.asList(Scheduled.class, Schedules.class))) {
                Map<Method, Set<Scheduled>> annotatedMethods = MethodIntrospector.selectMethods(targetClass, (method) -> {
                    Set<Scheduled> scheduledAnnotations = AnnotatedElementUtils.getMergedRepeatableAnnotations(method, Scheduled.class, Schedules.class);
                    return !scheduledAnnotations.isEmpty() ? scheduledAnnotations : null;
                });
                if (annotatedMethods.isEmpty()) {
                    this.nonAnnotatedClasses.add(targetClass);
                    if (this.logger.isTraceEnabled()) {
                        this.logger.trace("No @Scheduled annotations found on bean class: " + targetClass);
                    }
                } else {
                    annotatedMethods.forEach((method, scheduledAnnotations) -> {
                        scheduledAnnotations.forEach((scheduled) -> {
                            this.processScheduled(scheduled, method, bean);
                        });
                    });
                    if (this.logger.isTraceEnabled()) {
                        this.logger.trace(annotatedMethods.size() + " @Scheduled methods processed on bean '" + beanName + "': " + annotatedMethods);
                    }
                }
            }

            return bean;
        } else {
            return bean;
        }
    }

을 보시면 @Scheduled 검사 여부에 따라 적합한 후보군이 있으면 이에 따라

protected void processScheduled(Scheduled scheduled, Method method, Object bean)

위의 메소드를 호출하고 bean을 반환하는 작업을 진행하게 된다. 그렇게 되면 우리가 원하는 Schedule 설정이 동작하게 된다.

그리고 해당 메소드를 호출함으로써 실질적인 동작을 하게 된다.

@Override
public void afterPropertiesSet() {
   scheduleTasks();
}

그럼 scheduleTasks() 는 어디서 돌아갈까? 바로 아래글을 보자

그러면 실질적인 동작하는 클래스는 어디?

Task를 관리하는 클래스는 ScheduledTaskRegistrar 이다.

관리하는 Task 는 다음과 같다.

CronTask
FixedDelayTask
FixedRateTask
etc

등 다양한 Task 들이 존재하고 이에 대한 처리를 ScheduledTaskRegistrar 에서 하게 된다.

아까 위에서 scheduleTasks()에서 실질적인 동작들이 돌아간다고 말을 했는데 그 중 작은 부분을 보도록 하자

Date startTime = new Date(this.taskScheduler.getClock().millis() + task.getInitialDelay());
scheduledTask.future = this.taskScheduler.scheduleWithFixedDelay(task.getRunnable(), startTime, task.getInterval());

위 코드는 FixedDelay 를 설정했을 때 돌아가는 코드로서 @Scheduled 에 설정한 값들을 저장하고 그 값을 활용하여 ScheduleFuture에 등록함으로써 일정주기마다 동작하도록 설정하는 코드다.

그 이외에도 FixedRate, Cron도 이와 유사하게 동작하므로 실제로 보는 것을 추천한다.

어떤 상황에서 써야 할까?

필자가 생각했을 때는 스프링 배치로 돌기에는 너무 거창하고 그렇다고 주기적으로 돌긴 해야하는 상황에서는 사용하면 좋을 것 같다.

가령 일정 시간마다 데이터 최신화가 필요하지만 실패해도 상관없는 경우에 사용하거나, 일정시간마다 캐시를 Invalidation하는 작업을 하거나 등의 상황에서 사용하면 유용하고, 쉽게 사용할 수 있지 않을까 싶다.