ClassLoader의 특징과 종류

ClassLoader가 어떻게 동작하는지 알고 난 뒤 바로 JVM을 정리하려다 ClassLoader의 종류가 여러 개라는 것을 알게 되었다.

처음에는 여러 가지의 ClassLoader 중 한 가지만 JVM에서 사용하는 줄 알았더니 여러 개를 사용한다길래 찾아보았다.

 

설명할 것이 가장 긴 계층적 특징은 맨 마지막에 설명할 예정이다.

- 4가지 특징? -

ClassLoader는 Java의 상속 관계와 닮았다는 느낌을 많이 받았다.

그 예시가 바로 계층적 특징과 가시적인 규약 특징 때문이었다.

 

· 계층적 (Hierarchical)

 코드를 구현하다 보면 중복을 줄이기 위해 상속을 사용하게 된다.

부모 Class를 가진 자식 Class처럼 ClassLoader도 계층적으로 생성이 가능하다.

바로 아래 이미지의 부트스트랩(Bootstrap) ClassLoader가 확장(Extensions) ClassLoader를 가지고 있는 것처럼 말이다.

 

 · 가시적인 규약 (Visibility Constraint)

맨 위에 이미지를 Java 상속에 빗대어 설명해보자.

A Class가 상위 ClassLoader이고 B와 C라는 Class가 하위 ClassLoader에 대입하여 생각해보자.

A Class는 부모 Class이기 때문에 자식 Class인 B와 C의 데이터 사용할 수 없고,

같은 부모 Class를 가진 B와 C도 서로의 데이터를 사용할 수 없다. 

하지만 B와 C Class는 부모인 A Class의 데이터를 사용할 수 있다. (데이터가 지칭하는 것 : Field, Method 등)

 

이처럼 하위 ClassLoader는 상위 ClassLoader의 Class를 위임형 로드 요청 (Delegate Load Request)를

이용하여 찾을 수 있지만, 반대는 불가능하다.

또한 상위 ClassLoader가 같은 하위 ClassLoader는 서로 로딩한 Class를 사용할 수 없다는 일종의 범위 룰(Scope Rule)을

가시적인 규약 (Visibility Constraint)이라고 한다. 

 

 · 위임형 로드 요청 (Delegate Load Request)

상위 ClassLoader가 로딩한 Class가 우선권을 가지는 것을 위임형 로드 요청이라 하는데 예시로 정리해보자.

 

ClassLoader1의 자식 = ClassLoader 2

ClassLoader2의 자식 = ClassLoader3 일 때,

 

ClassLoader 3가 요청을 보낼 때 부모 Class로서 우선권을 가지고 있으니 ClassLoader2에게 Class 로딩을 요청을 할 수 있다.

또한 우선권이 ClassLoader 2에게 있기 때문에, ClassLoader 3이 ClassLoader 1에게 Class 로딩 요청을 보낼 수 없다.

다만 ClassLoader 1까지 요청을 하고 싶다면 위 이미지와 같이

ClassLoader 3 -> ClassLoader 2 -> ClassLoader 1 순서로 요청할 수 있다.

 

 · 클래스 언로드 불가 (Cannot Unload Classes)

ClassLoader에는 Class 언로딩(Unloading) 기능이 없다.

그렇기에 언로딩(Unloading)을 하기 위해선 ClassLoader 자체를 삭제하고, ClassLoader을 다시 생성하는 방법이 있다.

말하자면 테이블 컬럼을 추가 기능이 없어서 테이블 자체를 삭제하고, 컬럼을 추가하여 생성 후 다시 로드하는 느낌이라 볼 수 있을 듯하다.

 

여기까지 ClassLoader에 대한 특징에 대해 정리하였다.

그럼 위에서 언급했던 계층적 특징의 4가지 ClassLoader는 어떤 역활을 하는 것일까?

4가지의 classLoader들은 각각 다른 Class들을 로드하는데 그에 따른 특징도 있다.

 

 1. 부트스트랩 (Bootstrap) Class Loader

JVM이 실행될 때 가장 먼저 실행되는 ClassLoader이며,

($JAVA_HOME/jre/lib/rt.jar) 경로에 있는 Java 실행에 필요한 기본적인 Class 들을  로딩한다.

특이한 점이라면 Java로 구현된 다른 ClassLoader와는 다르게 네이티브 코드로 구현되어 있다.

 

 2. 확장 (Extensions) Class Loader

($JAVA_HOME/lib/ext/*.jar) 경로에 있는 Java 확장 클래스들을 로딩한다.

다만 시스템(System) ClassLoader와는 다르게 Classpath에 설정되어 있지 않아도 되며,

다양한 보안 확장 기능 등을 여기에서 로딩한다.

 

 3. 시스템 (System) Class Loader

Classpath 혹은 JVM 옵션 중 -cp, -classpath에 지정된 Class들이 로딩되며,

애플리케이션의 Class들을 로드한다고 할 수 있다.

즉, 사용자가 지정한 $CLASSPATH 내의 Class들을 로딩한다.

 

 4. 사용자 정의 (User-Defined) Class Loader

애플리케이션 사용자가 직접 코드상에서 생성하여 사용하는 클래스 로더이다.

3가지의 웹 로직(WebLogic) ClassLoader도 사용자 ClassLoader에 포함되며,

부모 ClassLoader는 System ClassLoader이다.

 

글이 길어지는 것 같아 웹 로직(WebLogic) ClassLoader에 대한 것은 다음 글에 정리하겠다.

 

- 회고 -

생각해보면 ClassLoader가 jvm 자체 안에서 돌아가게 했어도 됐을 텐데 굳이 분리한 이유가 무엇일까?

그리고 ClassLoader를 공부하면서 상속 관계에 대한 부분도 겹쳐 보였는데 이런 점에 있어서

Java라는 언어의 OOP라는 개념이 코드뿐만 아니라 다른 영역에도 일부 적용된 것이 아닐까 하는 생각이 들었다.

 

- 참고 블로그 -

https://blueyikim.tistory.com/37