[인프런] 스프링 핵심 원리 고급편(김영한) 정리

코로나 격리 기간 동안 기본편, 고급편을 다 보는 것이 목표였는데 성공했네요.

이제 복습만 해보면 될 것 같습니다(해당 포스트는 제가 복습하기 위해 정리해 둔 것 입니다.)

이번 강의는 조금 어려웠습니다. 그리고 AOP를 실제로 많이 쓰는 지 의문이 들었습니다.

AOP와 프록시 객체가 중점인데 이를 실제 프로젝트에 적용해보고 싶네요.

https://www.inflearn.com/course/%EC%8A%A4%ED%94%84%EB%A7%81-%ED%95%B5%EC%8B%AC-%EC%9B%90%EB%A6%AC-%EA%B3%A0%EA%B8%89%ED%8E%B8/dashboard

로그 추적기를 만들 때, 이 강의에서는 전부 콘솔을 통해 눈으로 직접 확인함.

assertThat 같은 junit의 기능을 활용하지 않음.

(학습을 위해 그렇게 하신다고 함.)

그렇다면, 로그는 어떻게 테스트를 해야하나?

→ 질문을 찾아보니, 보통 로그는 테스트를 하지 않음. 하지만 너무 중요하다면 따로 테스트를 해야한다고 답변해주심.

→ 어떻게….

로그를 남기기 위해 로그 관련된 객체를 파라미터로 넘겨야 됨.

→ 모든 코드가 이렇게 수정되어야 함.

이를 수정하기 위해서 새로운 클래스를 만들고, field에 TraceId(로그 관련 객체)를 추가해줌.

그리고 필드의 TraceId의 level을 직접 수정함으로써 가능함.

→ 문제는 이 새로운 클래스가 싱글톤일 경우, 동시성 문제가 발생함.

정상적인 경우

동시성 문제 발생(새로고침 눌러서 실험)

level 값이 2에서 끝나지 않고, 깊어진 것을 볼 수 있음. 그리고 transactionId가 같음.

객체 하나를 가지고 모든 사용자(요청)을 처리하니 이러한 현상이 발생함. 당연하게도.

싱글톤을 사용하면서 동시성을 해결하려면? → 쓰레드 로컬 사용하면 됨.

Thread local

해당 쓰레드만 접근할 수 있는 저장소.

(단점도 있을 거 같은데?)

주의점은 쓰레드가 종료할 때, .remove() 메소드를 통해서 객체를 지워줘야함. (메모리 누수가 일어날 수 있음)

만약 제거 하지 않다면?

WAS 같은 thread pool에서 심각한 문제 발생.

thread pool에 thread를 반환하게 되면, 기존에 사용하던 데이터가 Thread local에 남아있음.

다른 사용자에게 해당 thread가 할당되게 되면, 이전 사용자가 이용한 데이터 정보를 조회할 수 있음.

→ 그래서 사용자의 요청이 끝날 때, ThreadLocal의 값을 .remove()로 제거해야함.

템플릿 메서드 패턴

TraceStatus status = null;
try {
	status = trace.begin("message");
	//핵심 기능 호출
	trace.end(status);
} catch (Exception e) {
	trace.exception(status, e);
	throw e;
}

변하는 것과 변하지 않는 것을 분리해야함.

abstract class로 만들어서 상속받게 만들면, 매번 새로운 클래스 파일을 만들어야 함.

→ 익명 내부 클래스를 만들면 됨.

@Test
void templateMethodV1() {
    AbstractTemplate template1 = new SubClassLogic1();
    template1.execute();

    AbstractTemplate template2 = new SubClassLogic2();
    template2.execute();
}

-> 수정

@Test
void templateMethodV2() {
    AbstractTemplate template1 = new AbstractTemplate(){

        @Override
        protected void call() {
            log.info("비즈니스 로직1 실행");
        }
    };

    template1.execute();

    AbstractTemplate template2 = new AbstractTemplate(){

        @Override
        protected void call() {
            log.info("비즈니스 로직2 실행");
        }
    };

    template2.execute();
}

대신 클래스 이름 뒤에 $1 같은 문자가 붙음.

이 템플릿 패턴을 사용하는 모든 코드는 이러한 작업을 해줘야함. 과연 이게 좋은 건가…

코드가 좀 지저분해 보임(개인적으로는)

물론 유지보수하기는 좋음

