- 浏览: 80923 次
- 性别:
- 来自: 北京
不重启Tomcat有两种方式:热部署、热加载
热部署:容器状况在运行时重新部署整个项目。这类环境下一般整个内存会清空,重新加载,这类方式
有可能会造成sessin丢失等环境。tomcat 6确实可以热部署了,而且对话也没丢.
热加载:最好是在调试过程中使用,免患上整个项目加载,Debug标准样式支持热加载。容器状况在运行时重
新加载转变编译后的类。在这类环境下内存不会清空,sessin不会丢失,但容易造成内存溢出,或者找不到方
法。一般转变类的布局和模型就会有异常,在已经有的变量和方法中转变是不会出问题的(Eclipse、
MyEclipse8、JBuilder、IntelliJ IDEA…)。
常用的一定第二种:热加载了,设置如下!
简单例子演示如何进行类的热加载(Hot Deployment)
2008-10-22 — Unmi
应用服务器一般都支持热部署(Hot Deployment),更新代码时把新编译的确类替换旧的就行,后面的程序就执行新类中的代码。这也是由各种应用服务器的独有的类加载器层次实现的。那如何在我们的程序中也实现这种热加载功能呢?即要在虚拟机不关闭的情况下(比如一个),换个类,JVM 就知道加载这个新类,执行新类中的逻辑呢?下面就简单演示这样一个热加载的例子,首先大致了解一下类加载器。
标准 Java 启动器的类加载器层次
1. 引导类加载器(bootstrap): 加载内核 API,如 rt.jar(java.lang、java.io 等)
2. 扩展类加载器(extension): 加载的默认扩展来自于 jre/lib/ext
3. 系统类加载器(system): 类路径上的类,如 com.unmi.*
说明:这只是标准 Java 启动器运行程序时的类加载器层次,像应用服务器中的类加载器通常会多一两层,也是在这个基础上的延伸。上面的类加载层次存在自上而下的委托关系,委托加载不在这里细讲。
类加载器的规则有三
1. 一致性规则:类加载器不能多次加载同一个类
2. 委托规则 :在加载一个类之前,类加载器总参考父类加载器
3. 可见性规则:类只能看到由其类加载器的委托加载的其他类,委托是类的加载器及其所有父类加载器的递归集。(这个规则可能不太好理解,要举个例子就很容易理解的,这里也不细说)
实际的例子演示热加载
1. 建立工程,编写代码
前面铺垫的应该够厚了,开始用个例子来说明感受类的热加载(又名热部署 Hot Deployment)。这个例子采用 Eclipse 来做,首先要建立两个普通的 Java 工程,分别是 TestHotDeployInf 和 TestHotDeployImpl。让 TestHotDeployImpl 依赖于 TestHotDeployInf 工程,即在 TestHotDeployImpl 的 Build Path 中,Projects 标签页里把 TestHotDeployInf 工程选进来,因为编译 TestHotDeployImpl 中的类要用到 TestHotDeployInf 中的类。
然后在工程式 TestHotDeployInf 中新建一个接口(Cat.java) 和一个类(Client.java),内容分别是:
Cat.java(Cat 接口类,也可以用抽象类,用来引用需热加载的实现类的实例)
1
2
3
4
5
6
7
8
9
package com.unmi;
/**
* Cat 接口,要热加载的类一定要有一个接口或基类引用
* @author Unmi
*/
public interface Cat {
public void miaow();
}
Client.java(测试热加载的客户端类)
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
package com.unmi;
import java.io.BufferedReader;
import java.io.InputStreamReader;
import java.net.URL;
import java.net.URLClassLoader;
/**
* 测试热部署 Hot Deployment 的客户端类
* @author Unmi
*/
public class Client {
private static ClassLoader cl;
private static Class catClass;
/**
* @param args
*/
public static void main(String[] args) throws Exception{
BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
Cat cat = createCat();
System.out.println("miaow, reload, or exit");
while(true){
String cmd = br.readLine();
if(cmd.equalsIgnoreCase("exit")){
return;
} else if(cmd.equalsIgnoreCase("reload")){
reloadImpl();
cat = createCat();
System.out.println("CatImpl reloaded.");
} else if(cmd.equalsIgnoreCase("miaow")){
cat.miaow();
}
}
}
/**
* 使用加载的类 Cat 类创建 Cat 实例
* @return Cat 实例
* @throws Exception
*/
public static synchronized Cat createCat() throws Exception{
if(catClass==null){
reloadImpl();
}
Cat newCat = (Cat)catClass.newInstance();
return newCat;
}
/**
* 用自定义的类加载器重新加载 ../TestHotDeployImpl/bin 目录中的 CatImpl 实现类
* 注意这里的 ../TestHotDeployImpl/bin,方便直接读取 TestHotDeployImpl 下随时
* 修改后编译成的新的 com.unmi.CatImpl 类,避免了 class 文件编译后拷贝到别处
* @throws Exception
*/
public static synchronized void reloadImpl() throws Exception{
URL[] externalURLs = new URL[]{new URL("file:../TestHotDeployImpl/bin/")};
cl = new URLClassLoader(externalURLs);
catClass = cl.loadClass("com.unmi.CatImpl");
}
}
还要在 TestHotDeployImpl 中添加一个 Cat 的实现类 CatImpl
01
02
03
04
05
06
07
08
09
10
11
12
13
14
package com.unmi;
/**
* Cat 的实现类,观察是否加载了最新代码,可通过改变 miaow() 方法的输出
* @author Unmi
*/
public class CatImpl implements Cat {
@Override
public void miaow() {
System.out.println("I'm Hello Kity, I like play with you.");
//System.out.println("I'm Tom, Jerry always kids me.");
}
}
2. 进行测试
运行 TestHotDeployInf 中的 Client 程序,按照下图中的指令说明,可观察到热加载的过程:
3. 几个问题
1) 为什么要在单独的工程里放置 CatImpl 类(重要)
主要是为了编译成的 CatImpl 类对于 TestHotDeployInf 的系统加载类不可见,就是不能放在 TestHotDeployInf 的程序的 classpath 中。
这个问题可以说大,本应该提高一个层次来说明它。前面提过标准 Java 启动器加载器层次中有三个加载器,而在上面的 Client.java 中,我们看到用了一个自定义的 cl = new URLClassLoader(externalURLs) 类加载器来加载 com.unmi.CatImpl。也就是标准的类加载器又多了一层,这里估且把它叫做应用程序加载器(AppClassloader)。
根据委托规则,执行 Client 时,要加载 com.unmi.CatImpl 时会首先委托加载 Client 类本身的系统加载器加载。如果编译出的 CatImpl.class 放在 Cat.class 相同的位置,那么就由系统加载器来加载 com.unmi.CatImpl,自定义加载器 cl 是没机会了。所以必须放在外面让系统加载器看不到 com.unmi.CatImpl 类。
再依据一致性规则,如果系统加载器能加载了 com.unmi.CatImpl 类,以后你怎么修改 CatImpl 类,替换掉原来的类,内存中总是最先加载的那个 com.unmi.CatImpl 类版本。因为类只会加载一次。而用自定义的 cl 可不一样了,每次执行 cl.loadClass("com.unmi.CatImpl") 时都是用的一个新的 ClassLoader 实例,所以不受一致性规则的约束,每次都会加载最新版本的 CatImpl 类。
2) 关于类的卸载的问题
上一条讲了加载 com.unmi.CatImpl 时,每次都 new 了一个新了 ClassLoader 实例,每次都加载最新的 CatImpl 类,那就引出了不再使用的 ClassLoader 实例和早先旧版本的 CatImpl 类实例的回收问题。在多数 JVM 中,它们如同普通的 Java 对象一样的处理,当它们无从触及时被当作垃圾被收集掉。也可能在某些 JVM 中这种情况对 ClassLoader 和旧版本 Class 实例的回收要特殊关照一下。
这里的 Class 实例,就是对象调用 getClass() 得到的实例,如 CatImpl.getClass()。类实例和类加载器是相关联的,所有会出现这样的问题,相同类的静态变量可能表现为不同的值,因为它们可能是由不同的类加载器加载的。
对于 ClassLoader 确未细细深入,其实要展开的话内容也不多,关键就知道两点(还是回到了前面的两点,等于什么都没说哦):
1)了解你的程序的类加载器层次,应该看看常见应用服务器(如 Tomcat) 的类加载器层次
2) 理解类加载器的三个规则,着重理解委托机制
知道了类加载器层次,你就可以进行一些定制。如可以把一些包丢到 jre/lib/ext 中就能使用到;给 java 用参数 -Xbootclasspath 指定别的类或包就能替换掉 Java 核心 API 了。
对于可见性规则可以举两个例子:
1) 对于标准的类加载器层次,放在 jre/lib/ext 中的类(由扩展类加载器加载)可以让放在 classpath 下的类(由系统类加载器加载) 访问到,反过来就不行了。
2) 应用服务器中不同的 Web 应用中类不能相互访问,因为它们是由不同的类加载器加载的,且是在并行结构中。而在企业应用程序中的 WAR 包使用到 EJB 包和其他工具包,因为加载 WAR 包的类加载层是在加载 EJB 包和其他工具包的类加载器的下层。
热部署:容器状况在运行时重新部署整个项目。这类环境下一般整个内存会清空,重新加载,这类方式
有可能会造成sessin丢失等环境。tomcat 6确实可以热部署了,而且对话也没丢.
热加载:最好是在调试过程中使用,免患上整个项目加载,Debug标准样式支持热加载。容器状况在运行时重
新加载转变编译后的类。在这类环境下内存不会清空,sessin不会丢失,但容易造成内存溢出,或者找不到方
法。一般转变类的布局和模型就会有异常,在已经有的变量和方法中转变是不会出问题的(Eclipse、
MyEclipse8、JBuilder、IntelliJ IDEA…)。
常用的一定第二种:热加载了,设置如下!
简单例子演示如何进行类的热加载(Hot Deployment)
2008-10-22 — Unmi
应用服务器一般都支持热部署(Hot Deployment),更新代码时把新编译的确类替换旧的就行,后面的程序就执行新类中的代码。这也是由各种应用服务器的独有的类加载器层次实现的。那如何在我们的程序中也实现这种热加载功能呢?即要在虚拟机不关闭的情况下(比如一个),换个类,JVM 就知道加载这个新类,执行新类中的逻辑呢?下面就简单演示这样一个热加载的例子,首先大致了解一下类加载器。
标准 Java 启动器的类加载器层次
1. 引导类加载器(bootstrap): 加载内核 API,如 rt.jar(java.lang、java.io 等)
2. 扩展类加载器(extension): 加载的默认扩展来自于 jre/lib/ext
3. 系统类加载器(system): 类路径上的类,如 com.unmi.*
说明:这只是标准 Java 启动器运行程序时的类加载器层次,像应用服务器中的类加载器通常会多一两层,也是在这个基础上的延伸。上面的类加载层次存在自上而下的委托关系,委托加载不在这里细讲。
类加载器的规则有三
1. 一致性规则:类加载器不能多次加载同一个类
2. 委托规则 :在加载一个类之前,类加载器总参考父类加载器
3. 可见性规则:类只能看到由其类加载器的委托加载的其他类,委托是类的加载器及其所有父类加载器的递归集。(这个规则可能不太好理解,要举个例子就很容易理解的,这里也不细说)
实际的例子演示热加载
1. 建立工程,编写代码
前面铺垫的应该够厚了,开始用个例子来说明感受类的热加载(又名热部署 Hot Deployment)。这个例子采用 Eclipse 来做,首先要建立两个普通的 Java 工程,分别是 TestHotDeployInf 和 TestHotDeployImpl。让 TestHotDeployImpl 依赖于 TestHotDeployInf 工程,即在 TestHotDeployImpl 的 Build Path 中,Projects 标签页里把 TestHotDeployInf 工程选进来,因为编译 TestHotDeployImpl 中的类要用到 TestHotDeployInf 中的类。
然后在工程式 TestHotDeployInf 中新建一个接口(Cat.java) 和一个类(Client.java),内容分别是:
Cat.java(Cat 接口类,也可以用抽象类,用来引用需热加载的实现类的实例)
1
2
3
4
5
6
7
8
9
package com.unmi;
/**
* Cat 接口,要热加载的类一定要有一个接口或基类引用
* @author Unmi
*/
public interface Cat {
public void miaow();
}
Client.java(测试热加载的客户端类)
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
package com.unmi;
import java.io.BufferedReader;
import java.io.InputStreamReader;
import java.net.URL;
import java.net.URLClassLoader;
/**
* 测试热部署 Hot Deployment 的客户端类
* @author Unmi
*/
public class Client {
private static ClassLoader cl;
private static Class catClass;
/**
* @param args
*/
public static void main(String[] args) throws Exception{
BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
Cat cat = createCat();
System.out.println("miaow, reload, or exit");
while(true){
String cmd = br.readLine();
if(cmd.equalsIgnoreCase("exit")){
return;
} else if(cmd.equalsIgnoreCase("reload")){
reloadImpl();
cat = createCat();
System.out.println("CatImpl reloaded.");
} else if(cmd.equalsIgnoreCase("miaow")){
cat.miaow();
}
}
}
/**
* 使用加载的类 Cat 类创建 Cat 实例
* @return Cat 实例
* @throws Exception
*/
public static synchronized Cat createCat() throws Exception{
if(catClass==null){
reloadImpl();
}
Cat newCat = (Cat)catClass.newInstance();
return newCat;
}
/**
* 用自定义的类加载器重新加载 ../TestHotDeployImpl/bin 目录中的 CatImpl 实现类
* 注意这里的 ../TestHotDeployImpl/bin,方便直接读取 TestHotDeployImpl 下随时
* 修改后编译成的新的 com.unmi.CatImpl 类,避免了 class 文件编译后拷贝到别处
* @throws Exception
*/
public static synchronized void reloadImpl() throws Exception{
URL[] externalURLs = new URL[]{new URL("file:../TestHotDeployImpl/bin/")};
cl = new URLClassLoader(externalURLs);
catClass = cl.loadClass("com.unmi.CatImpl");
}
}
还要在 TestHotDeployImpl 中添加一个 Cat 的实现类 CatImpl
01
02
03
04
05
06
07
08
09
10
11
12
13
14
package com.unmi;
/**
* Cat 的实现类,观察是否加载了最新代码,可通过改变 miaow() 方法的输出
* @author Unmi
*/
public class CatImpl implements Cat {
@Override
public void miaow() {
System.out.println("I'm Hello Kity, I like play with you.");
//System.out.println("I'm Tom, Jerry always kids me.");
}
}
2. 进行测试
运行 TestHotDeployInf 中的 Client 程序,按照下图中的指令说明,可观察到热加载的过程:
3. 几个问题
1) 为什么要在单独的工程里放置 CatImpl 类(重要)
主要是为了编译成的 CatImpl 类对于 TestHotDeployInf 的系统加载类不可见,就是不能放在 TestHotDeployInf 的程序的 classpath 中。
这个问题可以说大,本应该提高一个层次来说明它。前面提过标准 Java 启动器加载器层次中有三个加载器,而在上面的 Client.java 中,我们看到用了一个自定义的 cl = new URLClassLoader(externalURLs) 类加载器来加载 com.unmi.CatImpl。也就是标准的类加载器又多了一层,这里估且把它叫做应用程序加载器(AppClassloader)。
根据委托规则,执行 Client 时,要加载 com.unmi.CatImpl 时会首先委托加载 Client 类本身的系统加载器加载。如果编译出的 CatImpl.class 放在 Cat.class 相同的位置,那么就由系统加载器来加载 com.unmi.CatImpl,自定义加载器 cl 是没机会了。所以必须放在外面让系统加载器看不到 com.unmi.CatImpl 类。
再依据一致性规则,如果系统加载器能加载了 com.unmi.CatImpl 类,以后你怎么修改 CatImpl 类,替换掉原来的类,内存中总是最先加载的那个 com.unmi.CatImpl 类版本。因为类只会加载一次。而用自定义的 cl 可不一样了,每次执行 cl.loadClass("com.unmi.CatImpl") 时都是用的一个新的 ClassLoader 实例,所以不受一致性规则的约束,每次都会加载最新版本的 CatImpl 类。
2) 关于类的卸载的问题
上一条讲了加载 com.unmi.CatImpl 时,每次都 new 了一个新了 ClassLoader 实例,每次都加载最新的 CatImpl 类,那就引出了不再使用的 ClassLoader 实例和早先旧版本的 CatImpl 类实例的回收问题。在多数 JVM 中,它们如同普通的 Java 对象一样的处理,当它们无从触及时被当作垃圾被收集掉。也可能在某些 JVM 中这种情况对 ClassLoader 和旧版本 Class 实例的回收要特殊关照一下。
这里的 Class 实例,就是对象调用 getClass() 得到的实例,如 CatImpl.getClass()。类实例和类加载器是相关联的,所有会出现这样的问题,相同类的静态变量可能表现为不同的值,因为它们可能是由不同的类加载器加载的。
对于 ClassLoader 确未细细深入,其实要展开的话内容也不多,关键就知道两点(还是回到了前面的两点,等于什么都没说哦):
1)了解你的程序的类加载器层次,应该看看常见应用服务器(如 Tomcat) 的类加载器层次
2) 理解类加载器的三个规则,着重理解委托机制
知道了类加载器层次,你就可以进行一些定制。如可以把一些包丢到 jre/lib/ext 中就能使用到;给 java 用参数 -Xbootclasspath 指定别的类或包就能替换掉 Java 核心 API 了。
对于可见性规则可以举两个例子:
1) 对于标准的类加载器层次,放在 jre/lib/ext 中的类(由扩展类加载器加载)可以让放在 classpath 下的类(由系统类加载器加载) 访问到,反过来就不行了。
2) 应用服务器中不同的 Web 应用中类不能相互访问,因为它们是由不同的类加载器加载的,且是在并行结构中。而在企业应用程序中的 WAR 包使用到 EJB 包和其他工具包,因为加载 WAR 包的类加载层是在加载 EJB 包和其他工具包的类加载器的下层。
发表评论
-
组合or继承
2013-05-27 11:54 822到底使用组合还是继承是每本讲设计的资料里都要讨论一番的话题 ... -
Java访问控制private之我见
2013-05-24 11:36 783最近待业在家,遂有空重新读了thinking in Java这 ... -
XML 系列教程
2012-05-06 12:50 585http://www.w3school.com.cn/x.as ... -
面向接口编程详解
2012-04-19 21:42 1107面向接口编程详解 2009-04-23 作者:张洋 来源: ... -
浅析java回调机制与观察者模式
2012-04-10 17:23 17891 java回调机制: 首先解 ... -
Java程序设计之-复合优先于继承
2012-04-03 10:33 1443组合 通过创建一个由其他对象组合的对象来获得新功能的重用方法 ... -
java学习之路(转)
2012-03-30 15:01 761(一) 从事软件 ... -
java内部类
2012-03-28 16:26 854一、 定义 放在一个类的内部的类我们就叫内部类。 二、 作用 ... -
为什么匿名内部类只能访问其所在方法中的final变量(转)
2012-03-28 15:45 1030(1).所谓“局部内部类”就是在对象的方法成员内部定义的类。而 ... -
Java访问权限修饰符(转)
2012-03-28 11:20 10611、Class类的访问权限: ... -
【java】好书推荐
2012-03-26 15:31 1439Java软件架构师所要需的东西 作为Java程序员来说,最痛 ... -
Java绝对好文,转载的!(转载)
2012-03-25 14:45 790想来学习Java也有两个年头了,永远不敢说多么精通,但也想谈谈 ... -
理解java动态加载机制
2012-03-20 00:01 10071.java动态性 java是一种 ... -
Registry of Singleton 模式(转)
2012-03-06 10:01 764考虑使用 Singleton 模式 时拥有子类别的问题,在Si ... -
单例模式(Singleton Pattern)
2012-03-05 20:40 6806.单例模式(Singleton Pattern) 前面说提到 ... -
java.util.concurrent 多线程框架
2012-02-26 16:15 758http://daoger.iteye.com/blog/14 ... -
线程----BlockingQueue (转),java
2012-02-26 13:50 792/** 本例介绍一个 ... -
关于多个线程同时调用单例模式的对象,该对象中方法的局部变量是否会受多个线程的影响
2012-02-12 12:16 2905对于那些会以多线程运行的单例类,例如Web应用中的Servle ... -
Java线程同步机制synchronized关键字的理解
2011-12-25 14:34 734由于同一进程的多个线 ... -
synchronized与static synchronized 的区别
2011-12-24 22:48 6491.synchronized与static synchroni ...
相关推荐
使用一个spring MVC样例来说明jreloader的tomcat热部署
java热部署
主要介绍了详解tomcat热部署和热加载的方法的相关资料,这里提供两种tomcat热部署和热加载的方法,需要的朋友可以参考下
在STS中如何对springBoot项目进行热部署的步骤
IntelliJ IDEA修改了mybatis mapper xml后自动热发布 热更新 热部署.zip Mybatis xml文件使用热加载检测不更新怎么办?看我的
在 Java 开发领域,热部署一直是一个难以解决的问题,目前的 Java 虚拟机只能实现方法体的修改热部署,对于整个类的结构修改,仍然需要重启虚拟机,对类重新加载才能完成更新操作。对于某些大型的应用来说,每次的...
J2EE 热部署 J2EE 热部署
主要介绍了Java基于自定义类加载器实现热部署过程解析,文中通过示例代码介绍的非常详细,对大家的学习或者工作具有一定的参考学习价值,需要的朋友可以参考下
eclipse工程格式 博文链接:https://aga.iteye.com/blog/200818
jrebel热部署,修改前端代码,Java代码,xml配文件,properties文件不用重新部署项目和重启服务器。真的好用,本人已验证使用。 jrebel热部署,修改前端代码,Java代码,xml配文件,properties文件不用重新部署项目...
热加载 支持在不使用devtools/jrebel的情况下, 热加载 mybatis的mapper文件 内置全局、局部拦截插件:提供delete、update 自定义拦截功能 拥有预防Sql注入攻击功能 无缝支持spring cloud: 后续提供分布式调用的例子
讲述了springboot的热部署以及集成dao层的框架。(Hibernate、SpringDataJPA等)
Eclipse 工程代码 博文链接:https://flyfoxs.iteye.com/blog/2080502
无需重启服务器,无需重新部署,为我们web编程节省大量时间
这是热部署的突破口,由于React Native加载的js文件都打包在bundle中,通过这个方法,可以设置app加载的bundle来源。若检测到远端存在更新的bundle文件,下载好后重新加载即可。 为了在运行中重新加载bundle文件,...
在 Java 开发领域,热部署一直是一个难以解决的问题,目前的 Java 虚拟机只能实现方法体的修改热部署,对于整个类的结构修改,仍然需要重启虚拟机,对类重新加载才能完成更新操作。对于某些大型的应用来说,每次...
下面小编就为大家分享一篇关于Webpack dev server热加载失败的解决方法,具有很好的参考价值,希望对大家有所帮助。一起跟随小编过来看看吧