在Class文件格式与执行引擎部分，用户的程序能直接影响的内容并不多，Class文件的格式，类加载时机，如何连接，以及具体的字节码指令执行都由虚拟机控制，用户程序无法控制。能进行控制的，主要是字节码的生成和类加载器部分
主流的Java Web容器 如Tomcat Weblogic WebSphere都实现了自定义的类加载器，而一个功能健全的Web服务器，都要解决主要的以下几个问题
——部署在同一服务器上的2个web应用程序所使用的Java类库可以实现相互隔离，这是最基本的要求，2个不同的应用程序可能会同时依赖同一个第三方类库的不同版本，不能一个类库在一个服务器上只有一份，服务器保证2个应用程序的类库可以相互独立的使用
——部署在同一服务器上的2个Web应用程序所使用的Java类库可以共享。这个需求也很常见。如：用户可能有10个使用Spring组织的应用程序部署在同一台服务器上，如果把10份Spring分别存放在各个应用程序的隔离目录中，将会造成巨大的资源浪费（主要不是磁盘资源的浪费，主要是需要加载到内存，会使虚拟机运行数据区的方法区空间不足
——服务器需要尽可能地保证自身的安全不受Web应用程序的影响，即保证自身的安全性，因为许多主流的Java Web服务器本身也是由Java语言实现，也需要依赖相应的类库，因此服务器使用的类库应该与应用程序的类库相互独立
——支持JSP应用的Web服务器，大多数需要支持HotSwap功能。因为JSP文件最终都要编译成Java Class文件才能被虚拟机执行，但由于JSP是存文本文件，不同于Class文件运行期很容易被修改，即Web服务器需要实现JSP文件的热替换特性
由于存在以上要求，在部署Web应用时候，单独的一个ClassPath无法满足要求，所以各种Web服务器提供多个ClassPath路径用于存放用户第三方类库，这些路径一般以 lib classes 命名。被放置到不同路径中的类库，具备不同的访问范围和服务对象。通常，每一个目录都会有一个相应的自定义类加载器去加载对应目录下的Java类库。
——以Tomcat容器为例
在tomcat目录结构中，有3组目录 /common/* /server/* /shared/* 可以存放Java类库，另外加上Web应用程序自身的目录是/WEB_INF/* 一共是4种
- 放置在/common目录中：类库可以被Tomcat和所有Web应用程序共同使用
- 放置在/server目录中：类库可以被Tomcat自身所使用，对Web应用程序不可见
- 放置在/shared目录中：类库可以被所有应用程序可见，但对Tomcat自身不可见
- 放置在/WebApp/WEB_INF目录中：该类库只能仅仅被该应用程序使用
为了实现这些目录的隔离和加载。Tomcat包含多个不同功能的类加载器，按照经典的双亲委派机制进行加载
上层的三个是系统提供的3个基本类加载器
而下面几个类加载器则是Tomcat提供的，用于根据双亲委派原则分层次加载对应的类