만약 로그가 변경이 되면, 로그 템플릿 클래스만 변경하면 되기 때문임.

→ SRP를 지킴. → SRP가 잘 지켜져 있다면, 변경이 쉬움.

템플릿 메서드 패턴은 골격을 정해두고, 일부 메소드는 하위 클래스가 구현함.

→ 상속을 이용함.

현재 자식 클래스 입장에서는 부모 클래스 기능을 사용안하고 있음.

(독립적인 call을 각자 구현하고 있음. 부모 클래스의 기능은 사용하지 않고 있음.)

사용하지 않음에도 부모 클래스에 강하게 의존하게 됨. 좋은 설계는 아니라고 함.

→ 이를 해결하기 위해 전략 패턴을 이용하면 됨.

전략 패턴(strategy)

변하는 부분은 따로 인터페이스(strategy)로 만들고, 변경되지 않는 부분은 클래스(context)로 만들어서 해결.

즉, 인터페이스에 역할을 위임함.

@Slf4j
public class ContextV1 {

		//call()이 있음. 이를 구현해야함. 이는 인터페이스임.
    private Strategy strategy;

    public ContextV1(Strategy strategy) {
        this.strategy = strategy;
    }

    public void execute() {
        long startTime = System.currentTimeMillis();

        strategy.call();

        long endTime = System.currentTimeMillis();
        long resultTime = endTime - startTime;
        log.info("resultTime={}", resultTime);
    }
}

Context는 Strategy 인터페이스에만 의지.

코드보면 그냥 스프링에서 의존성 주입하는 것과 같음.

전략 패턴은 인터페이스에만 의존하고 있음. 템플릿 메소드 패턴은 부모 클래스의 변경에 민감했었음.

익명 클래스를 람다로 변경할 수 있음.

(인터페이스의 메소드가 1개라면)

이 패턴은 선 조립, 후 실행 방식에서 유용.

(context와 strategy 조립 후, 실행함.)

단점은 조립 후에 전략을 변경하기가 어려움.

setter로 변경해도 되지만, 만약 context가 싱글톤이라면 동시성 문제가 발생하게 됨.

public class ContextV2 {

    public void execute(Strategy strategy) {
        long startTime = System.currentTimeMillis();

        strategy.call();

        long endTime = System.currentTimeMillis();
        long resultTime = endTime - startTime;
        log.info("resultTime={}", resultTime);
    }
}

파라미터로 받아오면 됨. 멋진데?

원하는 전략을 줄 수 있음. 단점은 실행할 때마다 전략을 줘야 함.

템플릿 콜백 패턴

콜백은 다른 함수로 실행 가능한 코드를 넘겨주고, 호출한 메소드에서 이러한 코드를 실행함.

저 위에 있는 contextv2가 템플릿 콜백임.

ContextV2가 템플릿 역할이고, strategy가 콜백임.

(ContextV1은 아님)

이는 GOF 패턴이 아닌, 스프링에서 주로 이용하는 패턴임.

이러한 코드의 문제점은 콜백으로 넘겨주는 코드를 다 작성을 해야함.

→ 즉 원본 코드의 수정이 필요함. 이를 해결하기 위해 프록시 패턴 이용.

인터페이스 컨트롤러에는 @RequestParam 같은 어노테이션을 달아줘야 함. 없으면 가끔 인식 안된다고 함.

@SpringBootApplication에서 @Import를 이용하여 원하는 설정파일 직접 주입할 수 있음.

(BasePackages 범위 밖에 있어도 등록가능)

@Controller를 쓰면 자동으로 Component 스캔 대상이 되어버림.

→ 수동 빈 등록을 하고 싶다면 RequestMapping 사용.

프록시

클라이언트 → 프록시 → 서버

중간에서 간접적으로 프록시가 요청을 할 수 있음.

클라이언트가 기대한 것 외에 다른 부가기능을 수행할 수 있음.

클라이언트는 프록시를 통해 요청한 결과만 받으면 됨. 어떠한 부가 기능이 수행 되었는 지는 몰라도 됨.

주요 기능

접근 제어.

권한에 따른 접근 차단
캐싱
지연 로딩

부가 기능 추가

부가 기능 수행(로그를 남기는 등)

프록시 패턴은 접근 제어가 목적.

데코레이터 패턴은 새로운 기능 추가가 목적

