JVM入门研究以及实践.docxVIP

我们看中的并非Java语言，而是JVM。——Java之父James Gosling接受著名IT网站eWEEK高级编辑的采访时如是说Java之所以能够崛起，JVM功不可没。Java虚拟机最初服务于让Java语言凌驾于平台之上，实现“一次编写，到处运行”；而随着时间的推移，JVM经过不同公司和团体以不同方式的实现（如IBM的J9、 BEA公司的JRockit，本文档主要介绍SUN官方的虚拟机HotSpot），逐渐有更多Java以外的语言登上了JVM这条船，如Groovy、JRuby、Scala、Jython等，而且本人经常会去中关村图书大厦“溜达”，发现被人们一致看好的Scala相关的书越来越多，也许Scala真的会有不错的明天。这里不对以上编程语言加以置评，旨在于对JVM的介绍。初识JVM体系结构Java虚拟机之所以被称之为是“虚拟的”，就是因为它仅仅是由一个规范来定义的抽象计算机，因此要运行某个Java程序，必须需要一个符合该规范的具体实现。我们经常听说Java虚拟机，其实这只是侠义上的理解。JVM可能指的是以下三种不同的概念：虚拟机规范一个具体实现一个运行中的虚拟机实例如图是Sun HotSpot的虚拟机实现的体系结构，它分为类装载子系统、运行时数据区、执行引擎以及本地方法接口，接下来一一介绍。类装载子系统装载器把一个类装入JVM中要要经过三个步骤来完成装载：查找和装入类或接口的二进制数据。连接：执行以下三步，其中解析是可选的验证：检验装入类或接口的二进制数据的正确性。准备：为静态变量分配存储空间。解析：将常量池内的符号引用替换为直接引用。初始化：激活类的静态变量和静态Java代码块。JVM内置了三个默认的装载器：BootstrapLoaderBootstrapLoader是由C/C++实现，我们无法在程序中获取它的实例，这个装载器负责装载lib目录下的dt.jar、tools.jar等Java核心核心类库。ExtClassLoader这个装载器负责装载jdk/lib/ext目录下的jar包。AppClassLoader这个装载器主要负责装载classpath目录下的类。这三个装载器存在层级关系：ExtClassloader为AppClassLoader的父装载器，BootstrapLoader为ExtClassLoader的父装载器。类的装载遵循“双亲委派”模式，如果AppClassLoader被请求装载一个类，它首先会去询问ExtClassLoader是否已经装载，如果已经装载，则返回其对象；如果尚未装载，会继续询问BootstrapLoader，也就是说BootstrapLoader拥有最高的优先级。为了进一步探索JVM的classloader机制，写了如下两个Demo：e.g 1/*****@authorJoher**/publicclass ClassLoaderTest {/***@paramargs*/publicstaticvoid main(String[] args) {ClassLoader loader = Thread.currentThread().getContextClassLoader();System.out.println(loader);System.out.println(loader.getParent());System.out.println(loader.getParent().getParent());}}结果输出：示例说明我们无法直接获取BootstrapLoader实例。e.g 2package java.lang;/****@authorJoher**/publicclass String {publicstaticvoid main(String[] args) {int a = 1;int b = 2;System.out.println(a + b); }}这个小程序会输出什么？答案是这个小程序根本不能运行！运行其会出现如图：提示说：发生了致命异常，程序将退出。WHY? 如果你够敏感，肯定会注意到次类名比较特殊，这是因为次类名与JVM核心类库的java.lang.String类发生了冲突，JVM会认为此同名的类是“恶意”的，所以导致程序直接退出。好吧，为了能使其运行，把类名改成StringTest，这个肯定没有重复的，再次运行会是什么结果？运行抛出一个安全异常，如图：为寻其因，于是溯源而上，根据错误信息定位到java.lang.ClassLoader类，发现如下代码：：/* Determine protection domain, and check that: - not define java.* class,- signer of th