Small Asteroid Blog

라이브러리 추가build.gradle 에 의존성 추가를 해준다. implementation 'org.springframework.boot:spring-boot-starter-aop'위의 라이브러리 추가로 aspectJ 관련 라이브러리를 등록하고 스프링 부트가 AOP 관련 클래스를 자동으로 스프링 빈에 등록해준다.  @Aspect 사용 예제스프링은 @Aspect 어노테이션으로 편리하게 포인트컷과 어드바이스로 구성되어 있는 어드바이저 생성 기능을 지원하며 어드바이저로 사용할 클래스에 @Aspect 어노테이션을 붙여줌으로써 스프링 AOP 를 적용할 수 있다. 주의할 점으로 스플이 AOP 적용시에는 private, final 메소드는 AOP 적용이 불가능하다. @Slf4j@Aspectpublic class As..

AOP란Aspect-Oriented Programming , 관점 지향 프로그래밍이란 뜻으로 어떤 로직을 핵심적인 관점과 부가적인 관점으로 나누어서 보고 그 관점을 기준으로 각각 모듈화하는 것이다. 부가 기능과 부가 기능을 어디에 적용할 지 선택하는 기능을 합해서 하나의 모듈로 만든 것을 Aspect라고 한다. 이 Aspect 를 사용한 프로그래밍 방식을 AOP 라고 한다. AOP는 OOP를 대체하기 위한 것이 아닌 횡단 관심사(하나의 부가 기능이 여러 곳에 동일하게 사용됨)를 깔끔하게 처리하기 어려운 OOP의 부족한 부분을 보조하는 목적으로 개발되었다. AOP 의 대표적인 구현으로는 AspectJ 프레임워크가 있다.  AOP 적용 방식적용 방식에는 크게  3가지 방식이 있다. 컴파일 시점클래스 로딩 시..

@Aspect란 AOP(관점 지향 프로그래밍)를 가능하게 하는 AspectJ 프로젝트에서 제공하는 어노테이션이다.  @Aspect를 스프링 프록시에 적용하려면 어드바이저(Advisor)를 만들어서 스프링 빈으로 등록하면 된다. 그러면 자동 프록시 생성기는 스프링 빈으로 등록된 어드바이저들을 찾고 스프링 빈에 자동으로 프록시를 적용해준다.  @Aspect 프록시 예제  빨간 박스는 포인트컷 부분이고 초록색 박스는 어드바이스 부분이다.  @Aspect를 어드바이저로 변환해서 저장하는 과정 1. 실행 : 스프링 어플리케이션 로딩 시점에 자동 프록시 생성기를 호출한다. 2. 모든 @Aspect 빈 조회 : 자동 프록시 생성기는 @Aspect 어노테이션이 붙은 스프링 빈을 모두 조회한다. 3. 어드바이저 생성 :..

이전에 작성했던 프록시 팩토리의 문제점을 해결하기 위해서 빈 후처리기를 사용한다고 했다. 프록시 팩토리 내용에 대해 알고싶으면 아래 링크를 참고하면 된다. https://bsssss.tistory.com/1482  빈 후처리기란 일반적으로 @Bean 이나 @Component 를 사용하면 스프링은 대상 객체를 생성하고스프링 컨테이너 내부의 빈 저장소에 등록한다. 빈 후처리기는 객체를 조작할 수도 있고, 다른 객체로 바꿔치기 하는 것도 가능하다.  빈 후처리기 - 스프링 빈 등록 과정생성 : 스프링 빈 대상이 되는 객체를 생성(@Bean, 컴포넌트 스캔 포함)전달 : 생성된 객체를 빈 저장소에 등록하기 직전에 빈 후처리기에 전달후 처리 작업 : 빈 후처리기는 전달된 스프링 빈 객체를 조작하거나 다른 객체로 ..

이미지 빌드 중 ./gradlew 실행을 위해 gradle 다운로드하는데 시간이 너무 오래걸리는 문제가 있었다. 빠를때도 있고 느릴때도 있었는데 계속 기다릴 수 없기에... 해결해보는걸로 하자. 찾아보니 종종 배포파일 다운로드가 느리다는 것 같았다. 해결 방법으로는 다운로드 받는 gradle 주소를 변경해서 진행하면 된다. 파일 위치는 gradle/wrapper/gradle-wrapper.properties 에 있고 distributionUrl 에 있는 주소를 변경해주면 된다. Downloading https://services.gradle.org/distributions/gradle-[버전]-bin.zip Downloading https://downloads.gradle.org/distributions..

Thread Pool Thread Pool 은 여러 개의 쓰레드를 유지하고 관리하기 위해 사용된다. Thread Pool 의 사이즈 쓰레드를 불필요하게 많이 만들게 되면 메모리의 낭비가 심해지고 너무 적은 수의 쓰레드를 만들게 되면 효율성이 떨어진다. 쓰레드의 개수를 고정 시키는 것보다 서비스가 실행되는 CPU의 코어 개수에 따라 유동적으로 생성할 수 있도록 해주는 것이 좋다. 많이 생성하는 것이 아니라 어떤 작업을 처리하느냐에 따라 기준이 바뀔 수 있다. CPU 처리가 많은 경우 - CPU 코어가 N개인 경우 N+1만큼의 쓰레드를 생성해주면 최적에 가까운 성능을 낼 수 있다고도 한다. I/O 작업이 많은 경우 - N*2 만큼의 쓰레드를 생성해준다.