转 牛人 java语录 （3）

Java杂谈（九）－－Struts
 
J2ee的开源框架很多，笔者只能介绍自己熟悉的几个，其他的目前在中国IT行业应用得不是很多。希望大家对新出的框架不要盲目的推崇，首先一定要熟悉它 比旧的到底好在哪里，新的理念和特性是什么？然后再决定是否要使用它。
 
这期的主题是Struts，直译过来是支架。Struts的第一个版本是在2001年5月发布的，它提供了一个Web应用的解决方案，如何让Jsp和 servlet共存去提供清晰的分离视图和业务应用逻辑的架构。在Struts之前，通常的做法是在Jsp中加入业务逻辑，或者在Servlet中生成视 图转发到前台去。Struts带着MVC的新理念当时退出几乎成为业界公认的Web应用标准，于是当代IT市场上也出现了众多熟悉Struts的程序员。 即使有新的框架再出来不用，而继续用Struts的理由也加上了一条低风险，因为中途如果开发人员变动，很容易的招进新的会Struts的IT民工 啊，^_^!  
 
笔者之前说的都是Struts-1，因为新出了Struts-2，使得每次谈到Struts都必须注明它是Struts-1还是2。笔者先谈比较熟悉的 Struts-1，下次再介绍一下与Struts－2的区别：  
 
1． Struts框架整体结构  
Struts-1的核心功能是前端控制器，程序员需要关注的是后端控制器。前端控制器是是一个Servlet，在Web.xml中间配置所有 Request都必须经过前端控制器，它的名字是ActionServlet，由框架来实现和管理。所有的视图和业务逻辑隔离都是应为这个 ActionServlet， 它就像一个交通警察，所有过往的车辆必须经过它的法眼，然后被送往特定的通道。所有，对它的理解就是分发器，我们也可以叫做Dispatcher，其实了 解Servlet编程的人自己也可以写一个分发器，加上拦截request的Filter，其实自己实现一个struts框架并不是很困难。主要目的就是 让编写视图的和后台逻辑的可以脱离紧耦合，各自同步的完成自己的工作。  
 
那么有了ActionServlet在中间负责转发，前端的视图比如说是Jsp，只需要把所有的数据Submit，这些数据就会到达适合处理它的后端控制 器Action，然后在里面进行处理，处理完毕之后转发到前台的同一个或者不同的视图Jsp中间，返回前台利用的也是Servlet里面的forward 和redirect两种方式。所以到目前为止，一切都只是借用了Servlet的API搭建起了一个方便的框架而已。这也是Struts最显著的特性—— 控制器。  
 
那么另外一个特性，可以说也是Struts-1带来的一个比较成功的理念，就是以xml配置代替硬编码配置信息。以往决定Jsp往哪个servlet提 交，是要写进Jsp代码中的，也就是说一旦这个提交路径要改，我们必须改写代码再重新编译。而Struts提出来的思路是，编码的只是一个逻辑名字，它对 应哪个class文件写进了xml配置文件中，这个配置文件记录着所有的映射关系，一旦需要改变路径，改变xml文件比改变代码要容易得多。这个理念可以 说相当成功，以致于后来的框架都延续着这个思路，xml所起的作用也越来越大。  
 
大致上来说Struts当初给我们带来的新鲜感就这么多了，其他的所有特性都是基于方便的控制转发和可扩展的xml配置的基础之上来完成它们的功能的。  
下面将分别介绍Action和FormBean， 这两个是Struts中最核心的两个组件。  
 
2． 后端控制器Action  
Action就是我们说的后端控制器，它必须继承自一个Action父类，Struts设计了很多种Action，例如DispatchAction、 DynaValidationAction。它们都有一个处理业务逻辑的方法execute()，传入的request, response, formBean和actionMapping四个对象，返回actionForward对象。到达Action之前先会经过一个 RequestProcessor来初始化配置文件的映射关系，这里需要大家注意几点：  
 
