How Tomcat Classloader separates different Webapps object scope in same JVM?

All the secrets is behind those ClassLoader instances.

The state of the class (like all static variables, byte code and so on) is scoped by the class loader which loads that class (a class is identified in JVM by its fully qualiflied name and the class loader loading the class. This is not exactly a scope, but thinking as scope usually helps understanding this better).

So if a class is loaded by two different class loaders, this class exists twice within the VM, it has two sets of static fields, can have different byte code (like different method implementations) and all such. Note that these two objects cannot be cast to each other even their names are identical. "Normal" Java applications have all classes loaded by a class loader hierarchy and every class is only loaded once.

For more complex scenarios, you will need different behaviours. Sometimes you want to isolate a library from messing with your code (like plugins in eclipse or web applications in an application server).

The basic idea to isolate your program from other classes is to load those with an extra class loader and use a lot of reflection. If you want to read up on this have a look at Oracle's documentation on ClassLoaders or OSGI.

Tomcat (and a lot of other web containers / application servers) load the application with separate ClassLoader hierarchies. This isolates all classes against other (web) applications and thus also makes sure, that singletons, different class versions and all this stuff does not collide.

In normal Java applications when a classloader is asked to load a class it forst delegates the request to it's parent class loader and then loads it if parent class loaders cannot find the requested class.

For web application servers this slightly differs. There are generally different class loader for each web app deployed in a web application server like tomcat. For Tomcat it looks like below -

So for web apps class loading resource happens in following order -

1. Bootstrap classes of your JVM (Core java classes)
2. /WEB-INF/classes of your web application
3. /WEB-INF/lib/*.jar of your web application
4. System class loader classes (Tomcat / Classpath specific classes)
5. Common class loader classes (classes common to all web apps)

But note if web application class loader is configured with delegate="true" then order is changed -

1. Bootstrap classes of your JVM (Core java classes)
2. System class loader classes (Tomcat / Classpath specific classes)
3. Common class loader classes (classes common to all web apps)
4. /WEB-INF/classes of your web application
5. /WEB-INF/lib/*.jar of your web application

For more details you can check Apache Tomcat's Class Loader HOW-TO page.

One thing that always gets left out when talking about singletons, is that a singleton can have only one instance per classloader. A ClassLoader limits class visibility, so the same class can exist under several different classloaders in the same VM. This allows you, among other things, to have different versions of jars loaded at the same time.

This question: Java Class Loaders seems to have some nice links and resources for further studying.

Remember that a class in Java is identified by its fully qualified name and the classloader that loaded it. Tomcat uses separate classloaders for each context (web application) that you deploy, thus keeping them separate. In addition, the system classloader loads the tomcat specific libraries and JVM bootstrap loader load the Java core libraries.