이 글은 인프런의 김영한님의 강의를 듣고 복습하며 정리한 글입니다. JDK 동적 프록시, CGLIB 동적 프록시 이전 글(https://ojt90902.tistory.com/700)에서 동적 프록시를 생성하기 위해 Java의 리플렉션 기술을 활용해 동적으로 메서드를 뽑아냈다. 그리고 이 기술을 바탕으로 구현된 JDK 동적 프록시 기술로 프록시 객체를 만들어 의존관계 주입을 통해 횡단 관심사를 처리했다. 그런데 한 가지 문제점이 있었다. JDK 동적 프록시는 반드시 인터페이스가 있는 환경에서만 사용할 수 있었다. 왜냐하면 인터페이스의 클래스 로더, 클래스 메타 정보 등을 넣어주어 동적으로 메서드를 뽑아오기 때문이다. 이처럼 인터페이스 없이 구체 클래스만 있을 때는 CGLIB라는 라이브러리를 이용해 대상 객..
이 글은 인프런의 김영한님 강의를 보고 복습하며 정리한 글입니다. 동적 프록시의 필요 앞선 글(https://ojt90902.tistory.com/699)에서 프록시 개념을 도입했다. 다형성을 이용해 프록시 개념을 많이 도입했고, 그 덕분에 원본 코드의 수정이 없이 로그 추적기를 필요한 클래스에 적용할 수가 있었다. 그렇지만 한계점은 명확했다. 한계점은 프록시를 도입하고자 하는 클래스만큼 프록시 클래스를 하나하나 만들어줘야한다는 것이다. 적용 클래스가 몇 개 정도면 만들어서 등록하면 되지만, 클래스가 수백개가 되면 사실 상 불가능한 일이다. 그렇다면 어떻게 해야할까? 앞선 글에서 작성되었던 프록시 객체의 코드다. 코드를 자세히 뜯어보면 다음을 알 수 있다. 부가 기능을 적용하는 코드가 거의 똑같다. 실제..
이 강의 인프런의 김영한님의 강의를 듣고 복습하며 작성한 글입니다. 템플릿 콜백 패턴은 오리지날 코드의 변경 필요 앞서 작성한 글(https://ojt90902.tistory.com/698)에서 템플릿 메서드 패턴, 전략 패턴, 템플릿 콜백 패턴 등을 이용해서 로그 추적기를 좀 더 편리하게 작성을 했었따. 마지막에는 템플릿 콜백 패턴에 익명 클래스의 오버라이딩을 이용해서 반복되는 코드 부분을 최소화했었다. 그렇지만 한계점은 명확하다. 왜냐하면 이런 저런 템플릿을 만들고, 원본 코드에서 익명 클래스의 오버라이딩이 필요하기 때문이다. 즉, 원본 코드에서의 변경이 필요하다. 좀 더 편하게 수정할 수 있게 된 것이지, 하나하나 손이 가는 것은 마찬가지다. 원본 코드에 손을 대지 않으면서 원하는 형태가 실행될 수..
이 포스팅은 인프런의 김영한님 강의를 듣고 복습하며 정리한 내용입니다. 템플릿 메서드 패턴, 전략 패턴, 템플릿 콜백 패턴의 적용 필요 앞선 게시글(https://ojt90902.tistory.com/696)에서 쓰레드 로컬까지 활용해서 로그 추적기를 적용했다. 그런데 한 가지 문제가 있었다. 바로 로그 추적기를 사용하기 위해서 실제 사용되는 코드 영역에서 핵심 기능을 위한 코드보다, 로그 추적기 구현을 위한 코드가 더 많다는 점이다. 배보다 배꼽이 큰 상황이다. 클래스가 몇 개 안된다면 아무 문제가 없으나, 수백 개가 될 경우 문제가 된다. 손이 많이 가고, 정확도도 떨어질 수 있다. 그렇다면 이런 문제를 어떻게 해결해야할까? 먼저 앞서 작성된 코드를 한번 살펴보자. 앞서 작성된 코드를 한번 들여다보면..
이 게시글은 인프런 김영한님 강의를 듣고 복습하며 기록한 글입니다. 동시성 문제 동시성 문제는 멀티 쓰레드 환경에서 발생하는 문제다. 위의 그림처럼 여러 쓰레드가 동시에 동일한 자원에 접근해서 수정을 하는 경우 발생한다. 왜냐하면 동시에 값을 수정했을 때, 각 쓰레드가 기대하던 값과는 다른 형태의 값이 들어올 가능성이 있기 때문이다. 바꿔 이야기 하면, 멀티 쓰레드 환경이라고 하더라도 싱글톤 객체에 단순히 '조회'만 하는 것이라면 동시성 문제가 발생하지 않는다. 문제는 동시에 동일한 자원에 접근해서 수정을 했을 때 발생한다. 또한 동시성 문제는 지역 변수에서 발생하지 않는다. 지역 변수는 쓰레드마다 각각 다른 메모리 영역이 할당되기 때문이다. 동시성 문제는 결국 같은 공간에 여러 쓰레드가 동시에 수정을 ..