e.g)

프록시 캐시처럼 활용하기?

interface Subject {
	T call();
}

class target implments Subject{
	Server server;
	T call() {
		server....()
	}
}

class proxy implents Subject {
	Subject target;
	String cacheValue;
	T call() {
		if(cacheValue == null) {
			cacheValue = target.call()
		}

		return cacheValue
	}
}

이런 식으로도 활용할 수 있음.

디자인 패턴에서 중요한 것은 의도.

데코레이터와 프록시 구분 기준은 의도임.

그리고 레포지토리나 서비스 등 인터페이스로 이용하면, 위처럼 프록시 패턴을 도입할 수 있음.

프록시가 이 인터페이스(컨트롤러, 서비스 등)를 상속받고, 이 프록시 내부에 진짜 객체를 이용하여 사용자의 요청을 처리할 수 있음.

→ 이런 식으로 하면 기존의 코드 변경이 사라짐.

그 이유는 기존 구체 객체를 빈으로 주는 게 아닌, 프록시를 주면 됨.

그러면 프록시 객체에서 로그를 남긴 후, 실제 객체에게 요청을 처리해달라고 하면 됨. 매우 멋진 방법처럼 보임.

구체 클래스를 상속해서 해도 됨.

하지만 super()로 부모 클래스의 생성자를 호출해야함. 인자로 null로 줘도 됨.

→ 왜냐하면 부모 클래스의 기능을 사용하지 않기 때문에.

(실제 객체를 필드로 가지고 있고, 그 객체를 통해 기능을 수행하기 때문에 부모 클래스의 기능을 사용하는 것이 아님.)

그래서 보통 인터페이스 기반이 더 좋음. 상속의 제약에서 자유로움.

인터페이스의 단점은 해당 인터페이스가 필요하다는 것이 단점임. 테스팅할 때도 단점이 있다고 함. 하지만 변경이 거의 일어나지 않는다면 구체 클래스를 하는 것이 더 좋을 수도 있음. 또한 실무에서는 둘 다 섞인 경우도 있기 때문에 우선 둘 다 알아둬야 함.

프록시의 단점은 프록시 클래스를 너무 많이 만들어야 함.

만약 적용할 클래스가 많아지면, 프록시 클래스도 그 만큼 만들어줘야 함.

→ 동적 프록시가 이를 해결해줌.

동적 프록시

리플렉션을 이용하여 메소드를 동적으로 변경가능.

리플렉션으로 method 따로 분리할 수 있음.

그리고 이를 프록시 객체에 method 를 넘겨주면 됨.

method.invoke(target, args) 로 실행할 수 있음. target은 해당 메소드를 실행할 인스턴스. args는 넘길 인수.

InvocationHandler의 구현 객체도 필요함. 거기에 invoke를 오버라이딩 해야함

그리고 jdk 리플렉션에서 지원해주는 proxy가 있음. Proxy.newProxyInstance를 통해 동적인 프록시 객체를 만들어줌. 하지만 이는 인터페이스에 적용 가능.

하지만 리플렉션은 런타임에 작동하기 때문에, 컴파일 시점에 오류 못 잡음. 되도록 사용하면 안됨.

private static final String[] PATTERNS = {"request*", "order*", "save*"};

@Bean
public OrderServiceV1 orderServiceV1(LogTrace logTrace) {
	OrderServiceV1 orderService = new OrderServiceV1Impl(orderRepositoryV1(logTrace));

	OrderServiceV1 proxy = (OrderServiceV1)Proxy.newProxyInstance(
		OrderServiceV1.class.getClassLoader(),
		new Class[]{OrderServiceV1.class},
		new LogTraceFilterHandler(orderService, logTrace, PATTERNS)
	);

	return proxy;
}

proxy가 빈으로 등록이 됨.

만약 인터페이스가 아닌 클래스에 적용하고 싶다면?

CGLIB(code generatpr library) 사용

이를 사용하는 경우는 거의 없음. 스프링에서 proxy factory라는 것을 제공해주기 때문.

이 안의 MethodInterceptor를 구현하면 됨.

그리고 Enhancer에 앞에서 구현한 것과 프록시를 적용할 객체를 넘겨주면 됨.

enhancer.create() 하면 프록시를 적용할 객체를 반환해줌.

하나는 클래스만, 하나는 인터페이스만 지원을 해줌.

