解析Java类和对象的初始化过程_J2EE_Java开发_软件开发-编程-IT资源网
来源：互联网 发布：js代码的执行方法 编辑：程序博客网 时间：2024/06/04 17:53
类的初始化和对象初始化是 JVM 管理的类型生命周期中非常重要的两个环节，Google 了一遍网络，有关类装载机制的文章倒是不少，然而类初始化和对象初始化的文章并不多，特别是从字节码和 JVM 层次来分析的文章更是鲜有所见。
本文主要对类和对象初始化全过程进行分析，通过一个实际问题引入，将源代码转换成 JVM 字节码后，对 JVM 执行过程的关键点进行全面解析，并在文中穿插入了相关 JVM 规范和 JVM 的部分内部理论知识，以理论与实际结合的方式介绍对象初始化和类初始化之间的协作以及可能存在的冲突问题。
问题引入
近日我在调试一个枚举类型的解析器程序，该解析器是将内一万多条枚举代码装载到缓存中，为了实现快速定位枚举代码和具体枚举类别的所有枚举元素，该类在装载枚举代码的同时对其采取两种策略建立内存索引。由于该类是一个公共服务类，在程序各个层面都会使用到它，因此我将它实现为一个单例类。这个类在我调整类实例化语句位置之前运行正常，但当我把该类实例化语句调整到静态初始化语句之前时，我的程序不再为我工作了。 下面是经过我简化后的示例代码：
［清单一］
package com.ccb..enums;
import .util.Collections;
import java.util.HashMap;
import java.util.Map;
public class CachingEnumResolver {
//单态实例 一切问题皆由此行引起
private static final CachingEnumResolver SINGLE_ENUM_RESOLVER = new CachingEnumResolver();
/*MSGCODE->Category内存索引*/
private static Map CODE_MAP_CACHE;
static {
CODE_MAP_CACHE = new HashMap();
//为了说明问题,我在这里初始化一条数据
CODE_MAP_CACHE.put("0","北京市");
}
//private, for single instance
private CachingEnumResolver() {
//初始化加载数据 引起问题，该方法也要负点责任
initEnums();
}
/** * 初始化所有的枚举类型 */
public static void initEnums() {
// ~~~~~~~~~问题从这里开始暴露 ~~~~~~~~~~~//
if (null == CODE_MAP_CACHE) {
System.out.println("CODE_MAP_CACHE为空,问题在这里开始暴露.");
CODE_MAP_CACHE = new HashMap();
}
CODE_MAP_CACHE.put("1", "北京市");
CODE_MAP_CACHE.put("2", "云南省");
//..... other code...
}
public Map getCache() {
return Collections.unmodifiableMap(CODE_MAP_CACHE);
}
/** * 获取单态实例 * * @return */
public static CachingEnumResolver getInstance() {
return SINGLE_ENUM_RESOLVER;
}
public static void main(String[] args) {
System.out.println(CachingEnumResolver.getInstance().getCache());
}
}
想必大家看了上面的代码后会感觉有些茫然，这个类看起来没有问题啊，这的确属于典型的饿汉式单态模式啊，怎么会有问题呢？
是的，他看起来的确没有问题，可是如果将他 run 起来时，其结果是他不会为你正确 work。运行该类，它的执行结果是：
［清单二］
CODE_MAP_CACHE为空,问题在这里开始暴露.{0=北京市}
我的程序怎么会这样？为什么在 initEnum() 方法里 CODE_MAP_CACHE 为空？为什么我输出的 CODE_MAP_CACHE 内容只有一个元素，其它两个元素呢？？？？！！
看到这里，如果是你在调试该程序，你此刻一定觉得很奇怪，难道是我的 Jvm 有问题吗？非也！如果不是，那我的程序是怎么了？这绝对不是我想要的结果。可事实上无论怎么修改 initEnum() 方法都无济于事，起码我最初是一定不会怀疑到问题可能出在创建 CachingEnumResolver 实例这一环节上。正是因为我太相信我创建 CachingEnumResolver 实例的方法，加之对 Java 类初始化与对象实例化底层原理理解有所偏差，使我为此付出了三、四个小时--约半个工作日的大好青春。
那么问题究竟出在哪里呢？为什么会出现这样的怪事呢？在解决这个问题之前，先让我们来了解一下JVM的类和对象初始化的底层机制。
类的生命周期
上图展示的是类生命周期流向；在本文里，我只打算谈谈类的"初始化"以及"对象实例化"两个阶段。
类初始化
类"初始化"阶段，它是一个类或接口被首次使用的前阶段中的最后一项工作，本阶段负责为类变量赋予正确的初始值。
Java 编译器把所有的类变量初始化语句和类型的静态初始化器通通收集到 方法内，该方法只能被 Jvm 调用，专门承担初始化工作。
除接口以外，初始化一个类之前必须保证其直接超类已被初始化，并且该初始化过程是由 Jvm 保证安全的。另外，并非所有的类都会拥有一个() 方法，在以下条件中该类不会拥有 () 方法：
该类既没有声明任何类变量，也没有静态初始化语句；该类声明了类变量，但没有明确使用类变量初始化语句或静态初始化语句初始化；该类仅包含静态 final 变量的类变量初始化语句，并且类变量初始化语句是编译时常量表达式。
对应于三个层次的框架比较
1、表现层框架比较
M不再是某一种表现层框架的特点而是这几种框架的共性。框架由于出现时间早，所以使用相对广泛，它的社区非常活跃，很容易找到很多现成的开源功能标签以供使用以及样例程序可供参考。但是它的组件在页面中显示的粗粒度，以及框架类的限制在很多情况下会表现得过于死板，给表示层的开发会带来一些额外的代码开销。JSF在很大程度上类似Struts，只是JSF的组件概念没有象Struts那样必须继承ActionForm的限制，JSF在事件粒度上要比Struts细腻。JSF有的另外一个优势就是其身后有Sun公司和其他的一些大公司的支持。Tapestry是一个完全组件的框架，Tapestry的组件可以被套嵌并包裹其它组件，因此可以组合形成一个更大的组件或逻辑页面。组件的行为模式为页面编程提供了很大的方便，事件处理也方便很多。所以，如果做一个对页面要求灵活度相当高的系统就可以考虑选用Tapestry。
表1 三种框架的表现层功能技术细节比较
框架
Struts
Tapestry3.0
JSF
View组件实现模式
标签库+组件，组件必须继承ActionForm
完全组件，分显式调用和隐式调用，组件必须继承BaseComponent
标签库+组件，普通POJO无需继承
组件在View显示粒度
View页面只能显示与表单对应的ActionForm，配置中Action与 ActionForm与 页面一般只能1:1:1关系。
可将组件嵌入页面任何一行，对使用组件数量无限制。
同Tapestry
页面跳转
使用标签库html:link中写明目标URL，URL名称需要对照struts_config.配置文件中的path命名，与组件Action耦合。
URL名称是目标的组件名称，不涉及URL和路径等操作，方便稳固。
类似Struts，也需要在配置文件中查找，与组件分离。
事件触发
通过表单提交submit激活，不能细化到表单里字段。
能够给于表单每个字段赋一个事件，事件组件必须实现PageListener接口
同Tapestry，事件组件必须实现ActionListener
2、业务组件层框架比较
2.1框架有些过于复杂了，有如下缺点：① EJB模型需要建立许多组件接口和实现许多不必要的回滚方法；②EJB的部署描述复杂而容易出错；③开发人员不能脱离EJB容器测试。对于以上缺点JCP ( Community Process)制订的EJB3.0标准框架做了相应的改进，该框架为所有主要的厂商支持。EJB3.0和Spring两个框架结构都有一个共同核心设计理念：将中间件服务传递给耦合松散的POJOs。
EJB3.0框架与高度整合，服务整合代码也包装在一个标准接口后面。EJB框架一方面有成熟的EJB容器支持，基于EJB框架的企业应用性能优良；另一方面EJB容器设计因为考虑了多方面的功能，所以在其内核上总是会显得臃肿，这也是一种重量表现。不需要的东西存在肯定会影响效率，EJB不能根据项目需求对EJB整体包括EJB容器进行可配置式的切割。
Spring框架处于应用和服务库的上方，服务整合的代码属于框架，并暴露于应用开发者。它与应用服务器整合的能力相对EJB3.0要弱。但是Spring框架模块的可分离配置体现了它优于EJB3.0的灵活性。
表2 EJB和Spring框架的具体细节比较
框架
EJB2/EJB3
Spring 1.x
灵活性(松耦合)
EJB3比EJB2更具灵活性，EJB3支持应用系统POJO
支持应用系统POJO，框架本身可分离配置
功能完整性
全面，支持异步JMS 分布式事务
较为全面。有自己的表现层和持久层模板，可支持异步
领域范围
支持业务逻辑Session
不支持，需要开发者额外基于ThreadLocal编制代码
IoC/AOP支持
EJB3支持IoC， JBoss等EJB3服务器支持AOP；基于业务组件的较粗粒度
基于JavaBeans类的细粒度支持AOP
单台性能
一般，批量查询等大数据量业务处理须小心，存在本地不透明缺陷。
一般，应用程序可配置cache/Pool以提高性能
可伸缩性
可支持多台服务器分布式计算。
不支持，可依靠EJB实现
开发效率
学习曲线长，导致熟练掌握难。借助商业开发工具可加快熟练者的开发速度。
可挑选只适合自己的功能实现。相对EJB稍简单。
系统规模
EJB2适合大型系统;EJB3适合中大型系统
适合中小型系统，可借助EJB支持中大型系统
3、持久层框架比较
容器管理持久性（CMP）是对EJB中Entity Bean进行持久性管理的方式。EJB2.1 持久性模型过于复杂并且存在缺陷[3]。EJB3.0持久层针对EJB2.1的缺陷做了相应改进，采用与类似的机制。
Hibernate相对而言其基本优势如下：①Hibernate 使用 Java 反射机制而不是字节码增强程序来实现透明性；②Hibernate的使用简单；③映射的灵活性很出色，它支持各种关系，从一对一到多对多的各种复杂关系。Hibernate 也有一些缺点，它限制所使用的对象模型 (例如，一个持久性类不能映射到多个表)。
使用iBATIS提供的O/R Mapping机制，对业务逻辑实现人员而言，面对的是纯粹的Java对象，这一层与通过Hibernate 实现O/R Mapping 而言基本一致，而对于具体的数据操作，Hibernate 会自动生成SQL 语句，而iBATIS则要求开发者编写具体的SQL 语句。相对Hibernate等 “全自动”O/R Mapping机制而言，iBATIS以SQL开发的工作量和数据库移植性上的让步，为系统设计提供了更大的自由空间。作为“全自动”ORM 实现的一种有益补充，iBATIS的出现显得别具意义。
企业应用系统框架选择
设计和性能是实际框架选择的两个基本点，善于平衡才是框架选择的主要宗旨。轻量级框架和重量级框架解决问题的侧重点是不同的。
轻量级框架侧重于减小开发的复杂度，相应的它的处理能力便有所减弱（如事务功能弱、不具备分布式处理能力），比较适用于开发中小型企业应用。采用轻量框架一方面因为尽可能的采用基于POJOs的方法进行开发，使应用不依赖于任何容器，这可以提高开发调试效率；另一方面轻量级框架多数是开源项目，开源社区提供了良好的设计和许多快速构建工具以及大量现成可供参考的开源代码，这有利于项目的快速开发。例如目前Tomcat+Spring+Hibernate已经成为许多开发者开发J2EE中小型企业应用偏爱的一种架构选择。随着可供选择的框架层出不穷，开发者可以根据需要对应于企业应用三个层次的轻量级框架选择，本文第2节的内容可供选择参考。
而作为重量级框架EJB框架则强调高可伸缩性，适合与开发大型企业应用。在EJB体系结构中，一切与基础结构服务相关的问题和底层分配问题都由应用程序容器或服务器来处理，且EJB容器通过减少数据库访问次数以及分布式处理等方式提供了专门的系统性能，能够充分解决系统性能问题。
轻量级框架的产生并非是对重量级框架的否定，甚至在某种程度上可以说二者是互补的。轻量级框架在努力发展以开发具有更强大，功能更完备的企业应用；而新的EJB规范EJB3.0则在努力简化J2EE的使用以使得EJB不仅仅是擅长处理大型企业系统，也利用开发中小型系统，这也是EJB轻量化的一种努力。对于大型企业应用以及将来可能涉及到能力扩展的中小型应用采用结合使用轻量级框架和重量级框架也不失为一种较好的解决方案。
总结
目前适用Java企业应用的系统框架可谓百花齐放，各种框架都有长短，选择应用系统框架时不可盲目的追求流行，首先需要明确所要实现的应用系统的系统处理能力需求，然后在熟悉比较各种框架细节的基础上从设计以及开发效率方面进行考虑。本文旨在为系统框架选择提供一个参考，限于篇幅本文只对其中的几种框架做了比较，开发者可以根据需要对更多其他框架细节进行比较。
鉴别泄漏对象的方法
一般说来，一个正常的系统在其运行稳定后其内存的占用量是基本稳定的，不应该是无限制的增长的，同样，对任何一个类的对象的使用个数也有一个相对稳定的上限，不应该是持续增长的。根据这样的基本假设，我们可以持续地观察系统运行时使用的内存的大小和各实例的个数，如果内存的大小持续地增长，则说明系统存在内存泄漏，如果某个类的实例的个数持续地增长，则说明这个类的实例可能存在泄漏情况。
Optimizeit是Borland公司的产品，主要用于协助对软件系统进行代码优化和故障诊断，其功能众多，使用方便，其中的OptimizeIt Profiler主要用于内存泄漏的分析。Profiler的堆视图(如图4)就是用来观察系统运行使用的内存大小和各个类的实例分配的个数的，其界面如图四所示，各列自左至右分别为类名称、当前实例个数、自上个标记点开始增长的实例个数、占用的内存空间的大小、自上次标记点开始增长的内存的大小、被释放的实例的个数信息、自上次标记点开始增长的内存的大小被释放的实例的个数信息，表的最后一行是汇总数据，分别表示目前JVM中的对象实例总数、实例增长总数、内存使用总数、内存使用增长总数等。
在实践中，可以分别在系统运行四个小时、八个小时、十二个小时和二十四个小时时间点记录当时的内存状态(即抓取当时的内存快照，是工具提供的功能，这个快照也是供下一步分析使用)，找出实例个数增长的前十位的类，记录下这十个类的名称和当前实例的个数。在记录完数据后，点击Profiler中右上角的Mark按钮，将该点的状态作为下一次记录数据时的比较点。
图4 Profiler 堆视图
系统运行二十四小时以后可以得到四个内存快照。对这四个内存快照进行综合分析，如果每一次快照的内存使用都比上一次有增长，可以认定系统存在内存泄漏，找出在四个快照中实例个数都保持增长的类，这些类可以初步被认定为存在泄漏。
分析与定位
通过上面的数据收集和初步分析，可以得出初步结论:系统是否存在内存泄漏和哪些对象存在泄漏(被泄漏)，如果结论是存在泄漏，就可以进入分析和定位阶段了。
前面已经谈到中的内存泄漏就是无意识的对象保持，简单地讲就是因为编码的错误导致了一条本来不应该存在的引用链的存在(从而导致了被引用的对象无法释放)，因此内存泄漏分析的任务就是找出这条多余的引用链，并找到其形成的原因。前面还讲到过牵引对象，包括已经加载的类的静态变量和处于活动的堆栈空间的变量。由于活动线程的堆栈空间是迅速变化的，处于堆栈空间内的牵引对象集合是迅速变化的，而作为类的静态变量的牵引对象的集合在系统运行期间是相对稳定的。
对每个被泄漏的实例对象，必然存在一条从某个牵引对象出发到达该对象的引用链。处于堆栈空间的牵引对象在被从栈中弹出后就失去其牵引的能力，变为非牵引对象，因此，在长时间的运行后，被泄露的对象基本上都是被作为类的静态变量的牵引对象牵引。
Profiler的内存视图除了堆视图以外，还包括实例分配视图(图5)和实例引用图(图6)。
Profiler的实例引用图为找出从牵引对象到泄漏对象的引用链提供了非常直接的方法，其界面的第二个栏目中显示的就是从泄漏对象出发的逆向引用链。需要注意的是，当一个类的实例存在泄漏时，并非其所有的实例都是被泄漏的，往往只有一部分是被泄漏对象，其它则是正常使用的对象，要判断哪些是正常的引用链，哪些是不正常的引用链(引起泄漏的引用链)。通过抽取多个实例进行引用图的分析统计以后，可以找出一条或者多条从牵引对象出发的引用链，下面的任务就是找出这条引用链形成的原因。
实例分配图提供的功能是对每个类的实例的分配位置进行统计，查看实例分配的统计结果对于分析引用链的形成具有一定的作用，因为找到分配链与引用链的交点往往就可以找到了引用链形成的原因，下面将具体介绍。
图5 实例分配图
图6 实例引用图
设想一个实例对象a在方法f中被分配，最终被实例对象b所引用，下面来分析从b到a的引用链可能的形成原因。方法f在创建对象a后，对它的使用分为四种情况:1、将a作为返回值返回;2、将a作为参数调用其它方法;3、在方法内部将a的引用传递给其它对象;4、其它情况。其中情况4不会造成由b到a的引用链的生成，不用考虑。下面考虑其它三种情况:对于1、2两种情况，其造成的结果都是在另一个方法内部获得了对象a的引用，它的分析与方法f的分析完全一样(递归分析);考虑第3种情况:1、假设方法f直接将对象a的引用加入到对象b，则对象b到a的引用链就找到了，分析结束;2、假设方法f将对象a的引用加入到对象c，则接下来就需要跟踪对象c的使用，对象c的分析比对象a的分析步骤更多一些，但大体原理都是一样的，就是跟踪对象从创建后被使用的历程，最终找到其被牵引对象引用的原因。
现在将泄漏对象的引用链以及引用链形成的原因找到了，内存泄漏测试与分析的工作就到此结束，接下来的工作就是修改相应的设计或者实现中的错误了。
总结
使用上述的测试和分析方法，在实践中先后进行了三次测试，找出了好几处内存泄漏错误。系统的稳定性得到很大程度的提高，最初运行1~2天就抛出内存溢出异常，修改完成后，系统从未出现过内存溢出异常。此方法适用于任何使用Java语言开发的、对稳定性有比较高要求的软件系统。
对象初始化
在类被装载、连接和初始化，这个类就随时都可能使用了。对象实例化和初始化是就是对象生命的起始阶段的活动，在这里我们主要讨论对象的初始化工作的相关特点。
编译器在编译每个类时都会为该类至少生成一个实例初始化方法--即 "()" 方法。此方法与源代码中的每个构造方法相对应，如果类没有明确地声明任何构造方法，编译器则为该类生成一个默认的无参构造方法，这个默认的构造器仅仅调用父类的无参构造器，与此同时也会生成一个与默认构造方法对应的 "()" 方法.
通常来说，() 方法内包括的代码内容大概为：调用另一个 () 方法；对实例变量初始化；与其对应的构造方法内的代码。 如果构造方法是明确地从调用同一个类中的另一个构造方法开始，那它对应的 () 方法体内包括的内容为：一个对本类的 () 方法的调用；对应用构造方法内的所有字节码。
如果构造方法不是通过调用自身类的其它构造方法开始，并且该对象不是 Object 对象，那() 法内则包括的内容为：一个对父类 () 方法的调用；对实例变量初始化方法的字节码；最后是对应构造子的方法体字节码。
如果这个类是 Object，那么它的() 方法则不包括对父类 () 方法的调用。
类的初始化时机
本文到目前为止，我们已经大概有了解到了类生命周期中都经历了哪些阶段，但这个类的生命周期的开始阶段--类装载又是在什么时候被触发呢？类又是何时被初始化的呢？让我们带着这三个疑问继续去寻找答案。
Java 虚拟机规范为类的初始化时机做了严格定义："initialize on first active use"--" 在首次主动使用时初始化"。这个规则直接影响着类装载、连接和初始化类的机制--因为在类型被初始化之前它必须已经被连接，然而在连接之前又必须保证它已经被装载了。
在与初始化时机相关的类装载时机问题上，Java 虚拟机规范并没有对其做严格的定义，这就使得 JVM 在实现上可以根据自己的特点提供采用不同的装载策略。我们可以思考一下 Jboss AOP 框架的实现原理，它就是在对你的 class 文件装载环节做了手脚--插入了 AOP 的相关拦截字节码，这使得它可以对程序员做到完全透明化，哪怕你用 new 操作符创建出的对象实例也一样能被 AOP 框架拦截--与之相对应的 Spring AOP，你必须通过他的 BeanFactory 获得被 AOP 代理过的受管对象，当然 Jboss AOP 的缺点也很明显--他是和 JBOSS 绑定很紧密的，你不能很轻松的移植到其它服务器上。嗯~……，说到这里有些跑题了，要知道 AOP 实现策略足可以写一本厚厚的书了，嘿嘿，就此打住。
说了这么多，类的初始化时机就是在"在首次主动使用时"，那么，哪些情形下才符合首次主动使用的要求呢？
首次主动使用的情形：
·创建某个类的新实例时--new、反射、克隆或反序列化；
·调用某个类的静态方法时；
·使用某个类或接口的静态字段或对该字段赋值时（final字段除外）；
·调用Java的某些反射方法时
·初始化某个类的子类时
·在虚拟机启动时某个含有main()方法的那个启动类。
除了以上几种情形以外，所有其它使用JAVA类型的方式都是被动使用的，他们不会导致类的初始化。
我的问题究竟出在哪里
好了，了解了JVM的类初始化与对象初始化机制后，我们就有了理论，也就可以理性的去分析问题了。
下面让我们来看看前面[清单一]的JAVA源代码反组译出的字节码：
［清单三］
public class com.ccb..enums.CachingEnumResolver extendsjava.lang.Object{
static {};
Code: 0: new #2;
//class CachingEnumResolver
3: dup
4: invokespecial #14;
//Method "":()V ①
7: putstatic #16;
//Field SINGLE_ENUM_RESOLVER:Lcom/ccb/framework/enums/CachingEnumResolver;
10: new #18;
//class HashMap ②
13: dup
14: invokespecial #19;
//Method java/util/HashMap."":()V
17: putstatic #21;
//Field CODE_MAP_CACHE:Ljava/util/Map;
20: getstatic #21;
//Field CODE_MAP_CACHE:Ljava/util/Map;
23: ldc #23;
//String 0
25: ldc #25;
//String 北京市
27: invokeinterface #31, 3;
//InterfaceMethod java/util/Map.put:(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object; ③
32: pop 33: returnprivate com.ccb.framework.enums.CachingEnumResolver();
Code: 0: aload_0 1: invokespecial #34;
//Method java/lang/Object."":()V 4: invokestatic #37;
//Method initEnums:()V ④ 7: returnpublic static void initEnums();
Code: 0: getstatic #21;
//Field CODE_MAP_CACHE:Ljava/util/Map;
⑤ 3: ifnonnull 24 6: getstatic #44;
//Field java/lang/System.out:Ljava/io/PrintStream;
9: ldc #46;
//String CODE_MAP_CACHE为空,问题在这里开始暴露.
11: invokevirtual #52;
//Method java/io/PrintStream.println:(Ljava/lang/String;)V 14: new #18;
//class HashMap 17: dup 18: invokespecial #19;
//Method java/util/HashMap."":()V ⑥ 21: putstatic #21;
//Field CODE_MAP_CACHE:Ljava/util/Map;
24: getstatic #21;
//Field CODE_MAP_CACHE:Ljava/util/Map;
27: ldc #54;
//String 1 29: ldc #25;
//String 北京市 31: invokeinterface #31, 3;
//InterfaceMethod java/util/Map.put:(Ljava/lang/Object;
Ljava/lang/Object;)Ljava/lang/Object;
⑦ 36: pop 37: getstatic #21;
//Field CODE_MAP_CACHE:Ljava/util/Map;
40: ldc #56;
//String 2 42: ldc #58;
//String 云南省 44: invokeinterface #31, 3;
//InterfaceMethod java/util/Map.put:(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;
⑧ 49: pop 50: returnpublic java.util.Map getCache();
Code: 0: getstatic #21;
//Field CODE_MAP_CACHE:Ljava/util/Map;
3: invokestatic #66;
//Method java/util/Collections.unmodifiableMap:(Ljava/util/Map;)Ljava/util/Map;
6: areturnpublic static com.ccb.framework.enums.CachingEnumResolver getInstance();
Code: 0: getstatic #16;
//Field SINGLE_ENUM_RESOLVER:Lcom/ccb/framework/enums/CachingEnumResolver;
⑨ 3: areturn}
如果上面［清单一］显示，清单内容是在 1.4 环境下的字节码内容，可能这份清单对于很大部分兄弟来说确实没有多少吸引力，因为这些 JVM 指令确实不像源代码那样漂亮易懂。但它的的确确是查找和定位问题最直接的办法，我们想要的答案就在这份 JVM 指令清单里。
现在，让我们对该类从类初始化到对象实例初始化全过程分析[清单一]中的代码执行轨迹。
如前面所述，类初始化是在类真正可用时的最后一项前阶工作，该阶段负责对所有类正确的初始化值，此项工作是安全的，JVM会保证多线程同步。
第1步：调用类初始化方法 CachingEnumResolver.()，该方法对外界是不可见的，换句话说是 JVM 内部专用方法，() 内包括了 CachingEnumResolver 内所有的具有指定初始值的类变量的初始化语句。要注意的是并非每个类都具有该方法，具体的内容在前面已有叙述。
第2步：进入() 方法内，让我们看字节码中的 "①" 行，该行与其上面两行组合起来代表 new 一个 CachingEnumResolver 对象实例，而该代码行本身是指调用 CachingEnumResolver 类的 （）方法。每一个 Java 类都具有一个 () 方法，该方法是 Java 编译器在编译时生成的，对外界不可见，() 方法内包括了所有具有指定初始化值的实例变量初始化语句和java类的构造方法内的所有语句。对象在实例化时，均通过该方法进行初始化。然而到此步，一个潜在的问题已经在此埋伏好，就等着你来犯了。
第3步：让我们顺着执行顺序向下看，"④" 行，该行所在方法就是该类的构造器，该方法先调用父类的构造器() 对父对象进行初始化，然后调用 CachingEnumResolver.initEnum() 方法加载数据。
第4步："⑤" 行，该行获取 "CODE_MAP_CACHE" 字段值，其运行时该字段值为 null。注意，问题已经开始显现了。（作为程序员的你一定是希望该字段已经被初始化过了，而事实上它还没有被初始化）。通过判断，由于该字段为 NULL，因此程序将继续执行到 "⑥" 行，将该字段实例化为 HashMap()。
第5步：在 "⑦"、"⑧" 行，其功能就是为 "CODE_MAP_CACHE" 字段填入两条数据。
第6步：退出对象初始化方法()，将生成的对象实例初始化给类字段 "SINGLE_ENUM_RESOLVER"。（注意，此刻该对象实例内的类变量还未初始化完全，刚才由 () 调用 initEnum() 方法赋值的类变量 "CODE_MAP_CACHE" 是 () 方法还未初始化字段，它还将在后面的类初始化过程再次被覆盖）。
第7步：继续执行（）方法内的后继代码，"②" 行，该行对 "CODE_MAP_CACHE" 字段实例化为 HashMap 实例（注意：在对象实例化时已经对该字段赋值过了，现在又重新赋值为另一个实例，此刻，"CODE_MAP_CACHE"变量所引用的实例的类变量值被覆盖，到此我们的疑问已经有了答案）。
第8步：类初始化完毕，同时该单态类的实例化工作也完成。
通过对上面的字节码执行过程分析，或许你已经清楚了解到导致错误的深层原因了，也或许你可能早已被上面的分析过程给弄得晕头转向了，不过也没折，虽然我也可以从源代码的角度来阐述问题，但这样不够深度，同时也会有仅为个人观点、不足可信之嫌。
如何解决
要解决上面代码所存在的问题很简单，那就是将 "SINGLE_ENUM_RESOLVER" 变量的初始化赋值语句转移到 getInstance() 方法中去即可。换句话说就是要避免在类还未初始化完成时从内部实例化该类或在初始化过程中引用还未初始化的字段。
写在最后
静下浮燥之心，仔细思量自己是否真的掌握了本文主题所引出的知识，如果您觉得您已经完全或基本掌握了，那么很好，在最后，我将前面的代码稍做下修改，请思考下面两组程序是否同样会存在问题呢？
程序一
public class CachingEnumResolver {
public static Map CODE_MAP_CACHE;
static {
CODE_MAP_CACHE = new HashMap();
//为了说明问题,我在这里初始化一条数据
CODE_MAP_CACHE.put("0","北京市");
initEnums();
}
程序二
public class CachingEnumResolver {
private static final CachingEnumResolver SINGLE_ENUM_RESOLVER;
public static Map CODE_MAP_CACHE;
static {
CODE_MAP_CACHE = new HashMap();
//为了说明问题,我在这里初始化一条数据
CODE_MAP_CACHE.put("0","北京市");
SINGLE_ENUM_RESOLVER = new CachingEnumResolver();
initEnums();
}
最后，一点关于 JAVA 群体的感言：时下正是各种开源框架盛行时期，Spring 更是大行其道，吸引着一大批 JEE 开发者的眼球（我也是 fans 中的一员）。然而，让我们仔细观察一下--以 Spring 群体为例，在那么多的 Spring fans 当中，有多少人去研究过 Spring 源代码？又有多少人对 Spring 设计思想有真正深入了解呢？当然，我是没有资格以这样的口吻来说事的，我只是想表明一个观点--学东西一定要"正本清源"。
献上此文，谨以共勉。
本文转自
http://cache.baidu.com/c?m=9f65cb4a8c8507ed4fece763105392230e54f7227c86d31674c3933fc239045c1426a5e0767c4719d3c77e621cad425eeeed6e21735037b0efce8840d6b9852858d2616b2e08c31c528516b8bb3032b620872b9eb86de3adf142cbfd9680c85422dd22076df7f29c5b7003ba1ce76547f4a7e95f655b07cceb27148b4e0328882230a137fef74368108086ca2c4dd45ed77660e4b845c12913c504d46f0c5730b74dc11f212d279439308f452a75e3&p=8c57c54ad48c12a059ecd426174e&user=baidu
本文主要对类和对象初始化全过程进行分析，通过一个实际问题引入，将源代码转换成 JVM 字节码后，对 JVM 执行过程的关键点进行全面解析，并在文中穿插入了相关 JVM 规范和 JVM 的部分内部理论知识，以理论与实际结合的方式介绍对象初始化和类初始化之间的协作以及可能存在的冲突问题。
问题引入
近日我在调试一个枚举类型的解析器程序，该解析器是将内一万多条枚举代码装载到缓存中，为了实现快速定位枚举代码和具体枚举类别的所有枚举元素，该类在装载枚举代码的同时对其采取两种策略建立内存索引。由于该类是一个公共服务类，在程序各个层面都会使用到它，因此我将它实现为一个单例类。这个类在我调整类实例化语句位置之前运行正常，但当我把该类实例化语句调整到静态初始化语句之前时，我的程序不再为我工作了。 下面是经过我简化后的示例代码：
［清单一］
package com.ccb..enums;
import .util.Collections;
import java.util.HashMap;
import java.util.Map;
public class CachingEnumResolver {
//单态实例 一切问题皆由此行引起
private static final CachingEnumResolver SINGLE_ENUM_RESOLVER = new CachingEnumResolver();
/*MSGCODE->Category内存索引*/
private static Map CODE_MAP_CACHE;
static {
CODE_MAP_CACHE = new HashMap();
//为了说明问题,我在这里初始化一条数据
CODE_MAP_CACHE.put("0","北京市");
}
//private, for single instance
private CachingEnumResolver() {
//初始化加载数据 引起问题，该方法也要负点责任
initEnums();
}
/** * 初始化所有的枚举类型 */
public static void initEnums() {
// ~~~~~~~~~问题从这里开始暴露 ~~~~~~~~~~~//
if (null == CODE_MAP_CACHE) {
System.out.println("CODE_MAP_CACHE为空,问题在这里开始暴露.");
CODE_MAP_CACHE = new HashMap();
}
CODE_MAP_CACHE.put("1", "北京市");
CODE_MAP_CACHE.put("2", "云南省");
//..... other code...
}
public Map getCache() {
return Collections.unmodifiableMap(CODE_MAP_CACHE);
}
/** * 获取单态实例 * * @return */
public static CachingEnumResolver getInstance() {
return SINGLE_ENUM_RESOLVER;
}
public static void main(String[] args) {
System.out.println(CachingEnumResolver.getInstance().getCache());
}
}
想必大家看了上面的代码后会感觉有些茫然，这个类看起来没有问题啊，这的确属于典型的饿汉式单态模式啊，怎么会有问题呢？
是的，他看起来的确没有问题，可是如果将他 run 起来时，其结果是他不会为你正确 work。运行该类，它的执行结果是：
［清单二］
CODE_MAP_CACHE为空,问题在这里开始暴露.{0=北京市}
我的程序怎么会这样？为什么在 initEnum() 方法里 CODE_MAP_CACHE 为空？为什么我输出的 CODE_MAP_CACHE 内容只有一个元素，其它两个元素呢？？？？！！
看到这里，如果是你在调试该程序，你此刻一定觉得很奇怪，难道是我的 Jvm 有问题吗？非也！如果不是，那我的程序是怎么了？这绝对不是我想要的结果。可事实上无论怎么修改 initEnum() 方法都无济于事，起码我最初是一定不会怀疑到问题可能出在创建 CachingEnumResolver 实例这一环节上。正是因为我太相信我创建 CachingEnumResolver 实例的方法，加之对 Java 类初始化与对象实例化底层原理理解有所偏差，使我为此付出了三、四个小时--约半个工作日的大好青春。
那么问题究竟出在哪里呢？为什么会出现这样的怪事呢？在解决这个问题之前，先让我们来了解一下JVM的类和对象初始化的底层机制。
类的生命周期
上图展示的是类生命周期流向；在本文里，我只打算谈谈类的"初始化"以及"对象实例化"两个阶段。
类初始化
类"初始化"阶段，它是一个类或接口被首次使用的前阶段中的最后一项工作，本阶段负责为类变量赋予正确的初始值。
Java 编译器把所有的类变量初始化语句和类型的静态初始化器通通收集到
除接口以外，初始化一个类之前必须保证其直接超类已被初始化，并且该初始化过程是由 Jvm 保证安全的。另外，并非所有的类都会拥有一个
该类既没有声明任何类变量，也没有静态初始化语句；该类声明了类变量，但没有明确使用类变量初始化语句或静态初始化语句初始化；该类仅包含静态 final 变量的类变量初始化语句，并且类变量初始化语句是编译时常量表达式。
对应于三个层次的框架比较
1、表现层框架比较
M不再是某一种表现层框架的特点而是这几种框架的共性。框架由于出现时间早，所以使用相对广泛，它的社区非常活跃，很容易找到很多现成的开源功能标签以供使用以及样例程序可供参考。但是它的组件在页面中显示的粗粒度，以及框架类的限制在很多情况下会表现得过于死板，给表示层的开发会带来一些额外的代码开销。JSF在很大程度上类似Struts，只是JSF的组件概念没有象Struts那样必须继承ActionForm的限制，JSF在事件粒度上要比Struts细腻。JSF有的另外一个优势就是其身后有Sun公司和其他的一些大公司的支持。Tapestry是一个完全组件的框架，Tapestry的组件可以被套嵌并包裹其它组件，因此可以组合形成一个更大的组件或逻辑页面。组件的行为模式为页面编程提供了很大的方便，事件处理也方便很多。所以，如果做一个对页面要求灵活度相当高的系统就可以考虑选用Tapestry。
表1 三种框架的表现层功能技术细节比较
框架
Struts
Tapestry3.0
JSF
View组件实现模式
标签库+组件，组件必须继承ActionForm
完全组件，分显式调用和隐式调用，组件必须继承BaseComponent
标签库+组件，普通POJO无需继承
组件在View显示粒度
View页面只能显示与表单对应的ActionForm，配置中Action与 ActionForm与 页面一般只能1:1:1关系。
可将组件嵌入页面任何一行，对使用组件数量无限制。
同Tapestry
页面跳转
使用标签库html:link中写明目标URL，URL名称需要对照struts_config.配置文件中的path命名，与组件Action耦合。
URL名称是目标的组件名称，不涉及URL和路径等操作，方便稳固。
类似Struts，也需要在配置文件中查找，与组件分离。
事件触发
通过表单提交submit激活，不能细化到表单里字段。
能够给于表单每个字段赋一个事件，事件组件必须实现PageListener接口
同Tapestry，事件组件必须实现ActionListener
2、业务组件层框架比较
2.1框架有些过于复杂了，有如下缺点：① EJB模型需要建立许多组件接口和实现许多不必要的回滚方法；②EJB的部署描述复杂而容易出错；③开发人员不能脱离EJB容器测试。对于以上缺点JCP ( Community Process)制订的EJB3.0标准框架做了相应的改进，该框架为所有主要的厂商支持。EJB3.0和Spring两个框架结构都有一个共同核心设计理念：将中间件服务传递给耦合松散的POJOs。
EJB3.0框架与高度整合，服务整合代码也包装在一个标准接口后面。EJB框架一方面有成熟的EJB容器支持，基于EJB框架的企业应用性能优良；另一方面EJB容器设计因为考虑了多方面的功能，所以在其内核上总是会显得臃肿，这也是一种重量表现。不需要的东西存在肯定会影响效率，EJB不能根据项目需求对EJB整体包括EJB容器进行可配置式的切割。
Spring框架处于应用和服务库的上方，服务整合的代码属于框架，并暴露于应用开发者。它与应用服务器整合的能力相对EJB3.0要弱。但是Spring框架模块的可分离配置体现了它优于EJB3.0的灵活性。
表2 EJB和Spring框架的具体细节比较
框架
EJB2/EJB3
Spring 1.x
灵活性(松耦合)
EJB3比EJB2更具灵活性，EJB3支持应用系统POJO
支持应用系统POJO，框架本身可分离配置
功能完整性
全面，支持异步JMS 分布式事务
较为全面。有自己的表现层和持久层模板，可支持异步
领域范围
支持业务逻辑Session
不支持，需要开发者额外基于ThreadLocal编制代码
IoC/AOP支持
EJB3支持IoC， JBoss等EJB3服务器支持AOP；基于业务组件的较粗粒度
基于JavaBeans类的细粒度支持AOP
单台性能
一般，批量查询等大数据量业务处理须小心，存在本地不透明缺陷。
一般，应用程序可配置cache/Pool以提高性能
可伸缩性
可支持多台服务器分布式计算。
不支持，可依靠EJB实现
开发效率
学习曲线长，导致熟练掌握难。借助商业开发工具可加快熟练者的开发速度。
可挑选只适合自己的功能实现。相对EJB稍简单。
系统规模
EJB2适合大型系统;EJB3适合中大型系统
适合中小型系统，可借助EJB支持中大型系统
3、持久层框架比较
容器管理持久性（CMP）是对EJB中Entity Bean进行持久性管理的方式。EJB2.1 持久性模型过于复杂并且存在缺陷[3]。EJB3.0持久层针对EJB2.1的缺陷做了相应改进，采用与类似的机制。
Hibernate相对而言其基本优势如下：①Hibernate 使用 Java 反射机制而不是字节码增强程序来实现透明性；②Hibernate的使用简单；③映射的灵活性很出色，它支持各种关系，从一对一到多对多的各种复杂关系。Hibernate 也有一些缺点，它限制所使用的对象模型 (例如，一个持久性类不能映射到多个表)。
使用iBATIS提供的O/R Mapping机制，对业务逻辑实现人员而言，面对的是纯粹的Java对象，这一层与通过Hibernate 实现O/R Mapping 而言基本一致，而对于具体的数据操作，Hibernate 会自动生成SQL 语句，而iBATIS则要求开发者编写具体的SQL 语句。相对Hibernate等 “全自动”O/R Mapping机制而言，iBATIS以SQL开发的工作量和数据库移植性上的让步，为系统设计提供了更大的自由空间。作为“全自动”ORM 实现的一种有益补充，iBATIS的出现显得别具意义。
企业应用系统框架选择
设计和性能是实际框架选择的两个基本点，善于平衡才是框架选择的主要宗旨。轻量级框架和重量级框架解决问题的侧重点是不同的。
轻量级框架侧重于减小开发的复杂度，相应的它的处理能力便有所减弱（如事务功能弱、不具备分布式处理能力），比较适用于开发中小型企业应用。采用轻量框架一方面因为尽可能的采用基于POJOs的方法进行开发，使应用不依赖于任何容器，这可以提高开发调试效率；另一方面轻量级框架多数是开源项目，开源社区提供了良好的设计和许多快速构建工具以及大量现成可供参考的开源代码，这有利于项目的快速开发。例如目前Tomcat+Spring+Hibernate已经成为许多开发者开发J2EE中小型企业应用偏爱的一种架构选择。随着可供选择的框架层出不穷，开发者可以根据需要对应于企业应用三个层次的轻量级框架选择，本文第2节的内容可供选择参考。
而作为重量级框架EJB框架则强调高可伸缩性，适合与开发大型企业应用。在EJB体系结构中，一切与基础结构服务相关的问题和底层分配问题都由应用程序容器或服务器来处理，且EJB容器通过减少数据库访问次数以及分布式处理等方式提供了专门的系统性能，能够充分解决系统性能问题。
轻量级框架的产生并非是对重量级框架的否定，甚至在某种程度上可以说二者是互补的。轻量级框架在努力发展以开发具有更强大，功能更完备的企业应用；而新的EJB规范EJB3.0则在努力简化J2EE的使用以使得EJB不仅仅是擅长处理大型企业系统，也利用开发中小型系统，这也是EJB轻量化的一种努力。对于大型企业应用以及将来可能涉及到能力扩展的中小型应用采用结合使用轻量级框架和重量级框架也不失为一种较好的解决方案。
总结
目前适用Java企业应用的系统框架可谓百花齐放，各种框架都有长短，选择应用系统框架时不可盲目的追求流行，首先需要明确所要实现的应用系统的系统处理能力需求，然后在熟悉比较各种框架细节的基础上从设计以及开发效率方面进行考虑。本文旨在为系统框架选择提供一个参考，限于篇幅本文只对其中的几种框架做了比较，开发者可以根据需要对更多其他框架细节进行比较。
鉴别泄漏对象的方法
一般说来，一个正常的系统在其运行稳定后其内存的占用量是基本稳定的，不应该是无限制的增长的，同样，对任何一个类的对象的使用个数也有一个相对稳定的上限，不应该是持续增长的。根据这样的基本假设，我们可以持续地观察系统运行时使用的内存的大小和各实例的个数，如果内存的大小持续地增长，则说明系统存在内存泄漏，如果某个类的实例的个数持续地增长，则说明这个类的实例可能存在泄漏情况。
Optimizeit是Borland公司的产品，主要用于协助对软件系统进行代码优化和故障诊断，其功能众多，使用方便，其中的OptimizeIt Profiler主要用于内存泄漏的分析。Profiler的堆视图(如图4)就是用来观察系统运行使用的内存大小和各个类的实例分配的个数的，其界面如图四所示，各列自左至右分别为类名称、当前实例个数、自上个标记点开始增长的实例个数、占用的内存空间的大小、自上次标记点开始增长的内存的大小、被释放的实例的个数信息、自上次标记点开始增长的内存的大小被释放的实例的个数信息，表的最后一行是汇总数据，分别表示目前JVM中的对象实例总数、实例增长总数、内存使用总数、内存使用增长总数等。
在实践中，可以分别在系统运行四个小时、八个小时、十二个小时和二十四个小时时间点记录当时的内存状态(即抓取当时的内存快照，是工具提供的功能，这个快照也是供下一步分析使用)，找出实例个数增长的前十位的类，记录下这十个类的名称和当前实例的个数。在记录完数据后，点击Profiler中右上角的Mark按钮，将该点的状态作为下一次记录数据时的比较点。
图4 Profiler 堆视图
系统运行二十四小时以后可以得到四个内存快照。对这四个内存快照进行综合分析，如果每一次快照的内存使用都比上一次有增长，可以认定系统存在内存泄漏，找出在四个快照中实例个数都保持增长的类，这些类可以初步被认定为存在泄漏。
分析与定位
通过上面的数据收集和初步分析，可以得出初步结论:系统是否存在内存泄漏和哪些对象存在泄漏(被泄漏)，如果结论是存在泄漏，就可以进入分析和定位阶段了。
前面已经谈到中的内存泄漏就是无意识的对象保持，简单地讲就是因为编码的错误导致了一条本来不应该存在的引用链的存在(从而导致了被引用的对象无法释放)，因此内存泄漏分析的任务就是找出这条多余的引用链，并找到其形成的原因。前面还讲到过牵引对象，包括已经加载的类的静态变量和处于活动的堆栈空间的变量。由于活动线程的堆栈空间是迅速变化的，处于堆栈空间内的牵引对象集合是迅速变化的，而作为类的静态变量的牵引对象的集合在系统运行期间是相对稳定的。
对每个被泄漏的实例对象，必然存在一条从某个牵引对象出发到达该对象的引用链。处于堆栈空间的牵引对象在被从栈中弹出后就失去其牵引的能力，变为非牵引对象，因此，在长时间的运行后，被泄露的对象基本上都是被作为类的静态变量的牵引对象牵引。
Profiler的内存视图除了堆视图以外，还包括实例分配视图(图5)和实例引用图(图6)。
Profiler的实例引用图为找出从牵引对象到泄漏对象的引用链提供了非常直接的方法，其界面的第二个栏目中显示的就是从泄漏对象出发的逆向引用链。需要注意的是，当一个类的实例存在泄漏时，并非其所有的实例都是被泄漏的，往往只有一部分是被泄漏对象，其它则是正常使用的对象，要判断哪些是正常的引用链，哪些是不正常的引用链(引起泄漏的引用链)。通过抽取多个实例进行引用图的分析统计以后，可以找出一条或者多条从牵引对象出发的引用链，下面的任务就是找出这条引用链形成的原因。
实例分配图提供的功能是对每个类的实例的分配位置进行统计，查看实例分配的统计结果对于分析引用链的形成具有一定的作用，因为找到分配链与引用链的交点往往就可以找到了引用链形成的原因，下面将具体介绍。
图5 实例分配图
图6 实例引用图
设想一个实例对象a在方法f中被分配，最终被实例对象b所引用，下面来分析从b到a的引用链可能的形成原因。方法f在创建对象a后，对它的使用分为四种情况:1、将a作为返回值返回;2、将a作为参数调用其它方法;3、在方法内部将a的引用传递给其它对象;4、其它情况。其中情况4不会造成由b到a的引用链的生成，不用考虑。下面考虑其它三种情况:对于1、2两种情况，其造成的结果都是在另一个方法内部获得了对象a的引用，它的分析与方法f的分析完全一样(递归分析);考虑第3种情况:1、假设方法f直接将对象a的引用加入到对象b，则对象b到a的引用链就找到了，分析结束;2、假设方法f将对象a的引用加入到对象c，则接下来就需要跟踪对象c的使用，对象c的分析比对象a的分析步骤更多一些，但大体原理都是一样的，就是跟踪对象从创建后被使用的历程，最终找到其被牵引对象引用的原因。
现在将泄漏对象的引用链以及引用链形成的原因找到了，内存泄漏测试与分析的工作就到此结束，接下来的工作就是修改相应的设计或者实现中的错误了。
总结
使用上述的测试和分析方法，在实践中先后进行了三次测试，找出了好几处内存泄漏错误。系统的稳定性得到很大程度的提高，最初运行1~2天就抛出内存溢出异常，修改完成后，系统从未出现过内存溢出异常。此方法适用于任何使用Java语言开发的、对稳定性有比较高要求的软件系统。
对象初始化
在类被装载、连接和初始化，这个类就随时都可能使用了。对象实例化和初始化是就是对象生命的起始阶段的活动，在这里我们主要讨论对象的初始化工作的相关特点。
编译器在编译每个类时都会为该类至少生成一个实例初始化方法--即 "
通常来说，
如果构造方法不是通过调用自身类的其它构造方法开始，并且该对象不是 Object 对象，那
如果这个类是 Object，那么它的
类的初始化时机
本文到目前为止，我们已经大概有了解到了类生命周期中都经历了哪些阶段，但这个类的生命周期的开始阶段--类装载又是在什么时候被触发呢？类又是何时被初始化的呢？让我们带着这三个疑问继续去寻找答案。
Java 虚拟机规范为类的初始化时机做了严格定义："initialize on first active use"--" 在首次主动使用时初始化"。这个规则直接影响着类装载、连接和初始化类的机制--因为在类型被初始化之前它必须已经被连接，然而在连接之前又必须保证它已经被装载了。
在与初始化时机相关的类装载时机问题上，Java 虚拟机规范并没有对其做严格的定义，这就使得 JVM 在实现上可以根据自己的特点提供采用不同的装载策略。我们可以思考一下 Jboss AOP 框架的实现原理，它就是在对你的 class 文件装载环节做了手脚--插入了 AOP 的相关拦截字节码，这使得它可以对程序员做到完全透明化，哪怕你用 new 操作符创建出的对象实例也一样能被 AOP 框架拦截--与之相对应的 Spring AOP，你必须通过他的 BeanFactory 获得被 AOP 代理过的受管对象，当然 Jboss AOP 的缺点也很明显--他是和 JBOSS 绑定很紧密的，你不能很轻松的移植到其它服务器上。嗯~……，说到这里有些跑题了，要知道 AOP 实现策略足可以写一本厚厚的书了，嘿嘿，就此打住。
说了这么多，类的初始化时机就是在"在首次主动使用时"，那么，哪些情形下才符合首次主动使用的要求呢？
首次主动使用的情形：
·创建某个类的新实例时--new、反射、克隆或反序列化；
·调用某个类的静态方法时；
·使用某个类或接口的静态字段或对该字段赋值时（final字段除外）；
·调用Java的某些反射方法时
·初始化某个类的子类时
·在虚拟机启动时某个含有main()方法的那个启动类。
除了以上几种情形以外，所有其它使用JAVA类型的方式都是被动使用的，他们不会导致类的初始化。
我的问题究竟出在哪里
好了，了解了JVM的类初始化与对象初始化机制后，我们就有了理论，也就可以理性的去分析问题了。
下面让我们来看看前面[清单一]的JAVA源代码反组译出的字节码：
［清单三］
public class com.ccb..enums.CachingEnumResolver extendsjava.lang.Object{
static {};
Code: 0: new #2;
//class CachingEnumResolver
3: dup
4: invokespecial #14;
//Method "
7: putstatic #16;
//Field SINGLE_ENUM_RESOLVER:Lcom/ccb/framework/enums/CachingEnumResolver;
10: new #18;
//class HashMap ②
13: dup
14: invokespecial #19;
//Method java/util/HashMap."
17: putstatic #21;
//Field CODE_MAP_CACHE:Ljava/util/Map;
20: getstatic #21;
//Field CODE_MAP_CACHE:Ljava/util/Map;
23: ldc #23;
//String 0
25: ldc #25;
//String 北京市
27: invokeinterface #31, 3;
//InterfaceMethod java/util/Map.put:(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object; ③
32: pop 33: returnprivate com.ccb.framework.enums.CachingEnumResolver();
Code: 0: aload_0 1: invokespecial #34;
//Method java/lang/Object."
//Method initEnums:()V ④ 7: returnpublic static void initEnums();
Code: 0: getstatic #21;
//Field CODE_MAP_CACHE:Ljava/util/Map;
⑤ 3: ifnonnull 24 6: getstatic #44;
//Field java/lang/System.out:Ljava/io/PrintStream;
9: ldc #46;
//String CODE_MAP_CACHE为空,问题在这里开始暴露.
11: invokevirtual #52;
//Method java/io/PrintStream.println:(Ljava/lang/String;)V 14: new #18;
//class HashMap 17: dup 18: invokespecial #19;
//Method java/util/HashMap."
//Field CODE_MAP_CACHE:Ljava/util/Map;
24: getstatic #21;
//Field CODE_MAP_CACHE:Ljava/util/Map;
27: ldc #54;
//String 1 29: ldc #25;
//String 北京市 31: invokeinterface #31, 3;
//InterfaceMethod java/util/Map.put:(Ljava/lang/Object;
Ljava/lang/Object;)Ljava/lang/Object;
⑦ 36: pop 37: getstatic #21;
//Field CODE_MAP_CACHE:Ljava/util/Map;
40: ldc #56;
//String 2 42: ldc #58;
//String 云南省 44: invokeinterface #31, 3;
//InterfaceMethod java/util/Map.put:(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;
⑧ 49: pop 50: returnpublic java.util.Map getCache();
Code: 0: getstatic #21;
//Field CODE_MAP_CACHE:Ljava/util/Map;
3: invokestatic #66;
//Method java/util/Collections.unmodifiableMap:(Ljava/util/Map;)Ljava/util/Map;
6: areturnpublic static com.ccb.framework.enums.CachingEnumResolver getInstance();
Code: 0: getstatic #16;
//Field SINGLE_ENUM_RESOLVER:Lcom/ccb/framework/enums/CachingEnumResolver;
⑨ 3: areturn}
如果上面［清单一］显示，清单内容是在 1.4 环境下的字节码内容，可能这份清单对于很大部分兄弟来说确实没有多少吸引力，因为这些 JVM 指令确实不像源代码那样漂亮易懂。但它的的确确是查找和定位问题最直接的办法，我们想要的答案就在这份 JVM 指令清单里。
现在，让我们对该类从类初始化到对象实例初始化全过程分析[清单一]中的代码执行轨迹。
如前面所述，类初始化是在类真正可用时的最后一项前阶工作，该阶段负责对所有类正确的初始化值，此项工作是安全的，JVM会保证多线程同步。
第1步：调用类初始化方法 CachingEnumResolver.
第2步：进入
第3步：让我们顺着执行顺序向下看，"④" 行，该行所在方法就是该类的构造器，该方法先调用父类的构造器
第4步："⑤" 行，该行获取 "CODE_MAP_CACHE" 字段值，其运行时该字段值为 null。注意，问题已经开始显现了。（作为程序员的你一定是希望该字段已经被初始化过了，而事实上它还没有被初始化）。通过判断，由于该字段为 NULL，因此程序将继续执行到 "⑥" 行，将该字段实例化为 HashMap()。
第5步：在 "⑦"、"⑧" 行，其功能就是为 "CODE_MAP_CACHE" 字段填入两条数据。
第6步：退出对象初始化方法
第7步：继续执行
第8步：类初始化完毕，同时该单态类的实例化工作也完成。
通过对上面的字节码执行过程分析，或许你已经清楚了解到导致错误的深层原因了，也或许你可能早已被上面的分析过程给弄得晕头转向了，不过也没折，虽然我也可以从源代码的角度来阐述问题，但这样不够深度，同时也会有仅为个人观点、不足可信之嫌。
如何解决
要解决上面代码所存在的问题很简单，那就是将 "SINGLE_ENUM_RESOLVER" 变量的初始化赋值语句转移到 getInstance() 方法中去即可。换句话说就是要避免在类还未初始化完成时从内部实例化该类或在初始化过程中引用还未初始化的字段。
写在最后
静下浮燥之心，仔细思量自己是否真的掌握了本文主题所引出的知识，如果您觉得您已经完全或基本掌握了，那么很好，在最后，我将前面的代码稍做下修改，请思考下面两组程序是否同样会存在问题呢？
程序一
public class CachingEnumResolver {
public static Map CODE_MAP_CACHE;
static {
CODE_MAP_CACHE = new HashMap();
//为了说明问题,我在这里初始化一条数据
CODE_MAP_CACHE.put("0","北京市");
initEnums();
}
程序二
public class CachingEnumResolver {
private static final CachingEnumResolver SINGLE_ENUM_RESOLVER;
public static Map CODE_MAP_CACHE;
static {
CODE_MAP_CACHE = new HashMap();
//为了说明问题,我在这里初始化一条数据
CODE_MAP_CACHE.put("0","北京市");
SINGLE_ENUM_RESOLVER = new CachingEnumResolver();
initEnums();
}
最后，一点关于 JAVA 群体的感言：时下正是各种开源框架盛行时期，Spring 更是大行其道，吸引着一大批 JEE 开发者的眼球（我也是 fans 中的一员）。然而，让我们仔细观察一下--以 Spring 群体为例，在那么多的 Spring fans 当中，有多少人去研究过 Spring 源代码？又有多少人对 Spring 设计思想有真正深入了解呢？当然，我是没有资格以这样的口吻来说事的，我只是想表明一个观点--学东西一定要"正本清源"。
献上此文，谨以共勉。
本文转自
http://cache.baidu.com/c?m=9f65cb4a8c8507ed4fece763105392230e54f7227c86d31674c3933fc239045c1426a5e0767c4719d3c77e621cad425eeeed6e21735037b0efce8840d6b9852858d2616b2e08c31c528516b8bb3032b620872b9eb86de3adf142cbfd9680c85422dd22076df7f29c5b7003ba1ce76547f4a7e95f655b07cceb27148b4e0328882230a137fef74368108086ca2c4dd45ed77660e4b845c12913c504d46f0c5730b74dc11f212d279439308f452a75e3&p=8c57c54ad48c12a059ecd426174e&user=baidu
- 解析Java类和对象的初始化过程_J2EE_Java开发_软件开发-编程-IT资源网
- [转载]解析Java类和对象的初始化过程_J2EE_Java开发_软件开发-编程-IT资源网
- 解析 Java 类和对象的初始化过程
- 解析Java类和对象的初始化过程
- 解析Java类和对象的初始化过程
- 解析Java类和对象的初始化过程
- 解析Java类和对象的初始化过程
- 解析Java类和对象的初始化过程
- 解析Java类和对象的初始化过程
- 解析 Java 类和对象的初始化过程
- 解析Java类和对象的初始化过程
- 解析 Java 类和对象的初始化过程（转）
- 解析 Java 类和对象的初始化过程
- 解析 Java 类和对象的初始化过程
- 解析 Java 类和对象的初始化过程
- 解析 Java 类和对象的初始化过程
- 解析 Java 类和对象的初始化过程
- 解析 Java 类和对象的初始化过程
- 需求分析、概要设计、详细设计的区别
- c#通过oledb获取excel文件表结构信息
- 函数对象简单入门
- 好游戏是什么样的
- 5.12汶川7.8级大地震
- 解析Java类和对象的初始化过程_J2EE_Java开发_软件开发-编程-IT资源网
- 很牛的储存过程
- com和dll的区别
- petshop4.0 详解之五(PetShop之业务逻辑层设计)
- com和dll的区别
- (翻译)设计Qt风格的C++的应用程序接口 （转）
- 这些你注意了吗？
- 如何设计中间业务层
- Visual C#.Net网络程序开发-Socket篇
