티스토리 뷰

기술이야기

Class loader delegation model

novathinker 2008.02.01 16:35

Class loader delegation model을 굳이 우리말로 바꾸자면 Class loader 위임 모델이라고 할 수 있다. 즉 이것은 로딩 요청을 위계적으로 전달하는 방식을 나타내는 것으로 이해할 수 있다. 이 모델을 간단하게 말하자면 class를 로딩할 때 자신의 Class loader의 위계구조의 위쪽 즉 부모의 class loader에게 로딩을 위임하는 것이라 할 수 있다.

Class loader의 위계구조는 위의 그림과 같다. 쉽게 말해 Bootstrap-Extension-Application의 구조를 가지게 된다. Class loader들이 class를 로딩하게 되면 하나의 delegation parent와 함께 생성되고 Cache-Parent-Self의 순서로 해당 class를 확인하게 된다. Class loader가 로딩을 하게 될 때 가장 먼저 하게 되는 일은 해당 Class가 이미 로딩이 되어 있는지를 확인하는 것이다. 만약 로딩이 되어 있다면 메모리에 Cache되어 있을 것이고 이 경우 해당 class를 반환하게 된다. 만약 로딩이 되지 않았다면 부모(parent)에게 class를 로딩하게 위임을 하게 되고 부모가 Class를 로딩할 수 없다면 자신(self class loader)이 클래스를 탐색하게 된다.

이렇게 로딩되는 경우 class를 로딩할 확률은 delegation model의 상위로 갈수록 높아진다. 가장 상위에 있는 bootstrap class loader는 JVM의 수행을 위한 핵심적인 class만을 로딩하게 되고 가장 기본적인 class들의 버전이 정확하게 일치하는지를 확인한다. 또한 각 class가 누구에 의해 로딩이 되었는지에 대한 정보도 제공하고 있다. (참고로 이 정보는 자신을 포함한 상위의 class loader가 로딩한 것만 확인이 가능하고 자신의 하위의 loader가 로딩한 것에 대한 정보는 알 수 없다.)

Bootstrap loader는 VM의 일부로 구현되기 때문에 다른 class loader와는 달리 자바 코드로 인스턴스화 할 수 없다. 이 class loader는 JVM의 수행을 위한 핵심 시스템 class를 로딩하는 데 일반적으로 $JAVA_HOME/jre/lib에 있는 JAR파일들이 그 대상이 된다. 이를 변경하기 위해서는 -Xbootclasspath옵션을 사용하면 된다. Extension class loader는 Bootstrap의 바로 하위에 있는 class loader이다. 주로$JAVA_HOME/ jre/lib/ext에 위치한 JAR파일이 그 대상이 된다. Application class loader는 $CLASSPATH에 지정된 경로에서 class를 로딩한다. 이 class loader는 user-defined class loader의 부모가 된다.

결국 delegation model에 따라class를 로딩하게 때문에 그리고 각 loader가 class를 로딩하는 위치는 정해져 있기 때문에 class loading시 가장 먼저 찾게 되는 경로는 $JAVA_HOME/jre/lib가 되고 그 다음으로는 $JAVA_HOME/ jre/lib/ext, $CLASSPATH의 순서가 된다. 그러므로 가급적 사용자가 정의한 class의 경우는 Core class가 위치한 경로를 피하는 것이 좋다.

Application Server의 경우 delegation model의 위계구조는 아래의 그림처럼 다소 달라진다. 그러나 이것 역시 delegation model을 사용하기 때문에 class를 로딩할 때 parent에게 loading의 의무를 위임하고 parent가 할 수 없는 경우 자신이 class를 로딩하게 된다.

Bootstrap class loader는 JVM의 Class loder와 같이 최상위 Class loader이며 여기에서는 System Class loader의 parent가 된다.

System class loader는 Application Server의 core class의 대부분을 로딩하는 역할을 한다. 이 loader는 env의 classpath변수를 무시하는 별도의 옵션을 주지 않는 이상 $CLASSPATH에 위치한 class파일들이 그 대상이 된다.

Common class loader는 별도의 classpath 설정을 필요로 하지 않으며 기본적으로 domain-dir/lib/classes와 domain-dir/lib에 있는 JAR나 ZIP파일을 그 대상으로 한다. 그러나 이 디렉토리들은 필수적인 것이 아니기 때문에 만약 디렉토리가 없다면 common class loader는 생성되지 않는다.

Connector class loader는 모든 application에 공유가 가능하여 딱 한 개만 존재한다. 이는 개별적으로 deployed된 connector 모듈들을 로딩한다. LifeCycleModule class loader와 EJB class loader의 parent이다.

LifeCycleModule class loader는 모든 lifecycle module들의 parent loader이다. 각 lifecycle module들의 classpath는 각각 class loader가 구성한 경로를 사용한다.

EJB class loader는 EJB module이나 J2EE module내에서 EJB class들을 로딩한다.

WEB class loader는 WEB module이나 J2EE module에사 servlet과 기타 class를 로딩한다.

JSP Engine class loader는 JSP 파일들에서 컴파일된 JSP파일을 로딩한다.

EJB class loader와 WEB class loader 그리고 JSP Engine class loader의 경우는 deploy시 shared 또는 Universe 형태와 Isolation 형태로 나뉘어진다. Shared 또는 Universe 형태는 parent class loader에게 loading을 요청하거나 parent class loader가 직접 class를 로딩할 때 Application내에 있는 모든 해당 parent level의 class loader에게 class를 요청한다. 이 경우 상위 class loader가 reload될 경우 연관이 있는 모든 하위 class loader가 재생성 된다.

Isolation형태는 각 Application마다 각각 EJB-WEB-JSP의 트리가 구성이 된다. 그러므로 한 Application의 class loader에게 class를 요청할 수 없게 되기 때문에 각 Application마다 공통의 class를 사용한다면 모두 각각 loading을 해야만 한다.

참고자료

http://publib.boulder.ibm.com/infocenter/javasdk/v6r0/index.jsp?topic=/com.ibm.java.doc.diagnostics.60/html/cl_delegation.html

http://www.ibm.com/developerworks/java/library/j-dclp1/index.html?S_TACT=105AGX02&S_CMP=EDU

http://docs.sun.com/app/docs/doc/819-4721/6n6rrfqq3?l=ko&a=view

http://docs.sun.com/app/docs/doc/819-4721/6n6rrfqlr?l=ko&a=view#beade

http://technet.tmaxsoft.com/kr/edocs/jeus/50/release/release-0009.htm

저작자 표시 비영리 변경 금지
신고
댓글
댓글쓰기 폼