→ 스프링에서 제공해주는 프록시 팩토리는 둘 다 이용가능.

스프링의 프록시 팩토리

프록시 팩토리는 Advice를 만들어서 처리를 하게 됨. CGLIB나 JDK 동적 프록시는 이러한 Advice를 호출하게 됨.

→ 즉, JDK, CGLIB 안에 코드를 따로따로 구현할 필요가 없음.

프록시 팩토리도 MethodInterceptor를 구현하면 됨(CGLIB와 다른 거임! 패키지 주의)

invociation.proceed() 하면 됨.

이전과 달리 target에 대한 정보가 안보임.

@Slf4j
public class TimeAdvice implements MethodInterceptor {
	@Override
	public Object invoke(MethodInvocation invocation) throws Throwable {
		log.info("TimeProxy 실행");
		long startTime = System.currentTimeMillis();
		...
	}

이는 MethodInvocation invocation 내에 이미 들어있음.

이는 JDK가 기본임. 인터페이스가 없다면 CGLIB를 통해 동적프록시를 생성함.

이런 식으로 사용 가능

ServiceInterface target = new ServiceImpl();
ProxyFactory proxyFactory = new ProxyFactory(target);
proxyFactory.addAdvice(new TimeAdvice());

ServiceInterface proxy = (ServiceInterface) proxyFactory.getProxy();

매우 간단해짐.

포인트컷(Pointcut)은 필터링 로직. 클래스와 메서드 이름으로 필터링 가능.

어드바이스(Advice)는 앞에서 본 것처럼 프록시가 호출하는 부가 기능.

어드바이저(Advisor)는 둘 다 가지고 있는 것.

여러 프록시를 사용하려면?

//clients -> proxy2 -> proxy1 -> server

DefaultPointcutAdvisor advisor2 = new DefaultPointcutAdvisor(Pointcut.TRUE, new Advice2());
DefaultPointcutAdvisor advisor1 = new DefaultPointcutAdvisor(Pointcut.TRUE, new Advice1());

ServiceInterface target = new ServiceImpl();
ProxyFactory proxyFactory1 = new ProxyFactory(target);

proxyFactory1.addAdvisor(advisor2);
proxyFactory1.addAdvisor(advisor1);

이는 프록시가 여러 개 생성되는 것이 아님!

proxy가 여러 advisor를 사용하는 것임. 하나의 프록시에 어려 어드바이저를 적용되는 것.

등록 순서도 중요함

하지만 프록시 패턴에도 문제가 있음.

Configuration에서 bean을 만들때 중복되는 코드가 많음. 모든 클래스의 프록시 설정 코드를 다 작성해줘야 함.

컴포넌트 스캔을 하면 프록시 적용이 불가능함.

이미 기존 객체가 빈으로 바로 주입이 되어버림. 이 대신 프록시를 주입 해주도록 설정 해야하는데….

이를 처리하기 위해 빈 후처리기 이용하면 됨.

빈 후처리기(BeanPostProcessor)

빈을 등록하기 전에 빈을 조작할 수 있음.

후 처리 작업 시에 객체를 다른 객체로 바꿔치기도 할 수 있음.

BeanPostProcessor 인터페이스를 구현해야함.

before 메소드는 @PostConstruct 발생하기 전.

after는 초기화되고 난 후.

자바 8 이후는 default 로 선언되어 있어서 override를 안해도 오류가 안 뜸.

@Slf4j
public class PackageLogTraceProxyPostProcessor implements BeanPostProcessor {
	private final String basePackage;
	private final Advisor advisor;

	public PackageLogTraceProxyPostProcessor(String basePackage, Advisor advisor) {
		this.basePackage = basePackage;
		this.advisor = advisor;
	}

