Java 虚拟机分析工具用 JDK 自带的jconsole,jvisualvm, 和jmc(Java Mission Control) 就已经非常好了,还真极少情况下(甚至没有)非得用商业的 Profiler 工具如 YourKit Java Profiler 或 JProfiler 的情况。用于实时观察 JVM 的内存, CPU, 线程等运行状况,对比 Heap 快照,发现线程死锁的应用情景,我比较喜欢用jvisualvm(VisualVM)。
有很长一段时间,因为在家办公司,只要连接到公司的 VPN 后再执行jvisualvm来打开 VisualVM 时,会有很长的时间(可能长达 10 几分钟)卡在窗口右下角状态栏的Computing description...,要等到它消失后才能开始连接 JVM,这时候我的 Java 应用可能早就退出了。要是本地不连 VPN 的话就正常,启动 VisualVM 是正常的,但调试有些工作项目又必须连接公司的 VPN。
这种使用 VisualVM 的体验有如恶梦一般,还是有经常要用到 VisualVM 的需求,所以再也不能忍受这种无谓的等待。依然是 Google + StackOverflow 的模式,找到原来罪魁祸首是 /etc/hosts中的127.0.0.1这个条目。 Read More- 在 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 Read More - 我们什么时候会接触到 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 Read More Java 程序员还是应该对 Java ClassLoader 有所了解,曾经问过一个做 Java 的 JVM 是什么?结果是:没听过。 汗颜了吧,但也不少写 JSP 的甚至是 Java 代码的真的可能不了解 ClassLoader,所以对 Classpath 仍然费解。 JRE 本身就有一个 ClassLoader 层次,更别说在各种应用服务器中因为 ClassLoader 层次的因素产生了莫名其妙的问题。 例如,数据库驱动有时候应该放在哪个目录中,怎么应用却加载了一个旧版的 Jar 包等等。
本篇的 Understand Java ClassLoader.chm 文件是我根据 IBM 开发者网站上的 https://www6.software.ibm.com/developerworks/cn/education/java/j-classloader/tutorial 整理而成的。以前是用 Visual CHM 工具来制作 CHM 文件,而这个呢是用 FAR 生成的,感觉 FAR 的功能要强大些。 Read More
- 注:因package,import涉及较多内容,另开一个帖子了,但为了保证此贴内容与标题相符,在此也把写上了该部分内容(措辞有整理)
深入下package,import:
凡是和java设计相关的工具,都会用到package与import,到底这两个东东是做什么的,如何用,它们的内部机理又是如何呢,今仅就个人的理解谈谈看法,里面一些错漏,疑点也请朋友们指出:
一, package,import引入原因:
package:
我们都熟悉超市,超市虽然庞大,东西繁多,但管理的井井有条,很容易找到某样东东,;之所以能如此,一个很重要的原因就是采用了分类放置,这样既方便了管理,又方便了寻找
Package也是一个分类放置东东的区域,不过它放的不是商品而是java中的类。Java中有各种各样的类,
内容丰富,繁多,为了更好的管理,识别,就为每一类型的类建立一个区域,这个区域就是包 Read More - 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 Read More - 1.Java中的所有类,必须被装载到jvm中才能运行,这个装载工作是由jvm中的类装载器完成的,
类装载器所做的工作实质是把类文件从硬盘读取到内存中
2.java中的类大致分为三种:
1.系统类
2.扩展类
3.由程序员自定义的类
3.类装载方式,有两种
1.隐式装载, 程序在运行过程中当碰到通过new 等方式生成对象时,隐式调用类装载器加载对应的类到jvm中,
2.显式装载, 通过class.forname()等方法,显式加载需要的类
隐式加载与显式加载的区别:
两者本质是一样?, Read More - 1. 编码的产生
对电脑而言,只认识0,1; 而现实世界是由各种符合组成,要想让计算机解释现实世界,就必须建立一套现实世界中的符号 和 计算机能处理的符号之间的对应关系,这个对应关系就是编码
2. 在一个编辑器中,当我们在键盘上敲入一个字符时,在该编辑器上就会显示对应的字符,这个过程用计算机执行步骤来解释大致如下:
输入字符 –> 编辑器根据设定的编码格式把字符编成01格式 -> 编辑器再按编码规则对01解码–> 显示字符
3.几种常见的编码格式
1. ASCII码:
计算机中最早的一套编码格式,采用7位二进制表示一个常见的字符,我们知道,计算机是按照字节来处理数据的,一个字节8位,因此用一个字节就可以表示一个ASCII字符,且还有一个位空位,规定最高位不用,常见的把最高位设定为0。 7位二进制最多可以表示128个字符(2的7次方),ASCII码只能表示常见的英文字符,数字,和少量的符号(没办法,谁让计算机是人家老美先发明的啊,优先考虑本土语言,理解理解)
注: 由于ASCII最早定义,使用广泛,使得之后出现的新的”字符“(不是汉字喔)编码都尽量和它兼容 Read More - 最初我们用 Java 写 JSP 的时候,几乎可以不触及异常,因为 Servlet 容器会把 API 抛出的异常包装成 ServletException 丢给容器去处理。再后来应用分层,代码中要处理的异常便多了,一般会转换成自定义的业务异常类,用 try-catch-throw customerException-finally。再到如今各种框架日臻成熟,代码中显式的异常处理又渐渐少了些,借助于 AOP 横行,异常对业务的影响描述被移入到了配置文件中了,例如,事物处理、权限的控制等。
这颇有些像手机的发展,当通信技术不甚发达的时候,手里抓的是砖头,信号是模拟的。后来慢慢瘦身成两三根手指大小,甚至是就一支笔似的,可如今信息量大了,屏幕要大,再配上 QWERT 键盘,机身自然就肥硕了。
当然与手机的个头变迁略有不同的是,任凭你怎么对待 Java 中异常,切入 AOP 也好,在 JVM 中处理异常的内在机制始终未变。 Read More - 对象可触及时的生命周期
在 JVM 1.2 之前,堆中的对象分为三种状态,分别是:
1. 可触及的 -- 从根节点开始可追踪到
2. 可复活的 -- 从根节点开始追踪不到,但有可能被终结方法触及并复活。不仅仅是那些声明了 finalize() 方法的对象,而是所有的对象都要经过可复活状态
3. 不可触及的 -- 以上两种可能性都不存在,可以真正回收它们所占据的内存了
版本 1.2 中,可触及按强弱进一步细分为:
1. 强可触及 -- 即原来的可触及,从根节点开始的任何直接引用,如一个局部变量或任何从强可触及对象的实例引用的对象
2. 软可触及 -- 表现为 SoftReference 所引用的对象
3. 弱可触及 -- 表现为 WeakReference 所引用的对象
4. 影子可触及 -- 表现为 PhantomReference 所引用的对象 Read More