进程和线程
什么是系统进程
进程是指在系统中正在运行的一个应用程序的实例；线程是系统分配处理器时间资源的基本单元，或者说进程之内独立执行的一个单元。对于操作系统而言，其调度单元是线程。一个进程至少包括一个线程，通常将该线程称为主线程。一个进程从主线程的执行开始进而创建一个或多个附加线程，就是所谓基于多线程的多任务。
那进程与线程的区别到底是什么？
进程是执行程序的实例。例如，当你运行记事本程序（Nodepad）时，你就创建了一个用来容纳组成 Notepad.exe的代码及其所需调用动态链接库的进程。每个进程均运行在其专用且受保护的地址空间内。因此，如果你同时运行记事本的两个拷贝，该程序正在使用的数据在各自实例中是彼此独立的。在记事本的一个拷贝中将无法看到该程序的第二个实例打开的数据。
以沙箱为例进行阐述。一个进程就好比一个沙箱。线程就如同沙箱中的孩子们。孩子们在沙箱子中跑来跑去，并且可能将沙子攘到别的孩子眼中，他们会互相踢打或撕咬。但是，这些沙箱略有不同之处就在于每个沙箱完全由墙壁和顶棚封闭起来，无论箱中的孩子如何狠命地攘沙，他们也不会影响到其它沙箱中的其他孩子。因此，每个进程就象一个被保护起来的沙箱。未经许可，无人可以进出。
实际上线程运行而进程不运行。两个进程彼此获得专用数据或内存的唯一途径就是通过协议来共享内存块。这是一种协作策略。
下面让我们分析一下任务管理器里的进程选项卡。
这里的进程是指一系列进程，这些进程是由它们所运行的可执行程序实例来识别的，这就是进程选项卡中的第一列给出了映射名称的原因。请注意，这里并没有进程名称列。进程并不拥有独立于其所归属实例的映射名称。换言之，如果你运行5个记事本拷贝，你将会看到5个称为Notepad.exe的进程。它们是如何彼此区别的呢？其中一种方式是通过它们的进程ID，因为每个进程都拥有其独一无二的编码。该进程ID由Windows NT或Windows 2000生成，并可以循环使用。因此，进程ID将不会越编越大，它们能够得到循环利用。第三列是被进程中的线程所占用的CPU时间百分比。它不是CPU的编号，而是被进程占用的CPU时间百分比。此时我的系统基本上是空闲的。尽管系统看上去每一秒左右都只使用一小部分CPU时间，但该系统空闲进程仍旧耗用了大约99%的CPU时间。
第四列，CPU时间，是CPU被进程中的线程累计占用的小时、分钟及秒数。请注意，我对进程中的线程使用占用一词。这并不一定意味着那就是进程已耗用的CPU时间总和，因为，如我们一会儿将看到的，NT计时的方式是，当特定的时钟间隔激发时，无论谁恰巧处于当前的线程中，它都将计算到CPU周期之内。通常情况下，在大多数NT系统中，时钟以10毫秒的间隔运行。每10毫秒NT的心脏就跳动一下。有一些驱动程序代码片段运行并显示谁是当前的线程。让我们将CPU时间的最后10毫秒记在它的帐上。因此，如果一个线程开始运行，并在持续运行8毫秒后完成，接着，第二个线程开始运行并持续了2毫秒，这时，时钟激发，请猜一猜这整整10毫秒的时钟周期到底记在了哪个线程的帐上？答案是第二个线程。因此，NT中存在一些固有的不准确性，而NT恰是以这种方式进行计时，实际情况也如是，大多数32位操作系统中都存在一个基于间隔的计时机制。请记住这一点，因为，有时当你观察线程所耗用的CPU总和时，会出现尽管该线程或许看上去已运行过数十万次，但其CPU时间占用量却可能是零或非常短暂的现象，那么，上述解释便是原因所在。上述也就是我们在任务管理器的进程选项卡中所能看到的基本信息列。
什么是线程?
究竟什么是线程呢？一个线程是给定的指令的序列 (你所编写的代码)，一个栈(在给定的方法中定义的变量)，以及一些共享数据(类一级的变量)。线程也可以从全局类中访问静态数据、栈以及可能的一些共享数据 。
每个线程有其自己的堆栈和程序计数器（PC）。你可以把程序计数器（PC）设想为用于跟踪线程正在执行的指令，而堆栈用于跟踪线程的上下文，上下文是当线程执行到某处时，当前的局部变量的值。虽然你可以编写出在线程之间传送数据的子程序，在正常情况下，一个线程不能访问另外一个线程的栈变量。
一个线程必须处于如下四种可能的状态之一，这四种状态为：
初始态：一个线程调用了new方法之后，并在调用start方法之前的所处状态。在初始态中，可以调用start和stop方法。
Runnable：一旦线程调用了start 方法，线程就转到Runnable 状态，注意，如果线程处于Runnable状态，它也有可能不在运行，这是因为还有优先级和调度问题。 阻塞/ NonRunnable：线程处于阻塞/NonRunnable状态，这是由两种可能性造成的：要么是因挂起而暂停的，要么是由于某些原因而阻塞的，例如包括等待IO请求的完成。 退出：线程转到退出状态，这有两种可能性，要么是run方法执行结束，要么是调用了stop方法。
线程的状态
最后一个概念就是线程的优先级，线程可以设定优先级，高优先级的线程可以安排在低优先级线程之前完成。一个应用程序可以通过使用线程中的方法setPriority(int)，来设置线程的优先级大小。
GMF安装
GMF安装
1、下载一个Eclipse for RCP and RAP Developers
下载地址：http://www.eclipse.org/downloads/
2、打开Eclipse–> Help–>Install New Software
3、在Work with 中选择 –All Available Sites –
找到 Modeling,并勾选上GMF相关的插件，Finished安装，安装需要一段时间，视网络状态，请耐心等待。安装完成后会要求重启Eclipse.
4、安装完成后，在Project Explorer 中右键 new–>other–>
出现下面的选项表示GMF安装成功。
Eclipse中常用的menubarPath
菜单条路径（menubar path）指出了添加菜单项的位置。我们使用分层的标识符列表来访问这个位置。下面是经常使用的菜单条列表以及它们的路径和公共组标志：
文件：file
o “开始” 区：fileStart
o “新建”菜单内部的”附加”组标志： new/additions
o “新建”区，在”新建”菜单下面：new.ext
o “关闭” 区：close.ext
o “保存” 区：save.ext
o “打印” 区：print.ext
o “打开” 区：open.ext
o “导入” 区：import.ext
o “附加” 区：additions
o “最近的文档” 区：mru
o “结束” 区：fileEnd
编辑： edit
o “开始” 区：editStart
o “撤销” 区：undo.ext
o “剪切” 区：cut.ext
o “查找” 区：find.ext
o “添加” 区：add.ext
o “结束” 区（有时不是结束）：fileEnd
o “附加” 区：additions
eclipse RCP学习参考
Eclipse RCP 入门
http://www.cnblogs.com/zephyr/archive/2008/05/30/1210477.html
Graphical Modeling Framework 进阶
http://www.ibm.com/developerworks/cn/opensource/os-ecl-gmfextend/#N100C4
基于 GMF 的流程分析工具的设计与实现
http://www.ibm.com/developerworks/cn/opensource/os-cn-eclipse-gmf2/part2/index.html
EMF：Ecore模型
http://www.cnblogs.com/zhoujg/archive/2010/10/20/1855510.html
八进制
http://www.cnblogs.com/bjzhanghao/
拥抱Eclipse RCP
http://www.blogjava.net/youxia/category/17374.html
使用 GMF 快速开发支持嵌套图元的编辑器
http://www.ibm.com/developerworks/cn/opensource/os-cn-ecl-emfnested/index.html?ca=drs-
eclipse GMF
http://www.eclipse.org/modeling/gmp/downloads/?project=gmf-tooling
Eclipse RCP与Spring的整合
http://www.blogjava.net/guangnian0412/archive/2006/12/30/91061.html
如何解决RCP开发添加扩展时右键只出现General或一般？
http://www.cnblogs.com/biaoyu/category/238242.html
http://fsz521job.itpub.net/category/5606/65806
Eclipse RCP 简介
Eclipse RCP是一项位于Eclipse平台核心的功能。大多数人想到Eclipse时，会想到Java集成开发环境(IDE)。如果将Eclipse中关于 IDE的内容剥去，剩下的就是一个提供基本工作台功能的核心，包括对可移动以及可叠加的窗口组件(编辑器和视图)、菜单、工具栏、按钮、表格、树形结构等 等的支持，而这个核心就是Eclipse RCP。
个人理解Eclipse RCP就是由插件开发转向桌面应用开发，构建最小化的Eclipse平台(8M)运行你的桌面应用，不必再为程序框架烦心，摆脱失败的AWT和Swing，让程序拥有专业级效果，而实现又很简单、很优雅。
RCP提供了丰富的界面控件，这使得基于 Java 开发桌面应用也变得容易了很多，虽然仍然不能和基于VB、Delphi进行相比。对于开发者而言，尽管使用 RCP 也是为了开发桌面应用，但 RCP 给开发者带来的更多的感觉是在它充分发挥了插件化系统的优势， RCP 可以视为基于 OSGi（Open Service Gateway Initiative） 构建插件化系统的最佳实践的指导，从 RCP 的设计中，可以学习到如何将应用做到模块化、将应用做到动态化，甚至还可以学习到如何自动生成界面这样的设计思想。 RCP 可以看做是基于 OSGi 做插件化应用系统的最佳实践，其中的不少设计方法甚至都可以整理成为基于 OSGi 做插件化应用系统的设计模式，让我们进入 RCP 之旅，揭开面纱，一探其本质吧！相信大家在了解了 RCP 的设计思想，看过其代码后，不得不对 RCP 表示崇高的敬意，大师之作，不同凡响。
Eclipse RCP为应用程序开发人员提供了：
◆应用程序和特性的一致且本地的外观；
◆公共应用程序服务，例如窗口管理、更新管理、帮助和选择管理；
◆本地的外观，利用Windows、Mac OS X、Linux、Solaris、HP-UX、AIX和嵌入式设备上的实际平台窗口部件；
◆标准化的组件模型；
◆普及的可扩展性；
◆整合的更新机制；
◆顶级开发工具(Eclipse 软件开发包(SDK)是世界级的软件开发环境)。
Eclipse RCP项目用SWT图形库和工具包取代了Java标准中的AWT和Swing。SWT直接调用了操作系统的图形库，从而使得Java应用程序的LOOK & Feel 与操作系统的习惯完全一致；更为重要的是，对本地方法的直接调用大幅度的提高了基于SWT 的Java应用程序的运行速度。SWT 的缺点主要在于两点：(1) 不是Java语言标准； (2) 支持的平台太少。
Java学习杂谈（十三）－－ORM
这是最后一篇Java杂谈了，以ORM框架的谈论收尾，也算是把J2ee的最后一方面给涵盖到了，之所以这么晚才总结出ORM这方面，一是笔者这两周比较忙，另一方面也想善始善终，仔细的先自己好好研究一下ORM框架技术，不想草率的敷衍了事。
其实J2ee的规范指南里面就已经包括了一些对象持久化技术，例如JDO（Java Data Object）就是Java对象持久化的新规范，一个用于存取某种数据仓库中的对象的标准化API，提供了透明的对象存储，对开发人员来说，存储数据对象完全不需要额外的代码（如JDBC API的使用）。这些繁琐的工作已经转移到JDO产品提供商身上，使开发人员解脱出来，从而集中时间和精力在业务逻辑上。另外，JDO很灵活，因为它可以在任何数据底层上运行。JDBC只是面向关系数据库（RDBMS）JDO更通用，提供到任何数据底层的存储功能，比如关系数据库、文件、XML以及对象数据库（ODBMS）等等，使得应用可移植性更强。我们如果要理解对象持久化技术，首先要问自己一个问题：为什么传统的JDBC来持久化不再能满足大家的需求了呢？
笔者认为最好是能用JDBC真正编写过程序了才能真正体会ORM的好处，同样的道理，真正拿Servlet/Jsp做过项目了才能体会到Struts、 Spring等框架的方便之处。很幸运的是笔者这两者都曾经经历过，用混乱的内嵌Java代码的Jsp加Servlet转发写过完整的Web项目，也用 JDBC搭建过一个完整C/S项目的后台。所以现在接触到新框架才更能体会它们思想和实现的优越之处，回顾从前的代码，真是丑陋不堪啊。^_^
回到正题，我们来研究一下为什么要从JDBC发展到ORM。简单来说，传统的JDBC要花大量的重复代码在初始化数据库连接上，每次增删改查都要获得 Connection对象，初始化Statement，执行得到ResultSet再封装成自己的List或者Object，这样造成了在每个数据访问方法中都含有大量冗余重复的代码，考虑到安全性的话，还要加上大量的事务控制和log记录。虽然我们学习了设计模式之后，可以自己定义Factory来帮助减少一部分重复的代码，但是仍然无法避免冗余的问题。其次，随着OO思想深入人心，连典型的过程化语言Perl等都冠冕堂皇的加上了OO的外壳，何况是 Java中繁杂的数据库访问持久化技术呢？强调面向对象编程的结果就是找到一个桥梁，使得关系型数据库存储的数据能准确的映射到Java的对象上，然后针对Java对象来设计对象和方法，如果我们把数据库的Table当作Class，Record当作Instance的话，就可以完全用面向对象的思想来编写数据层的代码。于是乎，Object Relationship Mapping的概念开始普遍受到重视，尽管很早很早就已经有人提出来了。
缺点我们已经大概清楚了，那么如何改进呢？对症下药，首先我们要解决的是如何从Data Schema准备完美的映射到Object Schema，另外要提供对数据库连接对象生命周期的管理，对事务不同粒度的控制和考虑到扩展性后提供对XML、Properties等可配置化的文件的支持。到目前为止，有很多框架和技术在尝试着这样做。例如似乎是封装管理得过了头的EJB、很早就出现目前已经不在开发和升级了的Apache OJB、首先支持Manual SQL的iBATIS，还有公认非常优秀的Hibernate等等。在分别介绍它们之前，我还想反复强调这些框架都在试图做什么：
毕竟Java Object和数据库的每一条Record还是有很大的区别，就是类型上来说，DB是没有Boolean类型的。而Java也不得不用封装类（Integer、Double等）为了能映射上数据库中为null的情况，毕竟Primitive类型是没有null值的。还有一个比较明显的问题是，数据库有主键和外键，而Java中仍然只能通过基本类型来对应字段值而已，无法规定Unique等特征，更别提外键约束、事务控制和级联操作了。另外，通过Java Object预设某Field值去取数据库记录，是否在这样的记录也是不能保证的。真的要设计到完全映射的话，Java的Static被所有对象共享的变量怎么办？在数据库中如何表现出来……
我们能看到大量的问题像一座座大山横在那些框架设计者们面前，他们并不是没有解决办法，而是从不同的角度去考虑，会得到很多不同的解决方案，问题是应该采取哪一种呢？甚至只有等到真正设计出来了投入生产使用了，才能印证出当初的设想是否真的能为项目开发带来更多的益处。笔者引用一份文档中提到一个健壮的持久化框架应该具有的特点：
A robust persistence layer should support—-
1. Several types of persistence mechanism
2. Full encapsulation of the persistence mechanism.
3. Multi-object actions
4. Transactions Control
5. Extensibility
6. Object identifiers
7. Cursors: logical connection to the persistence mechanism
8. Proxies: commonly used when the results of a query are to be displayed in a list
9. Records: avoid the overhead of converting database records to objects and then back to records
10. Multi architecture
11. Various database version and/or vendors
12. Multiple connections
13. Native and non-native drivers
14. Structured query language queries(SQL)
现在来简短的介绍一下笔者用过的一些持久化框架和技术，之所以前面强调那么多共通的知识，是希望大家不要盲从流行框架，一定要把握它的本质和卓越的思想好在哪里。
1． Apache OJB
OJB代表Apache Object Relational Bridge，是Apache开发的一个数据库持久型框架。它是基于J2ee规范指南下的持久型框架技术而设计开发的，例如实现了ODMG 3.0规范的API，实现了JDO规范的API， 核心实现是Persistence Broker API。OJB使用XML文件来实现映射并动态的在Metadata layer听过一个Meta-Object-Protocol(MOP)来改变底层数据的行为。更高级的特点包括对象缓存机制、锁管理机制、 Virtual 代理、事务隔离性级别等等。举个OJB Mapping的简单例子ojb-repository.xml：
<class-descriptor class=”com.ant.Employee” table=”EMPLOYEE”>
<field-descriptor name=”id” column=”ID”
jdbc-type=”INTEGER” primarykey=”true” autoincrement=”true”/>
<field-descriptor name=”name” column=”NAME” jdbc-type=”VARCHAR”/>
</class-descrptor>
<class-descriptor class=”com.ant.Executive” table=”EXECUTIVE”>
<field-descriptor name=”id” column=”ID”
jdbc-type=”INTEGER” primarykey=”true” autoincrement=”true”/>
<field-descriptor name=”department” column=”DEPARTMENT” jdbc-type=”VARCHAR”/>
<reference-descriptor name=”super” class-ref=”com.ant.Employee”>
<foreignkey field-ref=”id”/>
</reference-descriptor>
</class-descrptor>
2． iBATIS
iBATIS最大的特点就是允许用户自己定义SQL来组配Bean的属性。因为它的SQL语句是直接写入XML文件中去的，所以可以最大程度上利用到 SQL语法本身能控制的全部特性，同时也能允许你使用特定数据库服务器的额外特性，并不局限于类似SQL92这样的标准，它最大的缺点是不支持枚举类型的持久化，即把枚举类型的几个对象属性拼成与数据库一个字段例如VARCHAR对应的行为。这里也举一个Mapping文件的例子sqlMap.xml：
<sqlMap>
<typeAlias type=”com.ant.Test” alias=”test”/>
<resultMap class=”test” id=”result”>
<result property=”testId” column=”TestId”/>
<result property=”name” column=”Name”/>
<result property=”date” column=”Date”/>
</resultMap>
<select id=”getTestById” resultMap=”result” parameterClass=”int”>
select * from Test where TestId=#value#
</select>
<update id=”updateTest” parameterClass=”test”>
Update Tests set Name=#name#, Date=”date” where TestId=#testId#
</update>
</sqlMap>
3． Hibernate
Hibernate无疑是应用最广泛最受欢迎的持久型框架，它生成的SQL语句是非常优秀。虽然一度因为不能支持手工SQL而性能受到局限，但随着新一代 Hibernate 3.x推出，很多缺点都被改进，Hibernate也因此变得更加通用而时尚。同样先看一个Mapping文件的例子customer.hbm.xml来有一个大概印象：
<hibernate-mapping>
<class name=”com.ant.Customer” table=”Customers”>
<id name=”customerId” column=”CustomerId” type=”int” unsaved-value=”0”>
<generator class=”sequence”>
<param name=”sequence”> Customers_CustomerId_Seq </param>
</generator>
</id>
<property name=”firstName” column=”FirstName”/>
<property name=”lastName” column=”LastName”/>
<set name=”addresses” outer-join=”true”>
<key column=”Customer”/>
<one-to-many class=”com.ant.Address”/>
</set>
…
</class>
</hibernate-mapping>
Hibernate有很多显著的特性，最突出的就是它有自己的查询语言叫做HQL，在HQL中select from的不是Table而是类名，一方面更加面向对象，另外一方面通过在hibernate.cfg.xml中配置Dialect为HQL可以使得整个后台与数据库脱离耦合，因为不管用那种数据库我都是基于HQL来查询，Hibernate框架负责帮我最终转换成特定数据库里的SQL语句。另外 Hibernate在Object-Caching这方面也做得相当出色，它同时管理两个级别的缓存，当数据被第一次取出后，真正使用的时候对象被放在一级缓存管理，这个时候任何改动都会影响到数据库；而空闲时候会把对象放在二级缓存管理，虽然这个时候与数据库字段能对应上但未绑定在一起，改动不会影响到数据库的记录，主要目的是为了在重复读取的时候更快的拿到数据而不用再次请求连接对象。其实关于这种缓存的设计建议大家研究一下Oracle的存储机制（原理是相通的），Oracle牺牲了空间换来时间依赖于很健壮的缓存算法来保证最优的企业级数据库访问速率。
以上是一些Mapping的例子，真正在Java代码中使用多半是继承各个框架中默认的Dao实现类，然后可以通过Id来查找对象，或者通过 Example来查找，更流行的是更具Criteria查找对象。Criteria是完全封装了SQL条件查询语法的一个工具类，任何一个查询条件都可以在Criteria中找到方法与之对应，这样可以在Java代码级别实现SQL的完全控制。另外，现在许多ORM框架的最新版本随着JDk 5.0加入Annotation特性都开始支持用XDoclet来自动根据Annotation来生成XML配置文件了。
笔者不可能详细的讲解每一个框架，也许更多的人在用Hibernate，笔者是从OJB开始接触ORM技术的，它很原始却更容易让人理解从JDBC到 ORM的过渡。更多的细节是可以从官方文档和书籍中学到的，但我们应该更加看中它们设计思想的来源和闪光点，不是盲从它们的使用方法。
到这里全部Java杂谈这个主题就正式结束了，笔者也可以长叹一口气，拿到毕设题目后也该开始忙自己的毕业设计了。最近看了很多Spring AOP的资料，实习下班回家还会研究Ajax和极限编程，如果有时间了话，会把自己的学习笔记拿出来分享的。衷心希望大家都能不断的进步，在喜欢的道路上不回头的走下去……^_^
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所学就差不多说完了。不足之处大家尽管提出来，笔者愿意接受各种职责批评，因为笔者认为失败的教训往往比成功更加助人成长。这个帖子一直以来得到那么多朋友的大力支持和鼓励，笔者在这里真诚的说一声谢谢！因为笔者即将毕业投入茫茫人海去从草根阶层开始挣扎，最近冷静的想了很多，即使毕业了，要提高的不止是技术，还包括很多综合素质，也许并不能马上找到如意的团队和工作岗位，只能承认自己是弱势群体，有时不得不向现实的生活低头，不知道今后是否还有这闲心去写学习笔记，去坚持走分享的道路。其实很多人我认为也很有心去分享，但被现实的生活束缚了手脚。所以也期望还呆在学校里的大学生们好好努力的珍惜那份无忧虑的心境和安静的环境，好好充实自己吧！
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学习杂谈（十）－－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笔者也没真正怎么用过，这里是看了网上一些前辈的帖子之后写下自己的学习体验，不足之处请见谅！
