Tomcat이 Spring-Web 모듈을로드하면 SPI 메커니즘이 실제로 Java 클래스 로더의 가시성 원리를 파괴합니까?

Tomcat 및 Spring-Web 모듈 로딩 : SPI 메커니즘에서 클래스 로딩 동작 분석

Tomcat이 Spring-Web 모듈을로드하면 Java SPI (서비스 제공 업체 인터페이스) 메커니즘을 사용하여 ServletContainerInitializer 인터페이스 구현 클래스를 찾고 사용합니다. 여기에는 ServiceLoader 의 load 방법과 클래스 로더의 가시성 원리가 포함됩니다. 어떤 사람들은이 접근법이 클래스 로더의 가시성 원칙을 위반하는 것에 의문을 제기하므로 깊이 분석하겠습니다.

이 기사는 ServiceLoader.load 메소드가 궁극적으로 sun.misc.Launcher.AppClassLoader 에 의해로드되어 ServletContainerInitializer 인터페이스의 구현 클래스를로드합니다. 코드에서 ServiceLoader.load(service, cl) Thread.currentThread().getContextClassLoader() 사용하여 클래스 로더를 얻습니다. Tomcat과 같은 응용 프로그램 서버 에서이 클래스 로더는 일반적으로 AppClassLoader 입니다.

어떤 사람들은 ServiceLoader.load(service, cl) 가 ServiceLoader.load(service, null) 와 동일하다고 생각합니다. 경우에 따라 결과가 비슷하지만 원칙은 다릅니다. 전자는 클래스 로더를 명시 적으로 지정하는 반면 후자는 발신자의 클래스 로더를 사용합니다.

왜 이것이 클래스 로더의 가시성 원칙을 깨뜨린다고 생각 하는가? 핵심은 SPI 메커니즘의 특수성에 있습니다. rt.jar 의 인터페이스는 BootstrapClassLoader 에 의해로드되지만 구현 클래스는 일반적으로 ClassPath에 있으며 AppClassLoader 에 의해로드됩니다. BootstrapClassLoader 아래쪽으로로드 할 수 없으므로 스레드 컨텍스트 클래스 로더가 구현 클래스를로드해야합니다. 이것은 상위 대표 모델의 엄격한 계층 구조를 우회하여 AppClassLoader BootstrapClassLoader 로드 할 수없는 클래스를로드 할 수있게합니다. 문제가 해결되었지만 부모 대표 모델의 원래 의도에서 벗어났습니다.

AppClassLoader 부모 대의원 메커니즘의 코드를 직접 건너 뛰지 않고 내부적으로 상위 대표단 논리를 따르는 것으로 강조해야합니다. SPI 시나리오에서만 BootstrapClassLoader 의 한계로 인해 최종 로딩 작업은 AppClassLoader 에 의해 수행됩니다. JDBC 메커니즘은 비슷합니다. Java는 인터페이스 만 제공합니다. 특정 구현은 제조업체가 제공하며, 상위 대의원 메커니즘의 제한도 우회해야합니다.

따라서 SPI 메커니즘은 상위 대표 모델의 엄격한 규칙을 어느 정도 "위반"하지만 이는 필요한 타협이며 클래스 로더의 가시성 원리를 완전히 "파괴"하지는 않습니다. 스레드 컨텍스트 클래스 로더를 통해 구현 클래스를로드하는 적절한 방법을 찾습니다.

위 내용은 Tomcat이 Spring-Web 모듈을로드하면 SPI 메커니즘이 실제로 Java 클래스 로더의 가시성 원리를 파괴합니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!