	@Override
	public Object postProcessAfterInitialization(Object bean, String beanName) throws	BeansException {
		log.info("param beanName={} bean={}", beanName, bean.getClass());

		//프록시 적용 대상 여부 체크
		//프록시 적용 대상이 아니면 원본을 그대로 반환
		String packageName = bean.getClass().getPackageName();
	
		if (!packageName.startsWith(basePackage)) {
			return bean;
		}
	
		//프록시 대상이면 프록시를 만들어서 반환
		ProxyFactory proxyFactory = new ProxyFactory(bean);
		proxyFactory.addAdvisor(advisor);
		Object proxy = proxyFactory.getProxy();
	
		log.info("create proxy: target={} proxy={}", bean.getClass(),
		
		proxy.getClass());
		return proxy;
	}
}

AnnotationAwareAspectJAutoProxyCreator라는 빈 후처리기가 자동으로 등록이 됨?

(자동 프록시 생성기)

모든 Advisor 빈을 조회함. 이에 있는 포인트컷을 이용하여 해당 객체에 프록시를 적용할 지 결정함.

해당 객체의 모든 메서드를 포인트컷에 매칭해봄. 하나라도 만족하면, 프록시 대상이 됨.

위처럼 따로 PostProccesor를 구현안해도 됨. 그냥 Advisor만 빈으로 등록하면 됨.

→ 스프링이 알아서 프록시로 해줌.

근데 여러 advisor가 있다면 순서는 어떻게 적용이 되는지? → @Order로 선언을 해주면 되나.(이는 강의에는 없음. 뒤쪽에 나옴)

스프링이 자체로 내부에서 사용하는 bean에도 해당 패턴이 있으면 로그를 남기는 문제가 있음.

(orderController 같은 빈을 등록할 때도 로그가 남음. pattern에서 order라는 메소드가 들어가있으면, 전부 로그를 남기도록 했기 때문.)

AspectJExpressionPoincut으로 이를 해결가능함.

실무에서 이를 주로 이용한다고 함.

정규표현식으로 처리 가능.

(자세한 건 AOP 부분에서 설명 나오는 듯 함.)

만약 여러 개의 advisor를 등록 시, 하나의 adivsor의 포인트컷만 만족해도 프록시로 생성됨. 대신 프록시에 만족하는 advisor만 포함.

(그렇다면 조건마다 여러 프록시 객체가 만들어지는 것인가? 아니면 하나의 프록시에서 매번 포인트컷으로 필터링을 하는지)

Aspect 프록시

@Aspect 어노테이션으로 편리하기 프록시 생성가능.

@Aspect
public class LogTraceAspect {
	
	...

	//pointcut
	@Around("execution(*hello.proxy.app..*(..))")
	public Object method(ProceedingJoinPoint joinPoint) throws Throwable {
		//joinPoint에 정보가 들어있음.(메소드)
		//Advice 로직 작성하면 됨.
	}

