Apabila Tomcat memuat modul Spring-Web, adakah mekanisme SPI benar-benar memusnahkan prinsip penglihatan Java Class Loaders?

Tomcat dan Spring-Web Module Loading: Analisis tingkah laku pemuatan kelas di bawah mekanisme SPI

Apabila Tomcat memuat modul Spring-Web, ia menggunakan mekanisme Java SPI (Interface Penyedia Perkhidmatan) untuk mencari dan menggunakan kelas pelaksanaan antara muka ServletContainerInitializer . Ini melibatkan kaedah load ServiceLoader dan prinsip penglihatan loader kelas. Sesetengah orang mempersoalkan pendekatan ini melanggar prinsip penglihatan pemuat kelas, jadi mari kita menganalisisnya secara mendalam.

Artikel menunjukkan bahawa kaedah ServiceLoader.load akhirnya dimuatkan oleh sun.misc.Launcher.AppClassLoader untuk memuatkan kelas pelaksanaan antara muka ServletContainerInitializer . Dalam kod, ServiceLoader.load(service, cl) menggunakan Thread.currentThread().getContextClassLoader() untuk mendapatkan loader kelas. Dalam pelayan aplikasi seperti Tomcat, loader kelas ini biasanya AppClassLoader .

Sesetengah orang berfikir bahawa ServiceLoader.load(service, cl) bersamaan dengan ServiceLoader.load(service, null) . Walaupun hasilnya sama dalam beberapa kes, prinsipnya berbeza. Bekas yang secara eksplisit menentukan loader kelas, sementara yang terakhir menggunakan loader kelas pemanggil.

Kenapa ada yang menganggap ini memecahkan prinsip penglihatan pemuat kelas? Kuncinya terletak pada kekhususan mekanisme SPI. Antara muka dalam rt.jar dimuatkan oleh BootstrapClassLoader , tetapi kelas pelaksanaannya biasanya di ClassPath dan dimuatkan oleh AppClassLoader . BootstrapClassLoader tidak boleh dimuat ke bawah, jadi loader kelas konteks benang perlu memuat kelas pelaksanaan. Ini memintas hierarki yang ketat model delegasi induk, yang membolehkan AppClassLoader memuat kelas yang BootstrapClassLoader tidak dapat dimuatkan. Walaupun masalah itu diselesaikan, ia juga menyimpang dari niat asal model delegasi induk.

Perlu ditekankan bahawa AppClassLoader tidak secara langsung melangkau kod mekanisme delegasi induk, dan ia masih mengikuti logik delegasi induk secara dalaman. Ia hanya dalam senario SPI yang disebabkan oleh batasan BootstrapClassLoader , kerja pemuatan akhir dilakukan oleh AppClassLoader , yang merupakan perdagangan. Mekanisme JDBC adalah serupa. Java hanya menyediakan antara muka. Pelaksanaan khusus disediakan oleh pengilang, dan sekatan mekanisme delegasi induk juga diperlukan untuk memintas.

Oleh itu, mekanisme SPI "melanggar" peraturan ketat model delegasi induk sedikit sebanyak, tetapi ini adalah kompromi yang diperlukan dan tidak sepenuhnya "memusnahkan" prinsip penglihatan pemuat kelas. Ia mendapati cara yang sesuai untuk memuat kelas pelaksanaan melalui loader kelas konteks thread.

Atas ialah kandungan terperinci Apabila Tomcat memuat modul Spring-Web, adakah mekanisme SPI benar-benar memusnahkan prinsip penglihatan Java Class Loaders?. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!