1) 为了确保线程安全，在一个应用的生命周期中，Struts框架只会为每个Action类创建一个Action实例，所有的客户请求共享同一个Action 实例，并且所有线程可以同时执行它的execute()方法。所以当你继承父类Action，并添加了private成员变量的时候，请记住这个变量可以 被多个线程访问，它的同步必须由程序员负责。(所有我们不推荐这样做)。在使用Action的时候，保证线程安全的重要原则是在Action类中仅仅使用 局部变量，谨慎的使用实例变量。局部变量是对每个线程来说私有的，execute方法结束就被销毁，而实例变量相当于被所有线程共享。  
 
2) 当ActionServlet实例接收到Http请求后，在doGet()或者doPost()方法中都会调用process()方法来处理请求。 RequestProcessor类包含一个HashMap，作为存放所有Action实例的缓存，每个Action实例在缓存中存放的属性key为 Action类名。在RequestProcessor类的processActionCreate()方法中，首先检查在HashMap中是否存在 Action实例。创建Action实例的代码位于同步代码块中，以保证只有一个线程创建Action实例。一旦线程创建了Action实例并把它存放到 HashMap中，以后所有的线程会直接使用这个缓存中的实例。  
 
3) <action> 元素的 <roles> 属性指定访问这个Action用户必须具备的安全角色，多个角色之间逗号隔开。RequestProcessor类在预处理请求时会调用自身的 processRoles()方法，检查配置文件中是否为Action配置了安全角色，如果有，就调用HttpServletRequest的 isUserInRole()方法来判断用户是否具备了必要的安全性角色，如果不具备，就直接向客户端返回错误。(返回的视图通过 <input> 属性来指定)  
 
3． 数据传输对象FormBean  
Struts并没有把模型层的业务对象直接传递到视图层，而是采用DTO（Data Transfer Object）来传输数据，这样可以减少传输数据的冗余，提高传输效率；还有助于实现各层之间的独立，使每个层分工明确。Struts的DTO就是 ActionForm，即formBean。由于模型层应该和Web应用层保持独立。由于ActionForm类中使用了Servlet API， 因此不提倡把ActionForm传递给模型层， 而应该在控制层把ActionForm Bean的数据重新组装到自定义的DTO中， 再把它传递给模型层。它只有两个scope，分别是session和request。（默认是session）一个ActionForm标准的生命周期 是：  
1) 控制器收到请求 ->  
2) 从request或session中取出ActionForm实例，如不存在就创建一个 ->  
3) 调用ActionForm的reset()方法 ->  
4) 把实例放入session或者request中 ->  
5) 将用户输入表达数据组装到ActionForm中 ->  
6) 如眼张方法配置了就调用validate()方法 ->  
7) 如验证错误就转发给 <input> 属性指定的地方，否则调用execute()方法  
 
validate()方法调用必须满足两个条件：  
1) ActionForm 配置了Action映射而且name属性匹配  
2) <aciton> 元素的validate属性为true  
 
如果ActionForm在request范围内，那么对于每个新的请求都会创建新的ActionForm实例，属性被初始化为默认值，那么 reset()方法就显得没有必要；但如果ActionForm在session范围内，同一个ActionForm实例会被多个请求共 享，reset()方法在这种情况下极为有用。  
 
4． 验证框架和国际化  
Struts有许多自己的特性，但是基本上大家还是不太常用，说白了它们也是基于JDK中间的很多Java基础包来完成工作。例如国际化、验证框架、插件 自扩展功能、与其他框架的集成、因为各大框架基本都有提供这样的特性，Struts也并不是做得最好的一个，这里也不想多说。Struts的验证框架，是 通过一个validator.xml的配置文件读入验证规则，然后在validation-rules.xml里面找到验证实现通过自动为Jsp插入 javascript来实现，可以说做得相当简陋。弹出来的javascript框不但难看还很多冗余信息，笔者宁愿用formBean验证或者 Action的saveErrors()，验证逻辑虽然要自己写，但页面隐藏/浮现的警告提示更加人性化和美观一些。  
 
至于Struts的国际化，其实无论哪个框架的国际化，java.util.Locale类是最重要的Java I18N类。在Java语言中，几乎所有的对国际化和本地化的支持都依赖于这个类。如果Java类库中的某个类在运行的时候需要根据Locale对象来调 整其功能，那么就称这个类是本地敏感的(Locale-Sensitive)， 例如java.text.DateFormat类就是，依赖于特定Locale。  
 