	...
}

앞에서 본 AnnotationAwareAspectAutoProxyGenerator는 @Aspect의 Around부분을 Advisor로 변환하여 저장해줌.

순서 정하려면 @Order 사용하면 됨

@AOP(Aspect Oriented Programming)

애플리케이션은 핵심기능(비즈니스 로직?), 부가기능(트랜잭션, 로그 추적 등)으로 구분할 수 있음.

중복되는 부가 기능을 여러 클래스에 적용하려면?

→ 모든 클래스에 적용하기 위해 코드를 수정해주거나 유틸리티 클래스를 만들어서 적용시킴.

→ 이는 유지보수 하기 힘들고 구조가 복잡해짐.

이를 해결하기 위해 AOP가 나옴.

횡단 관심사를 깔끔하게 모듈화할 수 있음.

오류 검사 및 처리
동기화
성능 최적화(캐싱)
모니터링 및 로깅

어떤 방식으로 로직을 추가할 수 있나?

컴파일 시점(AspectJ 사용)
- 컴파일된 시점에 원본 로직에 부가 기능 로직이 추가됨. 위빙이라고 함.
- 단점은 특별한 컴파일러가 필요하고 복잡함.
클래스 로딩 시점(AspectJ 사용)
- 자바는 JVM에 내부의 클래스 로더에 .class 파일을 저장함.
- 이 시점에 aspect를 적용하는 것이 로드 타임 위빙임
- 로더 조작기를 지정해야 하는데, 번거롭고 운영하기 어려움.
런타임 시점(프록시, 지금까지 했던 것.)
- DI, 프록시, 빈 포스트 프로세서 같은 것들을 동원해서 프록시를 통해 스프링 빈에 부가 기능을 추가함.
- 프록시를 사용하기 때문에 일부 제약이 있음. 메서드 호출에만 적용할 수가 있음.(생성자에는 안됨?)
- 실제 대상 코드는 그대로 유지가 됨. 항상 프록시를 통해서 조작함.
- 스프링 빈에만 적용이 가능함.

AspectJ는 사용하기 어려움.

스프링 AOP는 편리함. 그리고 실무에서는 이 기능만 이용해도 대부분의 문제를 해결할 수 있음.

AOP 용어

JoinPoint

어드바이스가 적용될수 있는 위치, 메소드 실행, 생성자 호출, 필드 값 접근, static 메서드 접근 같은 프로그램 실행 중 지점.
AOP를 적용할 수 있는 모든 지점.(~~앞에서는 생성자는 안된다고 하지 않았나~~)
스프링 AOP는 프록시 방식 사용하기 때문에, 메소드 실행 지점으로 제한됨.

Pointcut

어드바이스가 적용될 위치 선별.
스프링 AOP는 메서드 실행 지점에만 설정가능.

Target

어드바이스를 받는 객체. 포인트컷으로 결정.

Advice

부가 기능

Aspect

어드바이스 + 포인트컷을 모듈화 한 것.
@Aspect
여러 어드바이스와 포인트 컷 존재.

Advisor

하나의 어드바이스와 하나의 포인트 컷.
스프링 AOP에서만 사용하는 용어

Weaving

포인트 컷으로 결정한 타겟의 조인 포인트에 어드바이스 적용하는 것.
핵심 기능에 영향 주지 않고 부가 기능 추가함.

AOP proxy

AOP를 적용하기 위한 프록시

@Pointcut("execution(* hello.aop.order..*(..))") //pointcut expression
private void allOrder(){} //pointcut signature

@Around("allOrder()")
public Object doLog(ProceedingJoinPoint joinPoint) throws Throwable {
	log.info("[log] {}", joinPoint.getSignature());
	return joinPoint.proceed();
}

//hello.aop.order 패키지와 하위 패키지
@Pointcut("execution(* hello.aop.order..*(..))")
public void allOrder(){}

//클래스 이름 패턴이 *Service
@Pointcut("execution(* *..*Service.*(..))")
private void allService(){}

//hello.aop.order 패키지와 하위 패키지 이면서 클래스 이름 패턴이 *Service
@Around("allOrder() && allService()")
...

//pointcut을 다른 클래스에서 만들었다면?
@Around("hello.aop.order.aop.Pointcuts.allOrder()")
...

드디어 순서 관련해서 나옴.

하나의 애스펙트에 여러 어드바이스가 있으면 순서를 보장받을 수 없음.

(method에 @Order을 해도 순서가 보장이 안됨)

그래서 클래스 단위로 쪼개야 함.

pointcut excecution 지시자(주로 사용됨)

"execution(public String hello.aop.member.MemberServiceImpl.hello(String))"

매칭 조건

접근제어자?: public
반환타입: String
선언타입?: hello.aop.member.MemberServiceImpl
메서드이름: hello
파라미터: (String)
예외?: 생략

. 은 해당 위치의 패키지

..은 그 하위 패키지도 포함.

파라미터에서 (..) 은 파라미터 타입과 수가 상관없다는 뜻. *은 무슨 타입이든 상관 없다는 뜻.

그리고 부모 타입으로 설정하면 자식 타입도 다 적용 가능 함.

(단, 부모 타입에 있는 메서드만 적용됨.)

within은 타입만 지정. 타입 내의 모든 메소드에 적용.

주의점은 타입이 정확하게 맞아야 함(부모 타입 안됨)

“within(hello.aop.member.MemberServiceImpl)”

target은 부모 클래스의 메서드까지 적용 됨.(자식 클래스가 아님. 부모임)

args은 인자가 주어진 타입의 인스턴스인 조인 포인트로 매칭.

(execution의 인자 부분. execution은 인자의 타입이 정확히 매칭되어야 함. args는 부모 타입 허용함.)

args는 단독 사용 보다는 보통 파라미터 바인딩에서 주로 사용됨.

“args(String)”

@target, args, @args는 혼자 사용이 안됨.

(이유는 잘 이해가 안감. 추후 복습 필요.)

@annotation은 해당 어노테이션이 있으면 적용함.

“@Around(”@annotation(hello.aop.member.annotation.MedthodAop”)

bean 이름으로도 적용가능

@Around("bean(orderService) || bean(*Repository)")

이런 식으로 인자로 뭔가를 받을 수 있음?

@Around("allMember() && args(arg,..)")
public Object logArgs2(ProceedingJoinPoint joinPoint, Object arg) throws Throwable{
	...
}

뒤에 ..이 있으면 더 받을 수도 있는 건가…? 어렵네. 잘 모르겠음 이 부분도.

→ 나중에 맨 정신일 때 봐야할듯.

(잘 사용은 안한다고 함. 중요하지 않다고 하심.)

this는 스프링 빈 객체(aop 프록시)를 대상으로 하는 조인 포인트.

target은 프록시가 실제로 가르키는 실제 대상으로 하는 조인 포인트.

(이 부분은 그냥 듣기만 함. 메모 안했음.)

@Around("@annotation(retry)")
public Object doRetry(ProceedingJoinPoint joinPoint, Retry retry) throws Throwable

이런 식으로도 인자 받을 수 있음. 인자로 Retry retry가 있기 때문에 자동으로 해당 annotation에 대한 정보를 받아올 수 있음.

AOP 실무 유의점

aop를 적용하려면 항상 프록시를 통해 객체를 호출해야함.

문제는 대상 객체의 내부에서 메서드 호출이 발생하면, 프록시를 거치지 않고 대상 객체를 직접 호출함.(실무에서도 만날 수 있는 문제라고 하심)

@Slf4j
@Component
public class CallServiceV0 {
	public void external() {
		log.info("call external");
		internal(); //내부 메서드 호출(this.internal()) 프록시를 거치지 않음.
	}

	public void internal() {
		log.info("call internal");
	}
}

@Slf4j
@Aspect
public class CallLogAspect {
	@Before("execution(* hello.aop.internalcall..*.*(..))")
	public void doLog(JoinPoint joinPoint) {
		log.info("aop={}", joinPoint.getSignature());
	}
}

1. //프록시 호출
2. CallLogAspect : aop=void hello.aop.internalcall.CallServiceV0.external()
3. CallServiceV0 : call external
4. CallServiceV0 : call internal

internal에는 프록시가 호출이 되지 않았음. 그 이유는 this.internal()을 호출하기 때문임.

proxy → target이 되는데 target에서 자신의 method를 호출함.

스프링 프록시의 한계임.

AspectJ는 이런 문제가 발생하지 않음. 그 이유는 실제 byte code를 조작해서 코드를 넣어버리기 때문에.

이를 해결하기 위해서 자기 자신을 주입하면 됨

@Slf4j
@Component
public class CallServiceV1 {
	private CallServiceV1 callServiceV1;

	//생성자로 하면 순환 참조를 하기 때문에 문제가 생김. 프록시가 먼저냐 이 bean이 먼저냐.
	//그래서 setter로 주입을 함. 실무에서 신경쓰기 진짜 어려울 듯.
	@Autowired
	public void setCallServiceV1(CallServiceV1 callServiceV1) {
		this.callServiceV1 = callServiceV1;
	}

	public void external() {
		log.info("call external");
		callServiceV1.internal(); //외부 메서드 호출
	}

	public void internal() {
		log.info("call internal");
	}
}

그 다음 해결책은 지연 조회

@Slf4j
@Component
@RequiredArgsConstructor
public class CallServiceV2 {
	// private final ApplicationContext applicationContext;
	//기본편 싱글톤에 프로로타입 주입할 때 봤던 것.
	private final ObjectProvider<CallServiceV2> callServiceProvider;

	public void external() {
		log.info("call external");
		// CallServiceV2 callServiceV2 =
		applicationContext.getBean(CallServiceV2.class);
		CallServiceV2 callServiceV2 = callServiceProvider.getObject();
		callServiceV2.internal(); //외부 메서드 호출
	}

	public void internal() {
		log.info("call internal");
	}
}

ObjectProvider는 실제 객체를 사용할 때 빈을 찾아옴. 자기 자신을 주입받지 않음.

앞에서는 뭔가 어색함.

제일 좋은 방법은 내부 호출이 없도록 구조를 바꾸는 방법임. 스프링에서도 이 방법을 권장함.

@Slf4j
@Component
@RequiredArgsConstructor
public class CallServiceV3 {
	private final InternalService internalService;
	public void external() {
		log.info("call external");
		internalService.internal(); //외부 메서드 호출
	}
}

@Slf4j
@Component
public class InternalService {

	public void internal() {
	log.info("call internal");
	}

}

깔끔하긴 한데 클래스 파일이 너무 많이 생길 것 같은데?

jdk 동적 프록시 한계점.

구체 타입으로 캐스팅이 불가능함. 인터페이스만 가능.

e.g)

interface MemberService ← MemberServiceImpl

MemberServiceImpl proxy = (MemberServiceImpl) proxy.getProxy();

하면 에러가 발생함.(타입 캐스팅 에러)

CGLIB는 성공함. MemberService로도 됨.

이러한 타입 캐스팅 에러는 의존관계 주입 시에 발생함.

@Slf4j
@SpringBootTest(properties = {"spring.aop.proxy-target-class=false"}) //JDK 동적 프록시, DI 예외 발생
//@SpringBootTest(properties = {"spring.aop.proxy-target-class=true"}) //CGLIB 프록시, 성공
@Import(ProxyDIAspect.class)
public class ProxyDITest {

