[JVM 밑바닥까지 파헤치기] 9. 클래스 로딩과 실행 서브시스템, 사례와 실전

저우즈밍 님의 "JVM 밑바닥까지 파헤치기" 책을 정리한 포스팅 입니다

 

1. 톰켓: 정통 클래스 로더 아키텍처

여러 개의 클래스 로더 

웹 애플리케이션 별로 격리

• 애플리케이션이 클래스 라이브러리를 독립적으로 사용할 수 있도록 보장
• 한 서버에 여러 버전이 공존할 수 있음

 

클래스 라이브러리는 웹 애플리케이션에 공유 가능

• 클래스 로더의 위임 모델 활용
• lib, classes 디렉토리 제공

 

서버는 웹 애플리케이션들의 영향을 최대한 받지 않아야 함

• 보안과 안정성을 고려하여 격리된 환경을 제공

 

클래스 라이브러리 디렉토리 (웹 앱 클래스 로더)

/lib

• 톰켓 자신과 모든 웹 애플리케이션

 

/webapp/WEB-INF

• 해당 웹 애플리케이션

 

핫 스왑 지원 (JSP 클래스 로더)

• 서버를 재시작하지 않고도 수정된 JSP 파일이 즉시 반영됨
• 자동으로 컴파일 된 후 실행됨
• 웹 로직은 지원 X

 

2. OSGi: 유연한 클래스 로더 아키텍처

• 자바 기반 동적 모듈 명세

 

번들

• 클래스 라이브러리 (JAR 형태)

 

모듈 간 가시성 제어

• 의존하는 패키지를 선언하거나
• 외부에 공개할 패키지를 선언할 수 있음

 

모듈 수준의 핫 스와프

• 프로그램 일부만 비활성화 or 활성화 가능

 

3. 동적 프락시 구현

바이트코드 생성 기술

javac 컴파일러

• 소스코드 수준에서 바이트코드 생성
• 정적 컴파일 수행

 

JSP 컴파일러

• 런타임에서 JSP 파일을 서블릿 파일로 변환하는 과정에서 바이트코드 생성 기술 사용

 

AOP 프레임워크

• 기존 클래스의 바이트코드를 변경하거나 새로운 코드를 삽입
• AspectJ, Spring AOP

 

동적 프락시

• 자바 코드를 런타임에 프락시 객체를 생성하는 기술
• 호출된 메서드를 인터펩트
• 원래 객체의 정보 없이 프락시 객체를 생성

 

java.lang.reflect.Proxy

Proxy.newProxyInstance(
    obj.getClass().getClassLoader(),
    obj.getClass().getInterfaces(),
    this
);

• 표준 자바 API
• 인터페이스 기반

 

GCLIB

• 런타임에 클래스의 바이트코드를 생성하여 프락시 객체 생성
• 메서드 오버라이딩을 통해 동작 변경
• 인터페이스 없어도 됨