Wie trennen Tomcat Classloader verschiedene Webapps-Objektbereiche in derselben JVM?

Question

Da Tomcat mehrere Webapps gleichzeitig laden kann, können diese Webapps getrennt arbeiten und stören sich nicht gegenseitig, und sie arbeiten in derselben JVM. So bin ich sehr verwirrt darüber, wie Tomcat den Objektbereich in der gleichen JVM behandelt.

Zum Beispiel habe ich ein Singleton-Objekt in den beiden verschiedenen Webapps, und Tomcat wird zwei verschiedene Singleton-Objekt für jedes generieren. Ich dachte immer, dass das Singleton-Objekt nur ein Objekt in der gleichen JVM hat, aber in Tomcat JVM gibt es vielleicht zwei oder mehr.

---

ich einige Informationen über die Classloader gelesen haben, hat Tomcat seine eigene WebAppClassLoader Webapps zu laden. Also bedeutet es, dass der Objektbereich hier der ClassLoader ist oder ich falsch liege. Kennt jemand darüber oder kann mir etwas über tomcat Arbeitsspeicherlayout geben?

Answer 1

Alle Geheimnisse sind hinter diesen ClassLoader Instanzen.

Der Status der Klasse (wie alle statischen Variablen, Bytecode usw.) wird durch den Klassenlader festgelegt, der diese Klasse lädt (die Klasse wird durch ihren Namen und der Klassenlader durch das Laden der Klasse identifiziert. Dies ist nicht der Fall) genau ein Bereich, aber denken als Umfang hilft normalerweise, dieses besser zu verstehen).

Wenn also eine Klasse von zwei verschiedenen Klassenladern geladen wird, existiert diese Klasse zweimal innerhalb der VM, sie hat zwei Sätze statischer Felder, kann verschiedene Bytecodes haben (wie verschiedene Methodenimplementierungen) und alle solche. Bei "normalen" Java-Anwendungen werden alle Klassen von einer Klassenladerhierarchie geladen, und jede Klasse wird nur einmal geladen.

Für komplexere Szenarien benötigen Sie ein anderes Verhalten. Manchmal möchten Sie eine Bibliothek davon abhalten, sich mit Ihrem Code herumzuärgern (wie Plug-Ins in Eclipse- oder Web-Anwendungen in einem Anwendungsserver).

Die Grundidee, Ihr Programm von anderen Klassen zu isolieren, besteht darin, diese mit einem zusätzlichen Klassenlader zu laden und viel Reflexion zu verwenden. Wenn Sie darüber nachlesen möchten, werfen Sie einen Blick in die Dokumentation von Oracle unter ClassLoaders oder OSGI.

Tomcat (und viele andere Webcontainer/Anwendungsserver) laden die Anwendung mit separaten ClassLoader-Hierarchien. Dies isoliert alle Klassen gegen andere (Web-) Anwendungen und stellt somit auch sicher, dass Singletons, verschiedene Klassenversionen und all diese Dinge nicht kollidieren.

Answer 2

Eine Sache, die immer ausgelassen wird, wenn über Singletons gesprochen wird, ist, dass ein Singleton nur eine Instanz pro Classloader haben kann. A ClassLoader schränkt die Klassensichtbarkeit ein, sodass dieselbe Klasse unter mehreren verschiedenen Klassenladeprogrammen in derselben VM vorhanden sein kann. Dies ermöglicht Ihnen unter anderem, verschiedene Versionen von Gläsern gleichzeitig geladen zu haben.

Diese Frage: Java Class Loaders scheint einige nette Links und Ressourcen für das weitere Studium zu haben.

Answer 3

Die "ID" einer Klasse in der JVM besteht aus dem vollständig qualifizierten Klassennamen und dem Klassenlader, der zum Laden verwendet wurde. Das heißt, wenn Sie zwei Klassen mit demselben Namen von verschiedenen Klassenladeprogrammen laden, werden sie als unterschiedliche Klassen betrachtet.

Answer 4

Denken Sie daran, dass eine Klasse in Java durch ihren vollständig qualifizierten Namen und den Klassenlader identifiziert wird, der sie geladen hat. Tomcat verwendet separate Klassenladeprogramme für jeden von Ihnen bereitgestellten Kontext (Webanwendung) und hält sie somit getrennt. Darüber hinaus lädt der System-Classloader die Tomcat-spezifischen Bibliotheken und der JVM-Bootstrap-Loader lädt die Java-Core-Bibliotheken.

Answer 5

So ein Singleton wäre Singleton für einen Klassenlader - in einem Container/JVM; als Container/JVM könnte mehrere Klassenlader haben.

Answer 6

In normalen Java-Anwendungen, wenn ein Klassenlader aufgefordert wird, eine Klasse zu laden, delegiert er die Anfrage zuerst an den übergeordneten Klassenlader und lädt sie dann, wenn Elternklasse-Lader die angeforderte Klasse nicht finden können.

Für Webanwendungsserver unterscheidet sich dies geringfügig. Für jede Webanwendung, die auf einem Webanwendungsserver wie Tomcat bereitgestellt wird, gibt es im Allgemeinen unterschiedliche Klassenladeprogramme. Für Tomcat sieht es aus wie unten -

Also für Web-Anwendungen Klasse Laden Ressource geschieht in folgenden Reihenfolge -

1. Bootstrap Klassen Ihrer JVM (Core Java-Klassen)
2. /WEB- INF/Klassen Ihrer Webanwendung
3. /WEB-INF/lib/*.jar Ihrer Webanwendung
4. Systemklassenladeklassen (Tomcat/Classpath specif ic-Klassen)
5. Gemeinsame Klassenlader-Klassen (Klassen, die für alle Web-Anwendungen)

Aber beachten Sie, wenn Web-Anwendung Klassenlader mit delegate="true" dann um so konfiguriert ist, geändert wird -

1. Bootstrap Klassen Ihrer JVM (Core Java-Klassen)
2. Systemklassenladeklassen (Tomcat/Klassenpfadspezifische Klassen)
3. Gemeinsame Klassenladeklassen (Klassen, die allen Webanwendungen gemeinsam sind)
4. /WEB-INF/classes Ihrer Web-Anwendung
5. /WEB-INF/lib/*.jar Ihrer Webapplikation

Für weitere Details, die Sie Class Loader HOW-TO Seite Apache Tomcat überprüfen.

Answer 7

1. Verschiedene App in Tomcat mit verschiedenen Classloader zu trennen. Zum Beispiel App1 mit ClassLoaderA, App2 mit ClassloaderB.
2. Jede Klasse verwendet einen eigenen Klassenlader, um andere Klassen zu laden. Wenn also ClassA.class auf ClassB.class verweist, muss ClassB auf dem Klassenpfad des Classloaders von ClassA oder seinen Eltern sein. Zum Beispiel In app1, com.exmaple.test1 von ClassLoaderA geladen. Und com.exmaple.test1 möchte neue com.exmaple.test2(). Standardmäßig verwendet es seinen eigenen Klassenlader ClassLoaderA, um com.exmaple.test2 zu laden. In der Ansicht von com.exmaple.test1 kann nur die Klasse des eigenen Klassenpfads (app1/webapp/classes oder app1/webapp/lib) angezeigt werden. Und in App2 wird es eine andere Ansicht sehen.
3. Zusammenfassend lernen Sie Klassenladeprogramm Sie müssen das Delegationsmodell verstehen. Und die Sichtbarkeit ist das Kind kann die Eltern sehen. aber das Elternteil kann das Kind nicht sehen und das Geschwisterkind kann das Geschwisterkind nicht sehen.So können wir verschiedene App isolieren.