	@Autowired MemberService memberService; //JDK 동적 프록시 OK, CGLIB OK
	@Autowired MemberServiceImpl memberServiceImpl; //JDK 동적 프록시 X, CGLIB OK

	@Test
	void go() {
		log.info("memberService class={}", memberService.getClass());
		log.info("memberServiceImpl class={}", memberServiceImpl.getClass());
		memberServiceImpl.hello("hello");
	}
}

CGLIB는 구체 클래스를 기반으로 만들어 지고,

JDK 동적 프록시는 인터페이스 기반으로 만들어지기 때문에.

보통 추상화한 인터페이스로 DI를 받아야 함. DI의 장점은 OCP인데, 이러한 장점이 사라짐.

잘 설계되어 있다면, 이러한 문제가 거의 발생하지 않음.

하지만 구체 클래스를 쓰는 경우가 필요한 경우도 있음.

그럼 CGLIB만 사용하면 되지 않나?

→ 문제점이 있음.

대상 클래스에 기본 생성자 필수임.
- 이는 구체 클래스를 상속 받음. super()가 자동으로 실행됨. 그렇기 때분에 기본 생성자를 만들어야 함.(파라미터가 없는 생성자)
생성자 2번 호출됨
- target객체 생성할 때 생성자가 호출됨. 그리고 프록시 객체를 생성할 때 부모 클래스의 생성자 호출 됨.
final 키워드 클래스, 메서드 사용 불가.
- 클래스에 final 있으면 상속이 안됨. 메서드에 있으면 오버라이딩이 안됨.

스프링 4.0 부터는 objenesis 라는 라이브러리를 이용하여 기본 생성자 없어도 객체 생성이 가능해짐.

4.0부터 CGLIB 생성자 2번 문제 호출도 해결되었음.

→ CGLIB의 단점이 사라짐.(final 클래스나 final 메서드는 거의 사용되지 않음.

스프링 부트 2.0부터 CGLIB를 기본를 사용함으로써 구체 클래스 타입 캐스팅을 할 수 있게 했음.

스프링이 어렵다는 것을 다시 한 번 느낄 수 있었습니다. 제가 모르는 것이 너무 많네요.

현재 회사에서 실무에 투입되기 전에 다른 강의도 좀 보고 가야할 것 같습니다.

특히 db와 spring에 대해 좀 공부를 할 필요성이 있는 것 같네요.

이번 강의도 좋았습니다. 스프링 부트에서 주로 사용하는 패턴들도 보고, 이를 활용해서 다양한 기능을 구현하는 것이 인상깊었습니다.

디자인 패턴도 공부를 해봐야 겠네요. 대충만 알고 있었는데, 이번 강의들을 통해 부족함을 많이 느낄 수 있었습니다.

저작자표시 비영리 동일조건 (새창열림)

'BackEnd > spring' 카테고리의 다른 글

[Spring] AOP 테스트 (2)	2023.12.21
[Spring] 빈 주입 null pointer exception 발생 (0)	2023.08.22
[인프런] 스프링 핵심원리 기본편(김영한) 정리 (0)	2023.07.28
[Spring] XSS 방지 (0)	2023.05.26
@Transactional, Connection Pool deadlock (0)	2023.02.17

하용권

[인프런] 스프링 핵심 원리 고급편(김영한) 정리

'BackEnd > spring' 카테고리의 다른 글

티스토리툴바

[인프런] 스프링 핵심 원리 고급편(김영한) 정리

'BackEnd > spring' 카테고리의 다른 글

관련글

티스토리툴바