답변

ClassLoader는 JVM에서 클래스를 처음 사용할 때 바이트 코드를 메모리에 로드하는 특별한 구성 요소입니다. 이는 파일 시스템, 네트워크, 아카이브 등 다양한 출처에서 동적으로 클래스를 로드할 수 있게 해줍니다.

클래스 로더의 유형:

• Bootstrap ClassLoader — 시스템 로더로, JVM의 기본 클래스를 로드합니다 (rt.jar).
• Extension ClassLoader — jre/lib/ext 경로에서 확장을 로드합니다.
• System (Application) ClassLoader — classpath에서 애플리케이션 클래스를 로드합니다.
• Custom ClassLoader — 모듈성, 핫 배포, 플러그인을 위한 사용자 정의 로더입니다.

ClassLoader는 위임을 구현합니다: 먼저 부모 로더에서 클래스를 로드하려고 시도하고 (부모 우선), 실패한 경우에만 스스로 찾습니다.

클래스 격리: 각 클래스 로더는 자신의 "가시성 영역"을 만들습니다. 이름이 같은 두 클래스가 서로 다른 로더에 의해 로드되면 JVM 내에서 서로 다른 유형으로 간주됩니다.

자체 로더 생성의 예:

class MyClassLoader extends ClassLoader {
    @Override
    protected Class<?> findClass(String name) throws ClassNotFoundException {
        // 클래스의 바이트 코드 검색 및 로드 코드
        return super.findClass(name);
    }
}

---

기묘한 질문

이름이 같은 두 클래스가 서로 다른 로더에 의해 로드되면 JVM 내에서 하나의 클래스로 간주될 수 있을까요?

답변: 아니요! JVM은 클래스를 (완전한 클래스 이름, 클래스 로더) 쌍으로 고유하다고 간주합니다. 따라서 같은 클래스가 다른 로더로 로드되면 서로 다르게 간주됩니다.

---

주제에 대한 미숙지로 인한 실제 오류의 예

---

이야기

플러그인 아키텍처를 지원하는 엔터프라이즈 애플리케이션에서 플러그인은 별도의 클래스 로더로 로드되었습니다. 이로 인해 주요 애플리케이션과 플러그인 간의 인터페이스(PluginInterface) 유형의 객체를 전달하려고 하면 ClassCastException이 발생했습니다. 같은 인터페이스가 서로 다른 로더에 의해 로드되었기 때문입니다.

---

이야기

사용자 정의 클래스 로더를 사용할 때 부모 로더에 대한 위임이 구현되지 않았습니다. 이로 인해 표준 라이브러리 클래스가 반복적으로 로드되어 이상한 ClassCastException 및 LinkageError 오류가 발생했습니다.

---

이야기

대규모 Java EE 서버에서 다른 애플리케이션이 동일한 라이브러리의 여러 버전을 로드했습니다. 로더 체인 설정의 부주의로 인해 클래스가 애플리케이션 간에 겹치게 되어 한 번 대규모 메모리 누수와 버전 충돌로 인한 중단이 발생했습니다.