用 jreloader 动态重新加载改变的类而不用重启 JVM

在 Tomcat 中可以配置 reloadable="true" 做到类改变后,Tomcat 重新加载。其实这个过程大约也是当 Tomcat 发现有改变的类会重新启动一个新的应用程序重新加载所有的类来服务于新的请求,只是不需要你手动的去执行 shutdown.sh(.bat),再 startup.sh(.bat)。这种方式对于古老的 jsp 程序完全能从容以对,因为 web.xml 里几乎没什么随应用一起启动且耗时长代码;但当下是框架横行,web.xml 中随应用一起启动的程度可谓是争先恐后的,所以仅仅依赖 reloadable="true" 是满足不了需求的。每改一个类(无论是改动了方法体中的代码还是变动了类的结构,准确的说是动了 WEB-INF/classes 目录中的任何文件) 你都可能就会在

Jan 28, 2011 7:19:42 PM org.apache.catalina.core.ApplicationContext log
INFO: Initializing Spring root WebApplicationContext 阅读全文 >>

类别: Java/JEE, JVM. 标签: , , , . 阅读(2,301). 评论(5) »

Java 的方法签名与字段类型表示-[Ljava.lang.String;

我们什么时候会接触到 Java 的方法签名呢?在进行 JNI 调用时,还有在看方法重载时。重载的方法是有不同的方法签名的,而是不区分返回值,而实际方法签名还揉入了返回值类型的,还有就是 javap -s 查看方法签名时,如 javap -s java.util.Date。

看来方法签名与我们实际工作的关系还真的不大。倒是有次遇着了,事出于 Struts2 应用中提交表单时报出了下面的错误:

00:43:59.716 [http-8080-4] WARN  com.opensymphony.xwork2.ognl.OgnlValueStack - Error setting expression 'version' with value '[Ljava.lang.String;@e18a9a'
ognl.MethodFailedException: Method "setVersion" failed for object cc.unmi.model.Post@ed0cd7
 at ognl.OgnlRuntime.callAppropriateMethod(OgnlRuntime.java:1285) ~[ognl-3.0.jar:na]
 at ognl.OgnlRuntime.setMethodValue(OgnlRuntime.java:1474) ~[ognl-3.0.jar:na]
 at ognl.ObjectPropertyAccessor.setPossibleProperty(ObjectPropertyAccessor.java:85 阅读全文 >>

类别: JVM. 标签: , . 阅读(6,268). 评论(0) »

java class文件格式解析(摘)

1.目的

大型软件系统开发时,某些Java组件可能涉及到多种数据库或中间件系统的连接和应用,例如一个数据传递组件需要从DB2中读取数据,并将数据通过中间件WebSphere MQ发送到其他系统,这类组件功能单一,但却需要连接多种第三方产品,使得程序员的单元测试变的非常不便,程序员不得不注视或修改部分源代码,或者在本地安装所需第三方产品。无疑这两种选择都是痛苦的。

基于以上的不便,本文开发了解析Java Class文件程序,目的是将第三方产品API的Class文件转换为Java源文件(不包括Java类的方法实现),在源文件的各种程序所需的方法里实现一些简单的语句,例如数据库连接方法永远返回true,获得数据方法永远返回 ”Hello world” 等,用JDK重新编译转换后的Java源文件,来替换真正的API 文件,这样程序员在UT测试时,无需修改源代码,也无需安装任何产品,并且能通过修改替换的API Java源文件实施各种UT测试。 阅读全文 >>

类别: JVM. 标签: . 阅读(108). 评论(0) »

四、深入下package,import:(摘)

注:因package,import涉及较多内容,另开一个帖子了,但为了保证此贴内容与标题相符,在此也把写上了该部分内容(措辞有整理)
 
深入下package,import:

    凡是和java设计相关的工具,都会用到package与import,到底这两个东东是做什么的,如何用,它们的内部机理又是如何呢,今仅就个人的理解谈谈看法,里面一些错漏,疑点也请朋友们指出:

一, package,import引入原因:

package:
    我们都熟悉超市,超市虽然庞大,东西繁多,但管理的井井有条,很容易找到某样东东,;之所以能如此,一个很重要的原因就是采用了分类放置,这样既方便了管理,又方便了寻找
    Package也是一个分类放置东东的区域,不过它放的不是商品而是java中的类。Java中有各种各样的类,
内容丰富,繁多,为了更好的管理,识别,就为每一类型的类建立一个区域,这个区域就是包 阅读全文 >>

类别: JVM. 标签: , . 阅读(162). 评论(0) »

三、我对java中类路径的理解(摘)

Java中的类路径分“编译后的存放路径” 和 “运行时的查找路径”,下面分别谈谈

1. java编译后的类存放路径,

分两种:“源文件被直接编译”和“源文件被间接编译”
        1-1源文件直接编译
          什么是源文件直接编译:即通过javac直接编译源文件
建立d:\my目录,在其目录下新建一个文件,如下:

Public class HelloWorld{
    Public static void main(String[] args){
        System.out.println(“HelloWorld”);
    }
}

在命令行输入: javac HelloWorld.java

这时在d:\my这个目录下就产生了一个类文件HelloWorld.class 阅读全文 >>

类别: JVM. 标签: , , . 阅读(224). 评论(3) »

二、我对java中类装载的理解(摘)

1.Java中的所有类,必须被装载到jvm中才能运行,这个装载工作是由jvm中的类装载器完成的,
类装载器所做的工作实质是把类文件从硬盘读取到内存中

2.java中的类大致分为三种:
    1.系统类
    2.扩展类
    3.由程序员自定义的类

3.类装载方式,有两种
    1.隐式装载, 程序在运行过程中当碰到通过new 等方式生成对象时,隐式调用类装载器加载对应的类到jvm中,
    2.显式装载, 通过class.forname()等方法,显式加载需要的类
  隐式加载与显式加载的区别:
    两者本质是一样?, 阅读全文 >>

类别: JVM. 标签: , , . 阅读(171). 评论(0) »

一、我对java中编码的理解(摘)

1. 编码的产生
    对电脑而言,只认识0,1; 而现实世界是由各种符合组成,要想让计算机解释现实世界,就必须建立一套现实世界中的符号 和 计算机能处理的符号之间的对应关系,这个对应关系就是编码

2. 在一个编辑器中,当我们在键盘上敲入一个字符时,在该编辑器上就会显示对应的字符,这个过程用计算机执行步骤来解释大致如下:
    输入字符 –> 编辑器根据设定的编码格式把字符编成01格式 -> 编辑器再按编码规则对01解码–> 显示字符

3.几种常见的编码格式
1. ASCII码: 
    计算机中最早的一套编码格式,采用7位二进制表示一个常见的字符,我们知道,计算机是按照字节来处理数据的,一个字节8位,因此用一个字节就可以表示一个ASCII字符,且还有一个位空位,规定最高位不用,常见的把最高位设定为0。 7位二进制最多可以表示128个字符(2的7次方),ASCII码只能表示常见的英文字符,数字,和少量的符号(没办法,谁让计算机是人家老美先发明的啊,优先考虑本土语言,理解理解)
注: 由于ASCII最早定义,使用广泛,使得之后出现的新的”字符“(不是汉字喔)编码都尽量和它兼容 阅读全文 >>

类别: JVM. 标签: , , . 阅读(127). 评论(3) »

JVM 对 Java 异常的处理原理(try.catch 子句)

最初我们用 Java 写 JSP 的时候,几乎可以不触及异常,因为 Servlet 容器会把 API 抛出的异常包装成 ServletException 丢给容器去处理。再后来应用分层,代码中要处理的异常便多了,一般会转换成自定义的业务异常类,用 try-catch-throw customerException-finally。再到如今各种框架日臻成熟,代码中显式的异常处理又渐渐少了些,借助于 AOP 横行,异常对业务的影响描述被移入到了配置文件中了,例如,事物处理、权限的控制等。

这颇有些像手机的发展,当通信技术不甚发达的时候,手里抓的是砖头,信号是模拟的。后来慢慢瘦身成两三根手指大小,甚至是就一支笔似的,可如今信息量大了,屏幕要大,再配上 QWERT 键盘,机身自然就肥硕了。

当然与手机的个头变迁略有不同的是,任凭你怎么对待 Java 中异常,切入 AOP 也好,在 JVM 中处理异常的内在机制始终未变。 阅读全文 >>

类别: JVM. 标签: , , . 阅读(721). 评论(3) »

有关于 JVM 的垃圾收集(三)

对象可触及时的生命周期

在 JVM 1.2 之前,堆中的对象分为三种状态,分别是:

1. 可触及的 -- 从根节点开始可追踪到
2. 可复活的 -- 从根节点开始追踪不到,但有可能被终结方法触及并复活。不仅仅是那些声明了 finalize() 方法的对象,而是所有的对象都要经过可复活状态
3. 不可触及的 -- 以上两种可能性都不存在,可以真正回收它们所占据的内存了

版本 1.2 中,可触及按强弱进一步细分为:

1. 强可触及 -- 即原来的可触及,从根节点开始的任何直接引用,如一个局部变量或任何从强可触及对象的实例引用的对象
2. 软可触及 -- 表现为 SoftReference 所引用的对象
3. 弱可触及 -- 表现为 WeakReference 所引用的对象
4. 影子可触及 -- 表现为 PhantomReference 所引用的对象 阅读全文 >>

类别: JVM. 标签: , , . 阅读(116). 评论(4) »

有关于 JVM 的垃圾收集(二)

自适应收集器

在第一篇:有关于 JVM 的垃圾收集(一)  中谈到过几种垃圾收集的算法,然而我们的 JVM 启动之后并不要求彻头彻尾的死板的使用一种垃圾收集算法,固定的算法参数。因为某种情况下某些垃圾收集算法工作得更好,而别外一些收集算法在另外的情况下工作得更好,所以自适应的垃圾收集技术应运而生。自适应算法监视堆中的情形,并且对应的调整为合适的垃圾收集技术。或能是换一种垃圾收集算法,或者是调整当前算法参数,或者把堆划分为子堆,同时在不同的子堆中使用不同的算法。

简述火车算法

垃圾收集一般都会停止整个程序的运行来查找和收集垃圾对象,它们可能在程序执行的任意时刻暂停,并且暂停的时间也无法确定。垃圾收集也可能使得程序对事件响应迟钝,无法满足实时系统的要求。如果一种垃圾收集算法可能导致用户可察觉的到的停顿或者使得程序无法适合实时系统的要求,这种算法被称作破坏性。垃圾收集算法的还有一个基本目标是使本质上的破坏性尽可能少,如果可能的话,尽可能消除这种破坏性。 阅读全文 >>

类别: JVM. 标签: , , . 阅读(97). 评论(0) »
Page 1 of 212