이제는 이 코드가 익숙할 것이므로 더 자세히 살펴보지는 않겠습니다. 이 예제를 실행하면 다음과 같은 결과가 출력됩니다.

<h2>Thanks for playing, try again!</h2>
1000000번 수행 시 걸린 시간: 188 ms
<h1>Thanks for playing, try again!</h1>
1000000번 수행 시 걸린 시간: 24 ms

 

예상대로 replacementTarget 빈의 출력은 Method Replacer가 제공하는 오버라이드된 구현체를 반영합니다. 하지만 재미있게도 동적으로 대체한 메서드가 정적으로 정의한 메서드보다 몇 배 느립니다. MethodReplacer에서 유효한 메서드를 검사하는 부분을 제거하고 여러 번 실행해 봐도 차이가 거의 없으므로 대부분의 오버헤드는 CGLIB 하위 클래스에 있다고 결론 내릴 수 있습니다.

 

3.5.4.4 메서드 대체를 사용해야 할 때

메서드 대체는 다양한 상황에서 매우 유용합니다. 특히 동일 타입의 모든 빈이 아닌 단일 빈에 대한 특정 메서드만 대체하려는 경우에 특히 유용합니다. 하지만 여전히 런타임 바이트 코드 향상에 의존하기보다는 표준 자바 메커니즘을 사용해 메서드를 대체하는 것이 더 바람직합니다.

애플리케이션의 일부에서 메서드 대체를 사용하려는 경우에는 메서드나 오버로드된 메서드 그룹마다 Method Replacer를 하나만 사용하는 것을 권장합니다. 관련이 없는 많은 메서드를 대상으로 하나의 MethodReplacer만을 사용하려는 유혹을 이겨내시기 바랍니다. 이렇게 하면 재구현 한 코드가 동작하는 동안에 불필요한 문자열 비교가 수없이 발생합니다. MethodReplacer가 정확하게 동작하는지 확인하는 간단한 검사를 수행하는 것은 유용하며, 검사 코드 때문에 오버헤드가 과도하게 발생하지는 않습니다. 성능이 정말로 걱정된다면 Boolean 타입 애트리뷰트를 MethodReplacer에 추가하면 의존성 주입을 이용해 검사 여부를 켜고 끌 수 있습니다.