创建Locale对象的时候，需要明确的指定其语言和国家的代码，语言代码遵从的是ISO-639规范，国家代码遵从ISO-3166规范，可以从  
http://www.unicode.org/unicode/onlinedat/languages.html  
http://www.unicode.org/unicode/onlinedat/countries.htm  
 
Struts的国际化是基于properties的message/key对应来实现的，笔者曾写过一个程序，所有Jsp页面上没有任何Text文本串， 全部都用的是 <bean:message> 去Properties文件里面读，这个时候其实只要指定不同的语言区域读不同的Properties文件就实现了国际化。需要注意的是不同语言的字符写 进Properties文件的时候需要转化成Unicode码，JDK已经带有转换的功能。JDK的bin目录中有native2ascii这个命令，可 以完成对*.txt和*.properties的Unicode码转换。  
 
OK，今天就说到这里，本文中的很多内容也不是笔者的手笔，是笔者一路学习过来自己抄下来的笔记，希望对大家有帮助！Java杂谈一路走来，感谢大家持续 的关注，大概再有个2到3篇续篇就改完结了！笔者尽快整理完成后续的写作吧……^_^
Java杂谈 （十）－－Struts2
 
  最近业余时间笔者一直Java Virtual Machine的研究，由于实习分配到项目组里面，不想从前那么闲了，好不容易才抽出时间来继续这个话题的帖子。我打算把J2ee的部分结束之后，再谈谈 JVM和javascript，只要笔者有最新的学习笔记总结出来，一定会拿来及时和大家分享的。衷心希望与热爱Java的关大同仁共同进步……  
 
  这次准备继续上次的话题先讲讲Struts-2，手下简短回顾一段历史：随着时间的推移，Web应用框架经常变化的需求，产生了几个下一代 Struts的解决方案。其中的Struts Ti 继续坚持 MVC模式的基础上改进，继续Struts的成功经验。 WebWork项目是在2002年3月发布的，它对Struts式框架进行了革命性改进，引进了不少新的思想，概念和功能，但和原Struts代码并不兼 容。WebWork是一个成熟的框架，经过了好几次重大的改进与发布。在2005年12月，WebWork与Struts Ti决定合拼， 再此同时， Struts Ti 改名为 Struts Action Framework 2.0,成为Struts真正的下一代。  
 
  看看Struts-2的处理流程：  
  1) Browser产生一个请求并提交框架来处理：根据配置决定使用哪些拦截器、action类和结果等。  
  2) 请求经过一系列拦截器：根据请求的级别不同拦截器做不同的处理。这和Struts-1的RequestProcessor类很相似。  
  3) 调用Action: 产生一个新的action实例，调用业务逻辑方法。  
  4) 调用产生结果：匹配result class并调用产生实例。  
  5) 请求再次经过一系列拦截器返回：过程也可配置减少拦截器数量  
  6) 请求返回用户：从control返回servlet，生成Html。  
 
  这里很明显的一点是不存在FormBean的作用域封装，直接可以从Action中取得数据。 这里有一个Strut-2配置的web.xml文件：  
  <filter>    
  <filter-name> controller </filter-name>    
  <filter-class> org.apache.struts.action2.dispatcher.FilterDispatcher </filter-class>  
  </filter>  
  <filter-mapping>    
  <filter-name> cotroller </filter-name>    
  <url-pattern> /* </url-pattern>  
  </filter-mapping>  
 
  注意到以往的servlet变成了filter，ActionServlet变成了FilterDispatcher，*.do变成了/*。filter 配置定义了名称(供关联)和filter的类。filter mapping让URI匹配成功的的请求调用该filter。默认情况下，扩展名为 ".action "。这个是在default.properties文件里的 "struts.action.extension "属性定义的。  
 
  default.properties是属性定义文件，通过在项目classpath路径中包含一个名为“struts.properties”的文件来 设置不同的属性值。而Struts-2的默认配置文件名为struts.xml。由于1和2的action扩展名分别为.do和.action，所以很方 便能共存。我们再来看一个Struts-2的action代码：  
  public class MyAction {  
  public String execute() throws Exception {    
  //do the work    
  return "success ";  
  }  
  }  
 
  很明显的区别是不用再继承任何类和接口，返回的只是一个String，无参数。实际上在Struts-2中任何返回String的无参数方法都可以通过配 置来调用action。所有的参数从哪里来获得呢？答案就是Inversion of Control技术（控制反转）。笔者尽量以最通俗的方式来解释，我们先试图让这个Action获得reuqest对象，这样可以提取页面提交的任何参 数。那么我们把request设为一个成员变量，然后需要一个对它的set方法。由于大部分的action都需要这么做，我们把这个set方法作为接口来 实现。  
  public interface ServletRequestAware {  
  public void setServletRequest(HttpServletRequest request);  
  }  
 
  public class MyAction implements ServletRequestAware {    
  private HttpServletRequest request;    
 
  public void setServletRequest(HttpServletRequest request) {    
  this.request = request;    
  }  
     
  public String execute() throws Exception {  
  // do the work directly using the request    
  return Action.SUCCESS;    
  }    
  }  
 
  那么谁来调用这个set方法呢？也就是说谁来控制这个action的行为，以往我们都是自己在适当的地方写上一句 action.setServletRequest(…)，也就是控制权在程序员这边。然而控制反转的思想是在哪里调用交给正在运行的容器来决定，只要利 用Java反射机制来获得Method对象然后调用它的invoke方法传入参数就能做到，这样控制权就从程序员这边转移到了容器那边。程序员可以减轻很 多繁琐的工作更多的关注业务逻辑。Request可以这样注入到action中，其他任何对象也都可以。为了保证action的成员变量线程安 全，Struts-2的action不是单例的，每一个新的请求都会产生一个新的action实例。  
 
  那么有人会问，到底谁来做这个对象的注入工作呢？答案就是拦截器。拦截器又是什么东西？笔者再来尽量通俗的解释拦截器的概念。大家要理解拦截器的话，首先 一定要理解GOF23种设计模式中的Proxy模式。  
 
  A对象要调用f()，它希望代理给B来做，那么B就要获得A对象的引用，然后在B的f()中通过A对象引用调用A对象的f()方法，最终达到A的f()被 调用的目的。有没有人会觉得这样很麻烦，为什么明明只要A.f()就可以完成的一定要封装到B的f()方法中去？有哪些好处呢？  
 
  1) 这里我们只有一个A，当我们有很多个A的时候，只需要监视B一个对象的f()方法就可以从全局上控制所有被调用的f()方法。  
  2) 另外，既然代理人B能获得A对象的引用，那么B可以决定在真正调A对象的f()方法之前可以做哪些前置工作，调完返回前可有做哪些后置工作。  
 
  讲到这里，大家看出来一点拦截器的概念了么？它拦截下一调f()方法的请求，然后统一的做处理（处理每个的方式还可以不同，解析A对象就可以辨别），处理 完毕再放行。这样像不像对流动的河水横切了一刀，对所有想通过的水分子进行搜身，然后再放行？这也就是AOP（Aspect of Programming面向切面编程）的思想。  
 
  Anyway，Struts-2只是利用了AOP和IoC技术来减轻action和框架的耦合关系，力图到最大程度重用action的目的。在这样的技术 促动下，Struts-2的action成了一个简单被框架使用的POJO（Plain Old Java Object）罢了。实事上AOP和IoC的思想已经遍布新出来的每一个框架上，他们并不是多么新的技术，利用的也都是JDK早已可以最到的事情，它们代 表的是更加面向接口编程，提高重用，增加扩展性的一种思想。Struts-2只是部分的使用这两种思想来设计完成的，另外一个最近很火的框架 Spring，更大程度上代表了这两种设计思想，笔者将于下一篇来进一步探讨Spring的结构。  
 
  PS: 关于Struts-2笔者也没真正怎么用过，这里是看了网上一些前辈的帖子之后写下自己的学习体验，不足之处请见谅！
Java杂谈（十一）－－Spring
 
 
  笔者最近比较忙，一边在实习一边在寻找明年毕业更好的工作，不过论坛里的朋友非常支持小弟继续写，今天是周末，泡上一杯咖啡，继续与大家分享J2ee部分 的学习经验。今天的主题是目前很流行也很好的一个开源框架－Spring。  
 
  引用《Spring2.0技术手册》上的一段话：  
  Spring的核心是个轻量级容器，它是实现IoC容器和非侵入性的框架，并提供AOP概念的实现方式；提供对持久层、事务的支持；提供MVC Web框架的实现，并对于一些常用的企业服务API提供一致的模型封装，是一个全方位的应用程序框架，除此之外，对于现存的各种框架，Spring也提供 了与它们相整合的方案。  
接下来笔者先谈谈自己的一些理解吧，Spring框架的发起者之前一本很著名的书名字大概是《J2ee Development without EJB》，他提倡用轻量级的组件代替重量级的EJB。笔者还没有看完那本著作，只阅读了部分章节。其中有一点分析觉得是很有道理的：  
 
  EJB里在服务器端有Web Container和EJB Container，从前的观点是各层之间应该在物理上隔离，Web Container处理视图功能、在EJB Container中处理业务逻辑功能、然后也是EBJ Container控制数据库持久化。这样的层次是很清晰，但是一个很严重的问题是Web Container和EJB Container毕竟是两个不同的容器，它们之间要通信就得用的是RMI机制和JNDI服务，同样都在服务端，却物理上隔离，而且每次业务请求都要远程 调用，有没有必要呢？看来并非隔离都是好的。  
 
  再看看轻量级和重量级的区别，笔者看过很多种说法，觉得最有道理的是轻量级代表是POJO + IoC，重量级的代表是Container + Factory。（EJB2.0是典型的重量级组件的技术）我们尽量使用轻量级的Pojo很好理解，意义就在于兼容性和可适应性，移植不需要改变原来的代 码。而Ioc与Factory比起来，Ioc的优点是更大的灵活性，通过配置可以控制很多注入的细节，而Factory模式，行为是相对比较封闭固定的， 生产一个对象就必须接受它全部的特点，不管是否需要。其实轻量级和重量级都是相对的概念，使用资源更少、运行负载更小的自然就算轻量。  
 
  话题扯远了，因为Spring框架带来了太多可以探讨的地方。比如它的非侵入性：指的是它提供的框架实现可以让程序员编程却感觉不到框架的存在，这样所写 的代码并没有和框架绑定在一起，可以随时抽离出来，这也是Spring设计的目标。Spring是唯一可以做到真正的针对接口编程，处处都是接口，不依赖 绑定任何实现类。同时，Spring还设计了自己的事务管理、对象管理和Model2 的MVC框架，还封装了其他J2ee的服务在里面，在实现上基本都在使用依赖注入和AOP的思想。由此我们大概可以看到Spring是一个什么概念上的框 架，代表了很多优秀思想，值得深入学习。笔者强调，学习并不是框架，而是框架代表的思想，就像我们当初学Struts一样……  
 
  1．Spring MVC  
  关于IoC和AOP笔者在上篇已经稍微解释过了，这里先通过Spring的MVC框架来给大家探讨一下Spring的特点吧。（毕竟大部分人已经很熟悉 Struts了，对比一下吧）  
众所周知MVC的核心是控制器。类似Struts中的ActionServlet，Spring里面前端控制器叫做DispatcherServlet。 里面充当Action的组件叫做Controller，返回的视图层对象叫做ModelAndView，提交和返回都可能要经过过滤的组件叫做 Interceptor。  
 
  让我们看看一个从请求到返回的流程吧：  
  (1) 前台Jsp或Html通过点击submit，将数据装入了request域  
  (2) 请求被Interceptor拦截下来，执行preHandler()方法出前置判断  
  (3) 请求到达DispathcerServlet  
  (4) DispathcerServlet通过Handler Mapping来决定每个reuqest应该转发给哪个后端控制器Controller  
  (5) 各式各样的后端控制器Controller来处理请求，调用业务层对象来处理业务逻辑，然后返回一个ModelAndView对象  
  (6) 当Controller执行完毕，Interceptor会调用postHandle来做后置处理  
  (7) ModelAndView代表了呈现画面是使用的Model数据对象和View对象，由于只能返回一个对象所有起了这个名字封装这两个对象。  
  (8) 由ViewResolver对象来解析每个返回的ModelAndView对象应该呈现到哪一个视图（Jsp/Html等）中（包括Exception Resolver）  
  (9) 当View绘制完成之后Interceptor又会跳出来执行它的afterCompletion方法做善后处理。当然Interceptor的行为完全 是配置的而不是强制的。  
 
 
  这样一个完整的流程就这样结束了，个人感觉Spring的MVC框架稍显复杂，不像Struts-1那么容易上手。不管是Controller、 Model、ViewRosovler、Handle Mapping还是View，Spring MVC框架都已经为你提供了多种实现，想最大程度的减少程序员的编码，增加框架的适用性。大家有兴趣可以继续深入研究哈！  
 
  2．Spring AOP  
  记得最初笔者请教他人Spring是一个什么东西的时候，每个人都会提到AOP这个词语。笔者在上一篇已经解释过AOP基本原理，这次来跟大家说说 Spring的AOP编程吧。不同的AOP框架会有其对AOP概念不同的实现方式，主要的差别在于所提供的Pointcut、Aspects的丰富程度， 以及它们如何被织入应用程序、代理的方式等等。先熟悉一下AOP中的几个重要概念：  
  (1) Cross-cutting：横切，说白了就是需要统一处理的集合  
  (2) Aspects:将散落各处的横切收集起来，设计成各个独立可重用的对象称为Aspects。  
  (3) Advice: 对横切的具体实现，即等待插入一段逻辑。  
  (4) Joinpoint:Advice插入流程的时机点。  
  (5) Pointcut: 用于选择Joinpoint的程序结构，可以通过Annotation或者XML实现。  
  (6) Weave: Advice被应用至对象之上的过程称之为织入，有编译期、类加载期、运行期三种时间点策略。  
 
  如果你采用实现接口的方式，Spring会在执行时期适用java的动态代理，如果不实现接口，Spring会使用CGLIB产生代理类。AOP的概念很 大很泛，而Spring只使用了其中的部分特性，毕竟Spring的目标是轻量级框架，比如它只支持对Method的Joinpoint，而不支持对 Field的Joinpoint，理由是为了封装性。  
   
  其实我们可以把概念看得简单一点，AOP的目的是减少冗余代码，增强对较大项目的全局监控。Spring利用AOP可以规定一个集合和一套规则，在这个集 合里所有的方法被invoke即调用的时候，都必须按照那套规则走一遍。那么首先对其中10个方法都要用到的处理代码就只用写一遍，如果是这10个方法来 了就织入这段代码；其次，按照规则，也许所有的牵扯某个模块的方法调用的时候，我都需要做日志或者进行验证，那么我只要立足于这个集合的入口和出口，管他 从哪里来去哪里，都能被有效的监控。我监控的可能不止是某个方法单独的行为，我还可以加入对流程控制的监控规则。例如是论坛，我规定注册了才能登录，而登 录后才能发帖回帖下资源，于是所有这类流程都会被收集到我眼皮地下通过。  
 
  PS:笔者最近忙于找工作的事，没有太多经历在论坛跟大家整理自己的笔记。最近也只是接触Spring的MVC比较多，对于Spring的其他特性，还没 有更多的去实践，所以仅仅是泛泛而谈，只是介绍一个印象罢了。还是那句话，我们学习一个框架不是如何使用，而是它所带来的优秀的思想和理念，这比如何使用 这个框架更有意义得多
Java杂谈（十二）－－JVM
 
  本来这次应该讲讲ORM的几个框架，但是笔者还没有完全总结出来，所以这里先插入一次学习JVM的心得。作为一个Java程序员，如果不了解JVM的工作 原理，就很难从底层去把握Java语言和Java程序的运作机制。这里先推荐一个最权威的讲解JVM的文档，大家只要查过Java API的可以在里面的一个叫“API, Language, and Virtual Machine Document”的标题下看到四个子标题，第一个是我们最熟悉的Java API Specification，很少会有人注意到第三和第四个子标题，分别是“The Java Language Specification”和“The Java Machine Specification”后面都带有（Download）字样，JVM的那个URL直接链接到http://java.sun.com/docs/books/vmspec/2nd-edition/这 里地址。我们可以下载到一份非常权威详细的讲解JVM原理的官方文档。笔者业余时间花了1个星期来阅读，这里把自己的收获跟大家来分享一下，大概从这么几 个方面来谈一谈：  
 
  1． JVM的实现机制  
  Java虚拟机就是一个小的计算机，有自己的指令集，有自己的文件系统，管理内部的表和数据，负责读取class文件里面字节码，然后转换成不同操作系统 的CPU指令，从而使得Java程序在不同的操作系统上顺利的跑起来。所以Window的JVM能把字节码转换成Window系统的指令集，Linux的 JVM能把字节码转换成Linux系统的字节，同理还有Solaris，它们彼此之间是不能通用的。最早一款的原型虽然是Sun公司开发的，但发展到现在 其实任何厂商都可以自己去实现一个虚拟机，用来读取字节码转换成OS指令。甚至我们可以认为JVM跟Java编程语言都没有关系，因为你自己哪怕用记事本 写一串字节码，也可以让JVM来解析运行，只要你的字节码能通过JVM的验证。  
 
  JVM的验证其实是很严格的，这里只讲一些有趣的地方。大家还记得Java的图标是一个杯咖啡麽？究其历史我们也许可以查出为什么，但还有更显而易见的方 式是JVM怎么判断一个文件是否是class文件？JVM的做法是读取前4个字节转换成16进制数，判断是否等于0xCAFEBABE这个数。注意到这个 单词了麽？“cafebabe”，代表着国外一种咖啡品牌，似乎叫做Peet’s coffee-baristas之类。创造Java的人为了方便记忆，选择了这样一个16进制数作为标准class文件的头，所以任何class文件都必 须具有这4个字节的头部。我们可以用DataInput这个接口的实现类来验证一下，读取任何一个class文件的第一个int，int在Java里面是 四个字节。转换成16进制一定会是0xcafebabe的。  
  所以这里想告诉大家的是，JVM其实并没有那么神秘，我们完全可以理解它的构造。  
 
  2． Java相关的基础概念  
  配合JVM的结构，在Java语言中也会有很多特点比较鲜明的地方。比如对数值计算从来不会检查位溢出。任何变量存储的二进制即使位全部为1了仍然可以 加，全部为0了仍然可以减。大家只要稍微测试一下就知道了，看这几个例子：  
  int max = Integer.MAX_VALUE;  
  int min = Integer.MIN_VALUE;  
  max+1 == min; //true  
  min-1 == max; //true  
  0.0/0.0 //得到“NaN”(Not a number)  
  1/0.0 //Infinity  
  -1/0.0 //-Infinity  
  1或-1/0 //ArithmeticException唯一的异常情况  
 
  看完这几个例子，大家是否能更好的把握Java的数值运算呢？Java完全遵照IEEE-754的标准来定义单双精度浮点数以及其他的数值存储方式。  
     
  另外Java里面有一个概念叫做Daemon Thread（守护线程），知道它的存在主要是为了理解虚拟机的生命周期。当我们运行java命令，从main函数进入的那一刻起，虚拟机就开始启动运行 了。Main所在的主线程也会启动起来，它属于非守护线程。与之同时一些守护线程也会同时启动，最典型的守护线程代表就是GC（垃圾收集器）线程。JVM 虚拟机什么时候退出呢？是在所有的非守护线程结束的那一刻，JVM就exit。注意这个时候守护线程并未退出，很可能还要继续完成它的本职工作之后才会结 束，但虚拟机的生命周期已经提前于它结束了。  
 
  3． JVM内部的基本概念  
  虚拟机内部还有一些概念，全部列举是不现实的，太繁琐也没有意义。除非您真的想自己去做一个JVM。笔者只列举部分概念：  
  首先我们来看一个叫做ReturnAddress的变量，它是JVM用来存储方法出口或者说进行跳转的依据，把任何地址存入这个变量就一定会按照这个地址 来跳转。我们需要注意的就是finally有比方法return更高的赋值给ReturnAddress的优先级。同时存在方法return和 finally return的话，一定是按照finally里面的return为准。  
     
  JVM有自己的Heap，能被所有线程共享，存储着所有的对象，内存是动态被分配的。对于每个线程，拥有自己的Stack，栈里面存储的单位叫做 Frame（桢）。桢里面就记录着零时变量、对象引用地址、方法返回值等数据。JVM还有一个叫做Method Area的地方，存储着一段一段的可执行代码，每一段就是一个方法体，也能被所有线程共享。所以我们说一个线程其实从run方法跑起来，跟它的类中声明的 其他方法是两个概念。因为其他的方法包括的所有的对象，这个时候都充当为资源被线程使用。  
 
  JVM有自己管理内存的方案，因为它具有文件系统的功能，我们可以看成一个小型的数据库，内部有许许多多不同的表。表的字段可能是另外一张表的地址，也可 以直接就是一个存储数据值的地址值。JVM所有对运行时候类的解析验证计算等管理工作，实际上都是在管理这些表的变动，如果我们从数据库的角度来 看，JVM所做的就是根据你的代码来操作那么多个表最后返回给你结果的过程。里面的表结构包括class的表、field表、method表、 attribute表等。  
 
  4． JVM的指令集  
  JVM有自己的指令集，笔者从前也看过一些计算机组成结构和汇编语言的数，建议大家也稍微看看，了解设计一个高效可用的计算机指令集是多么复杂又多么重要 的过程。对于JVM的指令集，职责是管理好Java程序编译出来的字节码，相对而言指令集的名称就多少和Java语言相关了，比如指令集里就有 sastore,、saload表示array里面short的存和取、类似还有d2i表示从double转换成int、monitorenter表示进 入synchronized块加锁、getstatic和putstatic表示对静态标量的存取、 jsr和ret等跳转指令……  
 
  为了便于记忆，设计JVM指令集的人们约定f开头的跟float有关，d跟double有关，i跟int有关，s跟short有关，a跟array有关。 有兴趣的可以细读文档里面的每一个指令的作用。因为只是作为初步了解，这里就不多说了。  
 
  5． 一些Java关键字的实现原理  
  文档还很详细的列举了很多加载、初始化、加锁等操作的过程。笔者觉得比较有用的第一是记住Java里面只有Array不是由ClassLoader加载的 对象，其他的对象全部都必须由一个ClassLoader来加载。另外package的概念除了类似于C++的namespace，是一种命名空间之外， 底层的实现是规定同一个package下的类必须由同一个类加载器来加载，所以package的概念还可以认为是被同一个类加载器加载的类。  
     
  另外在多线程中，有很多细节值得去体会。每个线程有自己的Working memory，它们从能被共享的Main Memory中去读数据、修改、然后再存回去。笔者一直认为线程就是数据库里面事务的前身或者说祖先。我们只要稍微比较一下它们的行为，就会发现很多一致 性。事务也是操作被事务共享的表数据，你改完我改，顺序不一致就会出现脏数据，而线程同样会出现脏数据。我们对线程加的锁策略，同样在事务中也有适用。当 然多事务的情况显然比多线程更加复杂，但我们只要理解了多线程，相信对学习数据库事务的效果也是非常有帮助的。Java里面除了synchronized 能够帮助同步多线程之外，还有一个弱同步的操作关键字是volatile，它产生在变量上的约束在文档中也有详细的说明。因为很复杂，考虑到篇幅笔者就不 打算解释一遍了。  
 
  好了，又是新的一篇结束了。大概再有一两篇笔者大学关于Java所学就差不多说完了。不足之处大家尽管提出来，笔者愿意接受各种职责批评，因为笔者认为失 败的教训往往比成功更加助人成长。这个帖子一直以来得到那么多朋友的大力支持和鼓励，笔者在这里真诚的说一声谢谢！因为笔者即将毕业投入茫茫人海去从草根 阶层开始挣扎，最近冷静的想了很多，即使毕业了，要提高的不止是技术，还包括很多综合素质，也许并不能马上找到如意的团队和工作岗位，只能承认自己是弱势 群体，有时不得不向现实的生活低头，不知道今后是否还有这闲心去写学习笔记，去坚持走分享的道路。其实很多人我认为也很有心去分享，但被现实的生活束缚了 手脚。所以也期望还呆在学校里的大学生们好好努力的珍惜那份无忧虑的心境和安静的环境，好好充实自己吧！