论坛首页 Java企业应用论坛

Tomcat 源代码分析之ClassLoader

浏览 13273 次
精华帖 (0) :: 良好帖 (4) :: 新手帖 (0) :: 隐藏帖 (0)
作者 正文
   发表时间:2012-03-18   最后修改:2012-03-18
leonayx123 写道
少了两个貌似。

一个 sharedClassLoader用来加载app可见的包
一个 serverClassLoader用来加载tomcat服务必须的包
我没看过tomcat的源码,
但我感觉,sharedClassLoader应该是appClassloader的parent
不知道是不是

网上看到的资料,加载servlet的classloader(appclassloader?)。似乎比较特殊,
不是按标准的 先让parent加载,而是自己先加载。
有点模糊,有见解的话,麻烦给我解惑下。


今天才看到,不好意思。
这里注明了,这是tomcat7.0版本的分析,前面你所说的
引用
一个 sharedClassLoader用来加载app可见的包
一个 serverClassLoader用来加载tomcat服务必须的包

都是以前的版本,我文章前面有指出的。
Classloader的加载顺序不是全是双亲委派模式加载的,特别是到应用服务器自己的classloader加载体系。
这里serlvet的加载方式在我上述代码已经注明了,顺序再如下说明:
1.从内存cache里找,目的是快速加载
2.保证java.和javax.加载都是从System classloader加载的,安全性
3.Mbeans加载时,是否采用delegate方式,这个具体查看Mbean的配置
4.本地加载
5.从父加载器里加载。
4和5这样的顺序,是保证web app的类加载器能够覆盖common classloader的一些加载包,使不同的Web Apps各自加载不同版本的class,而不互相影响。

0 请登录后投票
   发表时间:2012-03-21  
天下无贼 写道
其实挺简单的,Web类加载器设计要求:

1. 保证每个Web App应用的隔离;以免发生不同的Web App中存在同名的类,系统运行时会发生不可预测的问题。

2. 保证Web App里面的包优先于common包加载,以满足App之特别要求。

3. 充分利用Java原有的父子加载模型。保证标准java库,和tomcat命令行指定的库可以被加载进来。

这样的要求就决定了tomcat的加载顺序。



第2点好像满足不了
0 请登录后投票
   发表时间:2012-03-21  
redhat 写道
leonayx123 写道
少了两个貌似。

一个 sharedClassLoader用来加载app可见的包
一个 serverClassLoader用来加载tomcat服务必须的包
我没看过tomcat的源码,
但我感觉,sharedClassLoader应该是appClassloader的parent
不知道是不是

网上看到的资料,加载servlet的classloader(appclassloader?)。似乎比较特殊,
不是按标准的 先让parent加载,而是自己先加载。
有点模糊,有见解的话,麻烦给我解惑下。


今天才看到,不好意思。
这里注明了,这是tomcat7.0版本的分析,前面你所说的
引用
一个 sharedClassLoader用来加载app可见的包
一个 serverClassLoader用来加载tomcat服务必须的包

都是以前的版本,我文章前面有指出的。
Classloader的加载顺序不是全是双亲委派模式加载的,特别是到应用服务器自己的classloader加载体系。
这里serlvet的加载方式在我上述代码已经注明了,顺序再如下说明:
1.从内存cache里找,目的是快速加载
2.保证java.和javax.加载都是从System classloader加载的,安全性
3.Mbeans加载时,是否采用delegate方式,这个具体查看Mbean的配置
4.本地加载
5.从父加载器里加载。
4和5这样的顺序,是保证web app的类加载器能够覆盖common classloader的一些加载包,使不同的Web Apps各自加载不同版本的class,而不互相影响。



恩 学习了,不好意思,我也是那天上班大概瞄了一眼帖子,没注意到是tomcat7的。 我的认知水平还停在5.呵呵,瞎嚷了。感谢分享
0 请登录后投票
   发表时间:2012-03-24   最后修改:2012-03-24
richard_2010 写道
天下无贼 写道
其实挺简单的,Web类加载器设计要求:

1. 保证每个Web App应用的隔离;以免发生不同的Web App中存在同名的类,系统运行时会发生不可预测的问题。

2. 保证Web App里面的包优先于common包加载,以满足App之特别要求。

3. 充分利用Java原有的父子加载模型。保证标准java库,和tomcat命令行指定的库可以被加载进来。

这样的要求就决定了tomcat的加载顺序。



第2点好像满足不了


第二点实现上当然没问题,但是不应该这么做。 不然也不会给你delegate这个参数了。

譬如一个tomcat下布N个App,每个App都用到了想通的第三方库,假如这个库比较庞大的话,可以考虑放在common的lib下。不然每个app有独立的loader, permGen会很浪费。
0 请登录后投票
   发表时间:2012-03-25  
chenchao051 写道
richard_2010 写道
天下无贼 写道
其实挺简单的,Web类加载器设计要求:

1. 保证每个Web App应用的隔离;以免发生不同的Web App中存在同名的类,系统运行时会发生不可预测的问题。

2. 保证Web App里面的包优先于common包加载,以满足App之特别要求。

3. 充分利用Java原有的父子加载模型。保证标准java库,和tomcat命令行指定的库可以被加载进来。

这样的要求就决定了tomcat的加载顺序。



第2点好像满足不了


第二点实现上当然没问题,但是不应该这么做。 不然也不会给你delegate这个参数了。

delegate参数不是作此用途。
chenchao051 写道

譬如一个tomcat下布N个App,每个App都用到了想通的第三方库,假如这个库比较庞大的话,可以考虑放在common的lib下。不然每个app有独立的loader, permGen会很浪费。

可以考虑在common lib下放置需要的jar包,并在自己的app下覆盖掉,这个特性非常有用,比如为不用prje使用不同版本的lib。
0 请登录后投票
论坛首页 Java企业应用版

跳转论坛:
Global site tag (gtag.js) - Google Analytics